ldap backend using full_name_format to look for user information

[luizluca]

Hello,

I'm using sssd-2.5.2 from openSUSE Tumbleweed. I have two domains configured using ldap id backend. In order to resolve conflicts, I'm using

[domain1.com]
full_name_format =%1$s@dom1

[domain2.com]
full_name_format =%1$s@dom2

I can login normally but it fails to get additional groups. I can see only the primary group. The log shows that sdap_get_initgr_send is looking for:

[(&(|(userPrincipalName=user1@dom1)(mail=user1@dom1)(userPrincipalName=user1\\@dom1@DOMAIN1.COM))(objectclass=user)(objectSID=*))][DC=domain1,DC=com]

I don't see this problem with ad id backend. It seems that it considered the login formatted with full_name_format as the new "login" for that domain while I expected full_name_format to only affect the unix name. Shouldn't it chop "@.*" from usernames before going to LDAP search?

If I change to full_name_format = %1$s@domain1.com, it does work but it turn the login into a much longer string (my full domain with "@" is 24 chars long).

Also, if I call id user2@dom1, it will fails until user2 is loaded.

$ id user2@dom1
id: 'user2@dom1': no such user
$ id user2
uid=12345(user2@dom1) gid=54321 groups=54321
$ id user2@dom1
uid=12345(user2@dom1) gid=54321 groups=54321

Again, I also didn't saw this problem with ad id backend.

[sumit-bose]

Hi,

have you tried to use use_fully_qualified_names = True in the [domain/...] sections instead of changing full_name_format?

bye, Sumit

[luizluca]

Hi,

have you tried to use use_fully_qualified_names = True in the [domain/...] sections instead of changing full_name_format?

bye, Sumit

Indeed it works as expected. I had problem with a shorter (non FQDN) domain names for ad backend. But it seems to be a bug for ad id backend, not ldap one.

Anyway, should ldap id backend use full_name_format to generate a canonical name for ldap searches?

[sumit-bose]

Anyway, should ldap id backend use full_name_format to generate a canonical name for ldap searches?

Hi,

no, it should not and I think in general it does not. The log snippet you have send about with the search filter is the fallback to search for Kerberos user principals and email addresses with the fully-qualified name if the user was not found which the short name. You should find a LDAP searchfilter with uid=shortname or sAMAccountName=shortname (depending on your sssd.conf settings) earlier in the logs.

HTH

bye, Sumit

[luizluca]

I see only two ldap_search (debug level 10). Between them, I added the last mention of luizluca@mydomain1.com (using sssd.conf domain) and the first mention of luizluca@mydomain (as in full_name_format).

...
(2021-08-09 17:09:49): [be[mydomain1.com]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=luizluca)(objectclass=user)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][DC=mydomain1,DC=com].
...
(2021-08-09 17:09:49): [be[mydomain1.com]] [sysdb_store_user] (0x0400): User "luizluca@mydomain1.com" has been stored
...
(2021-08-09 17:09:50): [be[mydomain1.com]] [dp_get_account_info_send] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][name=luizluca@mydomain1]
...
(2021-08-09 17:09:50): [be[mydomain1.com]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(userPrincipalName=luizluca@mydomain1)(mail=luizluca@mydomain1)(userPrincipalName=luizluca\\@mydomain1@REDETRESC.TRE-SC.GOV.BR))(objectclass=user)(&(uidNumber=*)(!(uidNumber=0))))][DC=mydomain1,DC=com].

In the end, the user got no supplementary groups. Only "domain users" (the primary group) was listed.

This is the full but redacted log:

sssd_mydomain1.com.log

[sumit-bose]

Hi,

thanks for the logs, now I understand what is happening.

SSSD will split the fully-qualified name into the short name and the domain part at the '@' character. The domain part is important to where SSSD will search for the user. The domains SSSD knows about with id_provider = ldap are the domains from sssd.conf, i.e. domain1.com and domain2.com, but SSSD does not know about dom1 and dom2.

When you call id luizluca the id command will first do the equivalent of getent passwd user2, this is the first search you see in the logs, and based on your configuration SSSD will return the name luizluca@mydomain1. The second step of the id command is the search for the primary group with GID 30000. Finally id will send a request to lookup the group memberships of the user and will use the name returned by the first request luizluca@mydomain1. Since the domain mydomain1 is not know to SSSD, SSSD assumes that the input might be an email address or a Kerberos principal and continues with the fully-qualified name as can be seen in the search filter.

To fix this you should make SSSD aware of the domain names you use in the full_name_format and this easiest way I can think of is just to rename the domains

[sssd]
domains = mydomain1, mydomain2
..
[domain/mydomain1]
dns_discovery_domain = mydomain1.com
krb5_realm = MYDOMAIN1.COM
....
[domain/mydomain2]
dns_discovery_domain = mydomain2.com
krb5_realm = MYDOMAIN2.COM
...

Now you can remove the full_name_format option as well since the fully-qualified names will already look how you expect them. The dns_discovery_domain and krb5_realm options should be added to make sure finding LDAP servers and KDC will still work with the proper domain and realm names.

HTH

bye, Sumit

[luizluca]

Hi,

thanks for the logs, now I understand what is happening.

SSSD will split the fully-qualified name into the short name and the domain part at the '@' character. The domain part is important to where SSSD will search for the user. The domains SSSD knows about with id_provider = ldap are the domains from sssd.conf, i.e. domain1.com and domain2.com, but SSSD does not know about dom1 and dom2.

When you call id luizluca the id command will first do the equivalent of getent passwd user2, this is the first search you see in the logs, and based on your configuration SSSD will return the name luizluca@mydomain1. The second step of the id command is the search for the primary group with GID 30000. Finally id will send a request to lookup the group memberships of the user and will use the name returned by the first request luizluca@mydomain1. Since the domain mydomain1 is not know to SSSD, SSSD assumes that the input might be an email address or a Kerberos principal and continues with the fully-qualified name as can be seen in the search filter.

To fix this you should make SSSD aware of the domain names you use in the full_name_format and this easiest way I can think of is just to rename the domains

[sssd]
domains = mydomain1, mydomain2
..
[domain/mydomain1]
dns_discovery_domain = mydomain1.com
krb5_realm = MYDOMAIN1.COM
....
[domain/mydomain2]
dns_discovery_domain = mydomain2.com
krb5_realm = MYDOMAIN2.COM
...

Now you can remove the full_name_format option as well since the fully-qualified names will already look how you expect them. The dns_discovery_domain and krb5_realm options should be added to make sure finding LDAP servers and KDC will still work with the proper domain and realm names.

Yes, that fixed my issue. Indeed, I've been doing that since your first comment and I already applied it to production. My incident is already fixed. Thanks!

I reverted that change in a test machine just to provide sssd with a good complete log. Isn't this an issue with sssd code? If full_name_format can modify the username, sssd cannot trust that information for further searches. It could keep a map from full_name_format generated username to the user associated with a sssd domain as it cannot be sure the user used a user@domain format. Anyway, it would be better if the map was dynamic as the user might still be unknown (although the problem seems to be only after the user was loaded at least once). Maybe some scanf magic with full_name_format could help. I really don't know sssd internals.

[andreboscatto]

Dear Contributor/User,

Recognizing the importance of addressing enhancements, bugs, and issues for the SSSD project's quality and reliability, we also need to consider our long-term goals and resource constraints.

After thoughtful consideration, regrettably, we are unable to address this request at this time. To avoid any misconception, we're closing it; however, we encourage continued collaboration and contributions from anyone interested.

We apologize for any inconvenience and appreciate your understanding of our resource limitations. While you're welcome to open a new issue (or reopen this one), immediate attention may not be guaranteed due to competing priorities.

Thank you once again for sharing your feedback. We look forward to ongoing collaboration to deliver the best possible solutions, supporting in any way we can.

Best regards, André Boscatto