search

irods / contrib

A pooled collection of community-contributed code that works alongside iRODS
BSD 3-Clause "New" or "Revised" License
13 stars 19 forks source link

Update sync_ad_accounts.sh #23

Closed jdkruzr closed 7 years ago

jdkruzr commented 7 years ago

I'm not sure why this script uses "uid" as the field to extract from ldapsearch. This isn't populated by default in Active Directory -- sAMAccountName is much more useful, is the familiar "login name" users use to authenticate, and is always unique.

trel commented 7 years ago

When running the script with sAMAccountName at RENCI, I see, in addition to the users I want... all the groups, service accounts, machine accounts that we don't want to sync into the iRODS catalog.

$ cat with-uid.txt | wc -l
231
$ cat with-sAMAccountName.txt | wc -l
604

I'm more than willing to document this and change the script - but right now, the script here is what we're using in production.

I don't know enough about the internals of why RENCI recommended to me to use uid. I'll investigate a bit more.

Do you have any good links/reading that I can share? It's quite possible we're not on the cutting edge of AD convention.

jdkruzr commented 7 years ago

Sure, here's some reading from a Technet thread on the subject: https://social.technet.microsoft.com/Forums/en-US/48928a03-aac2-40f6-852e-cd14f5147e16/server-2008-r2-active-directory-returns-the-uid-attribute-not-the-guid-in-base64-instead-of?forum=winserverDS

I suspect what's happened at RENCI is that you guys have done something, either with a script or with some tool like Centrify, to populate the uid value in AD for each user. As you can see there, it's not populated by default. So it works for RENCI, but wouldn't work in the general case.

I didn't have the "lots of extra stuff" problem with sAMAccountName. I wonder if this is a matter of what OU is chosen when running ldapsearch. Mine doesn't have anything other than interactive, "regular" AD users in the base DN.

trel commented 7 years ago

In learning a bit more about our setup here...

Our AD schema probably didn't have unix attributes from the get go. We extended the schema when we wanted to abandon our openldap instance.

Not all previous users are unix users so we never populated the new unix attributes in the schema for those old users.

and

Our users are actually split across two OUs, RENCI Users for what we call internal and "External Users" for external accounts.

So, @jdkruzr, you're correct - I'll merge this pull request for the generic 'best practice' script.

Thanks again!