The attached patch fixes issues with logging in as users without an explicit UPN in a trust scenario. The simplest reproducer is to log in as Administrator or configure sssd to not look up the principal attribute by adding this to the server's sssd.conf subdomain_inherit = ldap_user_principal ldap_user_principal = nosuchatt
Please see the commit message for more details.
On Tue, Aug 09, 2016 at 10:27:32PM +0200, Jakub Hrozek wrote:
The attached patch fixes issues with logging in as users without an explicit UPN in a trust scenario. The simplest reproducer is to log in as Administrator or configure sssd to not look up the principal attribute by adding this to the server's sssd.conf subdomain_inherit = ldap_user_principal ldap_user_principal = nosuchatt
Please see the commit message for more details.
Patch looks good, works as expected and passes CI http://sssd-ci.duckdns.org/logs/job/52/48/summary.html.
ACK.
I wasn't able to reproduce the issue first until I realized I had enterprise principal enabled which made the mal-formed principals work as expected :-)
bye, Sumit
On (26/08/16 19:02), Sumit Bose wrote:
On Tue, Aug 09, 2016 at 10:27:32PM +0200, Jakub Hrozek wrote:
The attached patch fixes issues with logging in as users without an explicit UPN in a trust scenario. The simplest reproducer is to log in as Administrator or configure sssd to not look up the principal attribute by adding this to the server's sssd.conf subdomain_inherit = ldap_user_principal ldap_user_principal = nosuchatt
Please see the commit message for more details.
Patch looks good, works as expected and passes CI http://sssd-ci.duckdns.org/logs/job/52/48/summary.html.
ACK.
I wasn't able to reproduce the issue first until I realized I had enterprise principal enabled which made the mal-formed principals work as expected :-)
master: * 0302e3e7b3b06b809bd63c7911a42ab3e0a7ebf9
LS
sssd-devel@lists.fedorahosted.org