#2070 The present sssd-ad is unable to pull RFC2307 attributes from all domains in a forest
Closed: Fixed None Opened 5 years ago by simpfeld.

At the present time sssd-ad can only pull RFC2307 attributes for users and groups for the domain the system is joined to (the other domains in a forest (trusted domains) at present have to be mapped ids).

There is an issue with the fact that the same uid/gid could have been used on multiple domains. If such an option I talks about here was possible, having the same ids on multiple domains would essentially be undefined (up to the admins to ensure this didn't happen (maybe with tools)). Unless someone can think of a better approach here.

The use of id_mapping isn't so useful in a large company (or only useful 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 between Windows and Linux) it should never be used.

This feature is important because:

1/ 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.

2/ 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). Also allows integration with non-SSSD based Linux or Unix AD integration systems, they will have the same uid/gid data.

3/ Users can and do move between domains as they change location for example. Their uid should follow them. Or a group if moved domain.

4/ Mapping schemes don't allow migration from other directory services (or local users) where uid/gid's have to be maintained.


How does it work in 1.11? This is filed against master so it seems that our implementation in 1.11 has a flaw. Does it? IMO this feature makes perfect sense and should be a part of 1.11.x.

Wait! And how does it work in the trust case? If I have IPA trust two domains and each has POSIX attributes what SSSD would do? I hope it would pull POSIX attributes from each of the domains to serve them to IPA. Is this the case? Would turning "server mode" then be a solution for this case?

I found this issue on F19 with 1.11.0 , didn't know which version to target for as I wasn't sure where you were in the release cycle. Resolving as soon as is good for me.

Not sure on the second comment, don't know on the IPA case you mention as I have an AD issue. Under AD you only get POSIX attributes from the joined domain and not any trusted ones. I'm talking only about trusted domains (as in domains in an AD forest). Not sure about the "server mode" comment...

Replying to [comment:3 simpfeld]:

I found this issue on F19 with 1.11.0 , didn't know which version to target for as I wasn't sure where you were in the release cycle. Resolving as soon as is good for me.

Not sure on the second comment, don't know on the IPA case you mention as I have an AD issue. Under AD you only get POSIX attributes from the joined domain and not any trusted ones. I'm talking only about trusted domains (as in domains in an AD forest). Not sure about the "server mode" comment...

Wouldn't it just work if you configure SSSD to recognize individual domains independently instead of relying on the trust? If you have 4 domains in the forest you can configure 4 domains explicitly and the 2307 should work for each of the domains, at least this is what I would expect. And this is what I would expect when SSSD is configured in server mode with IPA (that was the comment about IPA). So may be setting the configuration to be like in the server mode for IPA not actually being on IPA server would address your use case?

These design questions are more targeted to the development team.

Thanks!

Replying to [comment:1 dpal]:

How does it work in 1.11? This is filed against master so it seems that our implementation in 1.11 has a flaw. Does it? IMO this feature makes perfect sense and should be a part of 1.11.x.

The problem is that the POSIX attributes are not replicated to the Global Catalog by default so there is no way of telling if they are present short of trying and failing.

Replying to [comment:2 dpal]:

Wait! And how does it work in the trust case? If I have IPA trust two domains and each has POSIX attributes what SSSD would do? I hope it would pull POSIX attributes from each of the domains to serve them to IPA. Is this the case? Would turning "server mode" then be a solution for this case?

In the trust case we don't talk to Global Catalog, but to LDAP port of AD which has the attributes by default.

The code is already there in 1.11 just not enabled, so I'll remove the RFE tag.

summary: [RFE] The present sssd-ad is unable to pull RFC2307 attributes from all domains in a forest => The present sssd-ad is unable to pull RFC2307 attributes from all domains in a forest

As agreed in an internal discussion we would always talk to the GC and document that you need to replicate the POSIX attributes to GC if using them.

As another step, if there are environments that don't want to or can't replicate the POSIX attributes, we can talk to the other DCs ourselves.

owner: somebody => jhrozek
status: new => assigned

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.11.1

Fields changed

patch: 0 => 1

resolution: => fixed
status: assigned => closed

Fields changed

changelog: => The SSSD is now able to sue POSIX attributes for users and groups in trusted domains in the same forest, as long as the attributes are replicated to the Global Catalog.

Metadata Update from @simpfeld:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.11.1

2 years ago

Login to comment on this ticket.

Metadata