Learn more about these different git repos.
Other Git URLs
In Active Directory it seems to be somewhat common to put an email-address into the userPrincipalName attribute.
In our case this email-address is completely different from user@realm and thus pam_sss will not work if ldap_user_principal is set to userPrincipalName in sssd.conf.
As a workaround it is currently possible to set ldap_user_principal to sAMAccountName (which matches the kerberos username). This way it will be possible to login using the kerberos username but it is impossible to login using the email-address.
On windows machines it is possible to login using either attribute. The one from sAMAccountName as well as the one from userPrincipalName.
It looks like we were operating on an incorrect assumption about the meaning of the userPrincipalName attribute in Active Directory. Our expectation is that it should hold the complete Kerberos principal necessary for authenticating the user. However, it looks like Active Directory does not guarantee this, and instead uses the convention of email address here instead of Kerberos principal.
With that in mind, it's probably best that we just default this option to point to samAccountName when using the AD provider and update our documentation to point to it.
One thing I'm unclear on: are you expecting to be able to log into a Linux machine by presenting the user's email address as the login name, rather than their samAccountName? If so, this is a more involved problem and should probably be tracked as a separate enhancement.
The reason we can't authenticate with an email address right now is that we're parsing the principal and attempting to use the portion after the @ sign to determine what Kerberos server is authoritative for it. I don't think we're ever likely to support this, as the lookup costs are pretty high (there are reasons Microsoft can get away with this, not least because Windows machines are guaranteed to be joined to a single domain and use trust relationships to reach other KDCs).
My recommendation here would be to just change the default value of ldap_user_principal to be samAccountName for the AD provider and the LDAP provider when used with the AD schema. This should have minimal impact for greatest effect.
May be I am wrong but if we can have a domain to realm mapping stored somewhere we would probably be able to determine the right realm even by the email address.
We need to use the right name type as well.
Also we may not be able to sue domain_realm mapping, the way AD clients do it is by always trying with their own KDC first and relying on referrals returned if it is not the right one.
I think we should do the same.
milestone: NEEDS_TRIAGE => SSSD 1.11 beta
rhbz: => todo
summary: Allow email-address in ldap_user_principal => [RFE] Allow email-address in ldap_user_principal
type: defect => enhancement
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1088402 (Red Hat Enterprise Linux 6)
rhbz: todo => [https://bugzilla.redhat.com/show_bug.cgi?id=1088402 1088402]
owner: somebody => sbose
review: => 0
status: new => assigned
patch: 0 => 1
resolution: => fixed
status: assigned => closed
milestone: SSSD 1.13 beta => SSSD 1.12.1
Metadata Update from @giggls:
- Issue assigned to sbose
- Issue set to the milestone: SSSD 1.12.1
SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here:
If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.
Thank you for understanding. We apologize for all inconvenience.
to comment on this ticket.