Can't set up login as "User logon name"

[vorbster]

I'm trying to set up SSSD so the users could authenticate against AD using their logon names. In ADUC I can see it as "User logon name", in LDAP it is UPN without suffix. I can't use samaccountname for these purposes because sometimes it doesn't match user logon name.

Our AD structure is something like this:

Domain: ad.corpdomain.com
UPN: domainuser5@company.com (same as email - but it's different than domain name)
Samaccountname: domainuser

It looks like SSSD is unable to separate username from the suffix in UPN so I could authenticate as domainuser5, it always needs "domainuser5@company.com".

In sssd.conf I have following:

ldap_user_name = UserPrincipalName
*_provider = ad (all providers set to ad)
use_fully_qualified_names = false

If I run "id domainuser5" it says user doesn't exist, if I run "id domainuser@company.com" it's successful but I don't want that domain part. Since we have only 1 enterprise domain suffix I don't care about overlapping.

I would like to know if it's possible to configure SSSD so I could user domainuser5 everywhere, if yes - how. Currently VAS can do that, I'm trying to replace it with SSSD.

Thanks!

[yrro]

This sounds like a problem I ran into recently and described here:

https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/6I35UAQEDSLQBDWWR56UUHC2IISXLLMN/

Namely, we have AD users where the domain in their userPrincipalName is not the AD domain's DNS domain name. At first I thought this was incorrect but after reading through these blog posts 1 2 3 I have learned that Windows doesn't really use the userPrincipalName (called the "explicit UPN" in the blog posts) for anything other than user account lookup!

The actual Kerberos TGT is always issued for the "implicit UPN" which is formed as {SAM-Account-Name} @ {DNS-Host-Name} and that is what sssd should be using to authenticate a user.

[vorbster]

Yes sounds like you're having a same issue. The problem is that users don't login to their Windows machines using samaccountname, they use the first part of eUPN. They should be able to use the same login for Linux machines, otherwise it's going to be a mess. I don't know how but VAS does it - SSSD should be able too.

[sumit-bose]

Hi,

SSSD treats only the full value of the userPrincipalName attribute as valid name, this is independent of the use_fully_qualified_names option. So it is expected that only domainuser5@company.com.

You said:

In ADUC I can see it as "User logon name", in LDAP it is UPN without suffix.

Does this mean that e.g. ldapsearch only returns domainuser5 as value for the userPrincipalName attribute?

bye,
Sumit

[vorbster]

Hi Sumit,

No, ldapsearch returns with the suffix. I'm attaching a screenshot as an example, so ldapsearch I would see "bella@deborah.com" but user should be able to login as "bella" without typing the whole thing.

Thanks

[sumit-bose]

Hi,

thanks for the clarification. As said before this is currently expected behavior, the UPN is always treated as a whole so bella@deborah.com or with your previous example domainuser5@company.com.

SSSD only relies on information available in LDAP. So if there is a different LDAP attribute which contains only the expected short name (without and domain suffix) for all users this can as a replacement for the default samAccountName which I understood does not work in your case.

I guess VAS is using RPC calls like e.g. IDL_DRSCrackNames (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/9b4bfb44-6656-4404-bcc8-dc88111658b3) to let AD figure out what would be the best match for the provided name but as said SSSD only uses LDAP and not RPC.

bye,
Sumit

[vorbster]

Thanks Sumit for the explanation, I'll have to search for a workaround.