Downloads all known user accounts for the associated account along with any previously saved MCP Username alias data.

Transcription

1 McAfee Client Proxy Setup Guide Revision A User Identification Utility Introduction The McAfee Client Proxy User Identification Utility ( mcpuseridentification.exe ) allows you to automatically map existing SaaS Web Protection Service users with the user name aliases used for the McAfee Client Proxy (MCP). The utility connects to the SaaS Web Control Console using credentials for a Customer Administrator. It downloads existing account addresses for existing users and matches them to Windows users in the local Active Directory system. The resulting file is uploaded into the SaaS Web Control Console to create the link between account and username for MCP authentication purposes. McAfee Client Proxy User Identification Utility automatically completes the following functions. Connects to the Control Console URL using the supplied Customer Administrator credentials. Downloads all known user accounts for the associated account along with any previously saved MCP Username alias data. Performs Active Directory look ups for all empty MCP Username Aliases (or all MCP Aliases if full refresh was enabled). Uploads the updated data back to the same Control Console. System Requirements Microsoft.NET 4.0 or greater must be installed on Windows. The Windows computer must have access to the local Active Directory server. Run the utility To use the utility, run an executable file on a computer and connect to the Web Protection Control Console. Task 1 From the Control Console, open Web Protection Policies McAfee Client Proxy Policies. 2 Click the MCP User Idnetification Utility link. This launches the.zip file to MCP executable. 3 Open the.zip file and copy the mcpuseridentification.exe file to the computer. 4 On the computer, double click mcpuseridentification.exe. 1

2 5 Enter the Customer Administrator logon credentials. 6 Optionally supply a Default Domain NetBIOS Name. 7 Optionally decide whether to perform a full refresh. 8 Click Connect. Optional form settings These additional options are provided on the form that is displayed to the user when they run this utility, but they need not be changed in most cases. They are made available for exceptional situations. Default Domain NetBIOS Name The Domain NetBIOS Name (Windows domain) is automatically queried along with every domain look up attempt. For all users who have matching SaaS and Active Directory accounts, this is ideal. However, when an Active Directory account does not exist for a specific SaaS user, an MCP Username Alias can be dynamically constructed for the missing user by affixing this Default Domain NetBIOS Name along with a back slash and the local part portion of their SaaS account name. This feature is optional and can be disabled. For Example: Presume a user sets the Default Domain NetBIOS Name to SAMPLE. Then, if the utility searches a (fictional) SaaS user, saasadmin@sample.domain.tld, who does not have an Active Directory account, the dynamic MCP Username Alias that is constructed becomes SAMPLE\saasadmin. 1 The Default Domain NetBIOS Name is automatically set to the NetBIOS name of the domain to which the current user has authenticated when this utility is loaded. 2 Delete the Default Domain NetBIOS Name value to prevent Best Guess matching. When this value is empty, SaaS accounts that have no match in Active Directory will not be given dynamically generated MCP Username Aliases. Optional configuration file An optional XML configuration file is supported by this utility. When not present, the utility functions correctly using built in settings. When present, this configuration file enables users to configure the utility with preset values for the Customer Administrator logon name and password as well as any number of Control Console URLs which the utility attempts to access whenever it downloads the user's MCP account data. This configuration file must be named mcpuseridentification.exe.config and it must exist in the same directory as the mcpuseridentification.exe. Configuration File Sample The following is the default content of the optional XML configuration file: <?xml version="1.0" encoding="utf 8"?> <configuration> <configsections> <sectiongroup name="usersettings" type="system.configuration.usersettingsgroup, System, Version= , Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name="mcpuseridentification.properties.settings" type="system.configuration.clientsettingssection, System, Version= , Culture=neutral, 2

3 PublicKeyToken=b77a5c561934e089" allowexedefinition="machinetolocaluser" requirepermission="false" /> </sectiongroup> <sectiongroup name="applicationsettings" type="system.configuration.applicationsettingsgroup, System, Version= , Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name="mcpuseridentification.properties.settings" type="system.configuration.clientsettingssection, System, Version= , Culture=neutral, PublicKeyToken=b77a5c561934e089" requirepermission="false" /> </sectiongroup> </configsections> <usersettings> <mcpuseridentification.properties.settings> <setting name="logon " serializeas="string"> <value /> </setting> <setting name="logonpassword" serializeas="string"> <value /> </setting> </mcpuseridentification.properties.settings> </usersettings> <applicationsettings> <mcpuseridentification.properties.settings> <setting name="consoleaddresses" serializeas="xml"> <value> <ArrayOfString xmlns:xsi=" instance" xmlns:xsd=" <string> <string> </ArrayOfString> </value> </setting> </mcpuseridentification.properties.settings> </applicationsettings> </configuration> Matching algorithm The matching algorithm supports a variety of options that support various Active Directory configurations. Active Directory supports advanced concepts like domain aliasing (called UPNSuffixes in Active Directory terminology). As a result, the following overarching algorithm is used in sequence to find MCP Username Alias data for each SaaS Account (each of these methods are defined below): 1 Direct Match 2 Domain Permutation Match 3 Domain Alias Match 4 Best Guess In all except Best Guess, the following Active Directory fields are searched no matter which version of Active Directory is used: 1 userprincipalname (the Windows 2000 style Domain login name for the user) 2 mail (the optional e mail field that Windows Administrators can provide for each user) 3 proxyaddresses (the set of Microsoft Exchange e mail addresses and e mail aliases that exist for each user) 3

4 Upon finding a match (excluding the Best Guess method), the MCP Username Alias is constructed using the configured NetBIOS Name for the Active Directory domain that contains the matching record. A Windows NT style logon name (in DomainNetBIOSname\UserName form) is then generated. This step is faster in Windows Server 2008 environments because this Windows NT style logon name is returned by the search request. All Active Directory searches are initially performed at the Global Catalog level and may be automatically delegated to any specific Forest or Tree level by the Global Catalog controller. These delegations are honored by this utility during its search, so the very best possible match is always sought. For all Active Directory search methods against Forests with more than one domain, there is always the possibility of finding the wrong Active Directory user account when the same local part exists in more than one domain. This utility tries to find the best possible match first, then each other somewhat less reliable method progressively. In most cases, this results in total success. In rare, edge cases, this can result in a small number of mismatches in scenarios where john.doe@domain1.tld and john.doe@domain2.tld exist in the same Forest, are actually two different people, and the customer is using a single fake domain with the SaaS account. To avoid this mismatch for the like named users, you should add unique e mail addresses (using their fake SaaS domain name) for the affected users to their respective Active Directory records (in the mail field) and use those unique e mail addresses as their SaaS account names. Direct match A direct match occurs when your SaaS account uses the same SaaS domain name as the local Active Directory domain name and the SaaS user account names match their local Active Directory account names. In this scenario, every SaaS user maps directly to the userprincipalname value of local Active Directory user accounts without any guesswork. For Example : Suppose you have a fictional customer that has a SaaS account with domain real.domain.tld and has a SaaS user with name real.user. Suppose also that the local Active Directory domain name is named, real.domain.tld and you diligently create SaaS users that exactly match their real local users. When you run this utility, the Active Directory user, real.user@real.domain.tld will be found, resulting in a direct match. Domain permutation match When the direct match method fails to find a local Windows account, this utility takes the local part of the SaaS account name and substitutes the domain name with every Active Directory domain name that is accessible in the nearest Global Catalog. Active Directory is then searched with each substitution until a match is found. This is likely to succeed in cases where the customer has registered a fake SaaS domain but all of their SaaS user accounts share the same local part as their intended Active Directory user accounts. For Example : Suppose you have a complex Active Directory Forest with several domains (with several Trees). Presume that two of these domain names are private.domain.1.tld and private.domain.2.tld. Let real.user.1 be a real user in private.domain.1.tld and real.user.2 be a real user in private.domain.2.tld. Suppose further that you did not register these private domains with our SaaS service. Instead of private.domain.1.tld and private.domain.2.tld, you simply have one SaaS domain, named fake.domain.tld. Yet all of your users have been granted SaaS accounts using their real user names ( real.user.1 and real.user.2 ), resulting in SaaS user names of, real.user.1@fake.domain.tld and real.user.2@fake.domain.tld. When you run the MCP User Identification utility, all of these real users on the fake domain are matched to real Active Directory accounts. This is possible because the domain portion of their SaaS accounts, fake.domain.tld, is dropped (when the direct match method fails) and substituted with 4

5 each of the real local domains, private.domain.1.tld and private.domain.2.tld. This results in searching Active Directory for and and finding matches. Domain alias match When both the direct match and domain permutation match methods fail to find Active Directory accounts, all registered Active Directory domain suffixes are then used to search for matches. This method is identical to the domain permutation match method except that UPNSuffix entries are used instead of domain names. This enables customers to match SaaS domains with local Active Directory domains that do not otherwise match, yet tie them together in a predictable way. For Example : Suppose you have a single local Active Directory domain, ad.domain.tld. but you use a different, fake SaaS domain, like fake.saas.domain.tld. You can assign the UPNSuffix, fake.saas.domain.tld to your domain controller for ad.domain.tld. Upon doing so, you are then able to get successful Active Directory searches with the MCP User Identification utility (as long as the local part portion of their SaaS accounts match the local part portion of their Active Directory accounts). Best-Guess When all else fails, a fictional MCP Username Alias is created for the SaaS account (unless Default Domain NetBIOS Name is empty). This fictional account is dynamically created by prefixing the Default Domain NetBIOS Name with a back slash to the local part portion of the unmatched SaaS account name. See the example in the Default Domain NetBIOS Name section above for more information. Note that when the Default NetBIOS Domain Name is empty, this step is skipped and dynamic MCP Aliases are not generated. Avoiding duplicate resolution Whenever more than one SaaS account resolves to the same Active Directory account, only the first encountered SaaS account gets an MCP Username Alias. All others are set to empty strings (no MCP Username Alias). SaaS accounts are processed in alphabetical order, so it should be easy to predict the outcome. To avoid duplication, you can try any of the following: Disable Best Guess matching by deleting the Default Domain NetBIOS Name. Reduce the likelihood of duplication by manually creating fictitious e mail address records in all but one of the affected users' Active Directory records and use those fictitious addresses as their SaaS account names (as discussed above in the Note under Matching Algorithm). Change the affected users' Active Directory account names so that the resulting names are sufficiently unique (such that no two accounts have the same local part in their User Principal Names). Ensure that the Active Directory SAM Account Name for every user in the Forest is unique. Delete any inactive, duplicate users from Active Directory and/or the SaaS service. 5

6 Copyright 2013 McAfee, Inc. Do not copy without permission. McAfee and the McAfee logo are trademarks or registered trademarks of McAfee, Inc. or its subsidiaries in the United States and other countries. Other names and brands may be claimed as the property of others. 6 A00