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 $USER(a)xxexample.test. That is
true, however when I kinit admin, all the following commands
ssh admin@xxexample.test(a)client.example.tst id
ssh admin@XXEXAMPLE.TEST(a)client.example.tst id
ssh admin@example.test(a)client.example.tst id
ssh admin@EXAMPLE.TEST(a)client.example.tst id
print
uid=1939400000(admin(a)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
admin@example.test(a)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