http://technet.microsoft.com/en-us/library/hh831611.aspx

PowerShell anywhere, really.

@EddieJennings we use a combination. We use the ids generated by sssd and automate the population of the AD attributes to align with them to ensure consistency. Where it comes in handy is when we have NFS mounts exported from an LDAP-aware NAS device. The NAS device doesn't natively understand the sssd mappings, and relies upon LDAP calls to find the accounts.

You can't really have a conflict, unless you were looking for a user and group to have the same number (which they can't with sssd, because it appends the principle's RID (padded to 5 digits). If you have a need to manually specify a UID/GID,, that would be for a local account, I presume. In those scenarios, we do create AD accounts that have manually defined UIDs that line up with the local user (always less than 1000) for the NAS appliance to find when evaluating access.

@EddieJennings sssd will by default generate a five digit identifier for each domain. It has to be repeatable because each instance of sssd on computers that may not talk to eachother have to come up with the same number. Once you have the number for a single account, you can predict what the uid is going to be for any group, user, or service account.

So, for a given domain ad.domain.com, and a user Bob, with a SID of S-1-5-....-1501, sssd will give you an id of XXXXX01501. Any other account in that domain will have the same XXXXX value followed by their RID (padded to five digits).

I'm pretty sure you can even override the value of XXXXX that sssd generates, but I prefer not to.

@Pete-S That sounds interesting, I'll have to dig into that a little more. In the mean time, we've added the public keys to the user accounts in AD configured openssh to validate the keys against AD instead of the local files.

@EddieJennings sssd will by default generate a five digit identifier for each domain. It has to be repeatable because each instance of sssd on computers that may not talk to eachother have to come up with the same number. Once you have the number for a single account, you can predict what the uid is going to be for any group, user, or service account.

So, for a given domain ad.domain.com, and a user Bob, with a SID of S-1-5-....-1501, sssd will give you an id of XXXXX01501. Any other account in that domain will have the same XXXXX value followed by their RID (padded to five digits).

I'm pretty sure you can even override the value of XXXXX that sssd generates, but I prefer not to.

@Pete-S If it is an issue, its trival enough to prevent public key authentication for users or groups of users, even groups of AD users.

@EddieJennings we use a combination. We use the ids generated by sssd and automate the population of the AD attributes to align with them to ensure consistency. Where it comes in handy is when we have NFS mounts exported from an LDAP-aware NAS device. The NAS device doesn't natively understand the sssd mappings, and relies upon LDAP calls to find the accounts.

You can't really have a conflict, unless you were looking for a user and group to have the same number (which they can't with sssd, because it appends the principle's RID (padded to 5 digits). If you have a need to manually specify a UID/GID,, that would be for a local account, I presume. In those scenarios, we do create AD accounts that have manually defined UIDs that line up with the local user (always less than 1000) for the NAS appliance to find when evaluating access.

http://technet.microsoft.com/en-us/library/hh831611.aspx

PowerShell anywhere, really.

My wife's got a...uh...nook. I'm not the biggest fan, but it was a gift from her mother. That being said, I can use PowerShell Web Access on it, which is sometimes all I need.