Bug 1001318

Created attachment 790703 [details]
sssd.conf

Can you attach the full logs, especially the sssd_domain.name.log would be userful.

(In reply to Sumit Bose from comment #2)
> Can you attach the full logs, especially the sssd_domain.name.log would be
> userful.

Colin sent the logs privately and I'll forward them to you.

Thank you for the log, they helped a lot. While trying to resolve the Globacl Catalog for some reasons SSSD uses only AAAA queries (IPv6 addresses) and does not try to find IPv4 adresses. I can reproduce this issue locally and will ook for a fix.

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2063

Can you try to set 'dyndns_update = False' in the [domain/iongeo.lan] section of sssd.conf and try to look up the user from the other domain again?

Didn't seem to workaround the issue. Unless I need to do some flushing of caches

Additionally you can try to set 'lookup_family_order = ipv4_only'. Nevertheless it would be nice if you can send new logs with one or both of the parameters set.

got the logs, thank you

Tried with no 'lookup_family_order = ipv4_only' and 'dyndns_update = False' . This seemed to still be unable to resolve other trusted domains.

The issue with the AAAA queries is solved with workaround. I will prepare a patch so that the workaround is not needed anymore.

Now you are hitting a configuration issue. You are using 'ldap_id_mapping = False' i.e. you would like to use the POSIX UID and GID stored on AD. In older versions of SSSD the whole POSIX ID range 1-2**(31) is reserved for the domain. To avoid regression with older installation this is true for the current version as well. Because of this there are no free IDs for the other domains.

To get around this you can either set 'ldap_id_mapping = True' and delete the cache file. Or the new options ldap_min_id and ldap_max_id can be used to restrict the ID range for the POSIX IDs read from the AD server. Please note the for the other domains in the forest SID based ID mapping will be used to avoid ID conflicts.

I'd like to be able to pull RFC2307 attributes from all the domains in the forest. 

We have no ID collisions in the forest, the tool we use to change these doesn't allow them to exist, not sure if this is the tool or maybe now even AD itself doesn't allow this to happen (given RFC2307 is now shipped at standard in AD). It's an interesting question. But I don't think a config option should be unavailable just cause someone could do something that is very unwise in the first place.

Either way I think this should be an option, at least, like the ability to flatten usernames across all domains I logged as an RFE at Bug#1001325. Both these two things are supported by other third party AD Linux integration solutions and for good reasons. 

Firstly it gives a consistent UID/GID space across all domains (the forest should behave (and does in general) like a single large domain to end users) and all attributes should be the same to any joined Linux system, whatever the domain.

Secondly UID/GID information should be shareable/consistent with non-Linux applications (e.g the Windows NFS servers and other SFU services) a mapping scheme will not allow this (and unnecessary given we have this data in RFC2307 attributes). 

Thirdly, users can and do move between domains as they change location for example. Their UID should follow them (and on my RFE bug too their username shouldn't change as far as Linux systems are concerned). 

Forthly, mapping schemes don't allow migration from other directory services (or local users) where UID/GID's have to be maintained. 

I'd suggest that that id_mapping is only useful in a small company (or where the Linux admins don't have full/sufficient AD rights). When you start scaling to multiple domains and large companies with fully working RFC2307 setups (easy to get with a reasonable commitment to integration with Windows/Linux) it should never be used. It's fraught with problems....

Do you also make sure that POSIX attributes are replicated to Global Catalog?  They are not by default..

True. But we do have these in the Global Catalog as it's a recommended performance enhancement if using RFC2307 attributes in a forest wide sense. 

Other AD integration technologies don't require this to though to allow RFC2307 to be used forest wide. As I say it's just a performance enhancement.

(In reply to Colin Simpson from comment #12)
> I'd like to be able to pull RFC2307 attributes from all the domains in the
> forest. 

I had expected that such a request will come sooner or later. We have chosen a defensive approach for the start, because our view of a forest is a collection of independently managed domains. In your environment the whole forest is managed centrally by an external tool (at least with respect to the RFC2307 attributes).

But I agree that if the admin is sure that there are not conflicts it should be possible to make use of this knowledge and use the RFC2307 attributes for the whole forest.
 
> 
> We have no ID collisions in the forest, the tool we use to change these
> doesn't allow them to exist, not sure if this is the tool or maybe now even
> AD itself doesn't allow this to happen (given RFC2307 is now shipped at
> standard in AD). It's an interesting question. But I don't think a config

I just tried and it is possible with AD to create a user with the same short name and the same POSIX UID in two different domains of a forest even in the same NIS domain.

> option should be unavailable just cause someone could do something that is
> very unwise in the first place.
> 
> Either way I think this should be an option, at least, like the ability to
> flatten usernames across all domains I logged as an RFE at Bug#1001325. Both
> these two things are supported by other third party AD Linux integration
> solutions and for good reasons. 

Would you mind to open two RFEs in SSSDs own ticket tracker https://fedorahosted.org/sssd/newticket . If you prefer I can do it as well. I think two are better because from my point of view the ID issue is easier to solve than the name issue.

> 
> Firstly it gives a consistent UID/GID space across all domains (the forest
> should behave (and does in general) like a single large domain to end users)
> and all attributes should be the same to any joined Linux system, whatever
> the domain.
> 
> Secondly UID/GID information should be shareable/consistent with non-Linux
> applications (e.g the Windows NFS servers and other SFU services) a mapping
> scheme will not allow this (and unnecessary given we have this data in
> RFC2307 attributes). 
> 
> Thirdly, users can and do move between domains as they change location for
> example. Their UID should follow them (and on my RFE bug too their username
> shouldn't change as far as Linux systems are concerned). 
> 
> Forthly, mapping schemes don't allow migration from other directory services
> (or local users) where UID/GID's have to be maintained. 
> 
> I'd suggest that that id_mapping is only useful in a small company (or where
> the Linux admins don't have full/sufficient AD rights). When you start
> scaling to multiple domains and large companies with fully working RFC2307
> setups (easy to get with a reasonable commitment to integration with
> Windows/Linux) it should never be used. It's fraught with problems....

Nevertheless it would be nice to know if with 'ldap_id_mapping = False' or with a restricted LDAP range the user can be resolved or if there is another issue. If you want to test I think it would be best to delete the sssd cache file or move it away so that it can be reused when the config is reset to its old state.

Having in the config file:

dyndns_update = False
lookup_family_order = ipv4_only
ldap_id_mapping = True

Does indeed correctly return user information for other domains:

# getent passwd corp\\prodbuild
prodbuild.lan:*:943823454:943823454:Build User:/home/prodbuild.lan:/bin/bash

As you suspected.

I'll file the upstream RFEs.

Thanks

I have opened two RFEs.

The first one to provide an option to flatten all usernames in the forest (on any domain) is here:

https://fedorahosted.org/sssd/ticket/2069

I have updated the bugzilla RFE I have for this at Bug#1001325 to point at this upstream RFE too.

The second one to pull RFC2307 attributes from all domains in a forest is here:

https://fedorahosted.org/sssd/ticket/2070

Can you verify these have been completed correctly?

Thanks

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2070

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2063

Thank you, the RFEs upstream are fine. I also linked them with the two bugzillas you opened in our inhouse tool to track the changes between Bugzilla and Trac.

(In reply to Colin Simpson from comment #17)
> Having in the config file:
> 
> dyndns_update = False
> lookup_family_order = ipv4_only
> ldap_id_mapping = True
> 
> Does indeed correctly return user information for other domains:
> 
> # getent passwd corp\\prodbuild
> prodbuild.lan:*:943823454:943823454:Build
> User:/home/prodbuild.lan:/bin/bash

Thank you for the confirmation. I'll fix the issue from comment #4 and close this ticket, since your RFEs now have separate tickets.

> 
> As you suspected.
> 
> I'll file the upstream RFEs.
> 
> Thanks

Fixed upstream.

The ability to resolve POSIX attributes was also just added upstream:
master:
    4343b618051d295cbb1a805a85feb117a91c6945
    c2aeea38addda1a07e60adbc3451f11b640f7bf1
    1b870ffa7910879f9310db453a31ab6f06392b9b
    d3e1d88ce7de3216a862b9fe78dc5aa94dcbc14b 
sssd-1-11:
    4b96f0cd6d075bc2aac18ba8368b65aaae41eb06
    2a413fb8751775f04ee989c92effd38299914ce1
    7830aeaa56d9c60438ffbf51130f5f1d223d628b
    85a5643dde73950a9c1e313699e2b7dc5eaa6758

sssd-1.11.1-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/sssd-1.11.1-1.fc19

Package sssd-1.11.1-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.11.1-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-17879/sssd-1.11.1-1.fc19
then log in and leave karma (feedback).

sssd-1.11.1-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.