On Tue, Jun 30, 2015 at 02:09:31PM +0200, Sumit Bose wrote: > > It does the right thing and I'm able to get the value back via > > pam_getenv(pamh, PAM_ENV_AUTH_DOMAIN) in my Apache module. > > > > My only concern is that the domain name as returned by sssd is > > lowercase which does not really match the realm as seen by say > > mod_auth_kerb or mod_auth_gssapi. But I guess uppercasing the string > > is up to consumer of that value. > > hm, the ticket said domain and not realm and unfortunately there might > be cases where the upper-case domain name does not match the realm used > for authentication.
I've tried to check the behaviour with ssh and it's even more confusing. I have IPA-enrolled machine, IPA domain example.test, realm EXAMPLE.TEST. I've tried to isolate the SSSD domain namespace from the rest. I've changed [domain/example.test] to [domain/xxexample.test] and domains = example.test to domains = xxexample.test in sssd.conf, and I've set use_fully_qualified_names = True. My expectation is that the canonical username of the user will be $u...@xxexample.test. That is true, however when I kinit admin, all the following commands ssh ad...@xxexample.test@client.example.tst id ssh ad...@xxexample.test@client.example.tst id ssh ad...@example.test@client.example.tst id ssh ad...@example.test@client.example.tst id print uid=1939400000(ad...@xxexample.test) ... So it's nice that the canonical fully qualified name uses the SSSD domain (the same which I expect PAM stack to return in PAM_ENV_AUTH_DOMAIN), but: why am I able to authenticate as ad...@example.test@client.example.tst even if there is no example.test domain defined in sssd.conf anymore? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel