On Thu, Feb 09, 2017 at 07:06:44PM -0000, smfrench@gmail.com wrote:

One of the more common cases for sssd (or winbind) with RFC2307 seems to be getting uids/gids from Active Directory domains, but few Active Directories have all of their users/groups configured for the POSIX uid/gid.

How can you configure sssd behavior for this common case (among the three behaviors that might be desired):

1. query AD for the Unix uid/gid and fail if that particular user is not configured with a uid (this seems to be what sss always does and isn't really practical given how unlikely that AD is configured perfectly for unix uids)

yes, this is the default behavior if ldap_id_mapping=False (default). There are use cases for this behavior, e.g. if only a subset of users should be able to login in the UNIX/Linux hosts, only those get the POSIX IDs assigned in AD. But I agree that it might be cumbersome this ways to allow all AD users to access the UNIX/Linux hosts especially since you have to add GIDs to the groups as well as long as you need the groups and groupmemberships in the UNIX/Linux hosts as well.

2. query AD for the Unix uid/gid and if that user is not configured with a uid map to a default uid (uid of something like "guest" or "defaultuser" or whatever)

This behaviour might be acceptable for a specific application to allow access to some common feature or information. But for SSSD which manages the system-wide mapping this would imo be highly unexpected because it will not be obvious for a user logging in that he will share the uid with many other users and all his data is accessible for the other users as well.

3. query AD for the Unix uid/gid and if that user is not configured with a uid map algorithmically

Currently only all users and groups get an algorithmically mapped POSIX ID if ldap_id_mapping=True. While it would be technical possible to reserve a id range for POSIX ID coming from AD and not use this id range for the algorithmic mapping I was so far reluctant to implement this. The main reason is that imo there is no clear way how to handle changes on the AD side. E.g. if the user is created first on AD without the POSIX IDs assigned and the next day an admin sees that there is a new user and set a POSIX UID and GID for the new user. Some systems might have already looked up the user and have assigned a POSIX ID algorithmically because the ID was not set in AD. Other systems which will look up the user after the admin added the ID will use the ID from AD. While this might be even acceptable in an environment without share storage it will still might lead to a change of the UID on a system where the cache of SSSD is lost.

I'd be happy to hear if there are ways to solve this?

Btw, with the help of local id overrides it would be possible to assign IDs algorithmically to all users and groups but override the IDs for those users and groups which have an ID assigned in AD if they are needed to compatibility. But you have to read the IDs from AD manually e.g. with ldapsearch and add them with sss_override utility on every client running SSSD.

HTH

bye, Sumit

I didn't see much useful on this topic at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...

If sssd doesn't do that, is this a case where winbind can do it better? or is there a way to configure nssswitch passwd line to fallback to a 3rd trivial alternative (files sss default e.g.) that provides a default uid for a user@domain who does not have a uid/gid configured in AD? _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org

On 9 February 2017 at 19:06, smfrench@gmail.com wrote:

One of the more common cases for sssd (or winbind) with RFC2307 seems to be getting uids/gids from Active Directory domains, but few Active Directories have all of their users/groups configured for the POSIX uid/gid.

How can you configure sssd behavior for this common case (among the three behaviors that might be desired):

1. query AD for the Unix uid/gid and fail if that particular user is not configured with a uid (this seems to be what sss always does and isn't really practical given how unlikely that AD is configured perfectly for unix uids)

FWIW, my company found 1) pretty practical, as I wrote a pretty short bit of Powershell which looks through AD for users and groups without POSIX attributes, and sets them (UID/GID becomes the user's RID + a static offset). This script runs every hour, and means all AD users and groups have POSIX attributes.

Cheers,

John