Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
vorbster opened this issue Jul 23, 2020 · 6 comments
Closed

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

vorbster opened this issue Jul 23, 2020 · 6 comments

Comments

@vorbster
Copy link

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
Copy link
Contributor

yrro commented Jul 27, 2020

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

vorbster commented Aug 4, 2020

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.
ad-user-properties-accounts-tab

Thanks

@sumit-bose
Copy link
Contributor

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
Copy link
Author

vorbster commented Aug 5, 2020

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

@andreboscatto andreboscatto closed this as not planned Won't fix, can't repro, duplicate, stale Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants