Question regarding AD connector and atrribute mapping

[jo3y]

Hi,

Is it possible to customize the way attributes are mapped? The reason I ask is that I'm currently trying to import users from AD but they do not have a userPrinicpalName attribute set (I haven't asked the AD guys why this is yet...). As userPrinicpalName is used to map the user name atrribute I'm struggling to auto create accounts in Endpoint Encryption that will automatically log in using Windows credentials.

To work around the missing userPrinicpalName attribute I want to know if it's possible to customize what the user name is mapped to, making it map to sAMAccountName & @domainname

Hope all of the above makes sense and that someone can help!

Cheers,

Charlie

[peter_eepc]

Use "mail" attribute. That will be easier for users (shouldn't they remember their e-mail address?).

[jo3y]

I would like McAfee EE to automatically log in using matching windows credentials, unfortunately in this Infrastructure a user's logon ID is a 6 digit number so nothing like their e-mail address.

[mwilke]

if no UPN exists on their AD profile use sAMAccountName

Much shorter than UPN

sAMAccountName = mwilke

UPN = mwilke@DomainXYZ  (usually)

[jo3y]

Thanks Mike, I've set it to that but didn't get chance to test installing the client onto a machine and loggin in as the imported user. However I was under the impression that this wouldn't work as it required the @domainxyz part to match up correctly with the Windows username and password and auot login. I'll give it a go now and see how it goes.

[CIPHENT.com]

saMAccountName is your best bet and that works like charm!

- AB

[mwilke]

Joey, if your windows usernames are user@domain and that info is not listed in the userPrincipalName attribute then where is that info listed in AD?

[jo3y]

No where! I've checked all of the attributes in AD for the test account and user@domain isn't listed. I've spoken with the AD guy and s the domain suffix differs from the e-mail suffix there is no requirement for the attribute so it's never been set.

I've just tested using sAMAccountName, after the initial login after install and setting the password from defaul it seems to be loggin in fine. I've just performing a couple of final test/sanity checks

- installing the client onto a different machine and logging in to see if it logs on automatically or the user is still required to enter the McAfee credentials first time round

- Changing the user's Windows password on one machine and seeing if the McAfee credentials auto update, then moving to the other machine and logging in to see if that has picked up the changes.

[jkussow]

I'd like offer a caution about using sAMAccountName, which I think I've also seen somewhere in the EE documentation, or maybe a KB article.  If your organization has multiple domains sAMAccountName may not be your best choice.since you can have an account in each domain with the same sAMAccountName--they could even be different people. Another potential problem with this is if your organization reuses sAMAccount names as users come and go. (e.g. John Smith,jsmith, gets fired and 8 months later Jane Smith gets hired and is given the username of jsmith.)

We use sAMAccountName but we also have some pretty strict controls in place to prevent reuse and overlapping usernames accross multiple domains.  Just throwing it out there as something to consider in your approach.

[jo3y]

Thanks jkussow, this isn't an issue for the infrastructure I'll be implementing this into, it only has one domain and sAMAccountNames never get reused. Good to know though