On Tue, Jun 30, 2015 at 02:00:16PM +0200, Jakub Hrozek wrote:

On Tue, Jun 30, 2015 at 01:47:01PM +0200, Jan Pazdziora wrote:

...

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.

That really depends on what the expectation is and what is the use-case.

The expectation is for the user to be able to authenticate either via Kerberos or via PAM (with optional subsequent access check) a have the user identifier (the long one) uniquely identify the user record from application's point of view. So ideally it needs to be the same string.

Currently the code seems to return the name of the sssd domain section the user authenticated with. That is more or less just a label and can be really anything.

On the other hand, that's the part after the '@' character which allows the clients to ask sssd daemon questions (via PAM, via D-Bus) and know that they uniquely (from the SSSD point of view) address that single user record they want. And I assume SSSD uses it internally as well for namespacing purposes. So the admin is not expected to change that section every hour, it's supposed to be reasonably stable.

If for the applications realm is also useful, then a) the app can query the sssd dbus interface for the matching realm for the domain b) we can also return the realm, although the expectations should be set right in documentation that not all domain types have the realm info (LDAP domain for example)

So how about the reverse mapping? Going from realm to SSSD domain / section? Currently for example in mod_authnz_pam we consider them interchangeable -- we just take the principal name (either fully qualified or not) and pass it to pam_sss.so via pam_acct_mgmt to evaluate the access check. Should we get the SSSD domain / section value for that?

On Tue, Jun 30, 2015 at 01:47:01PM +0200, Jan Pazdziora wrote:

On Wed, Jun 10, 2015 at 03:36:04PM +0200, Michal Židek wrote:

...

See the attached patch that adds the AUTH_DOMAIN variable to pam reply.

Ticket: https://fedorahosted.org/sssd/ticket/2476

Thanks, Michal

URL: https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20150610/c84359a5/attachment.bin

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.

How are you planning to use the realm later on in your Apache module?

bye, Sumit

-- Jan Pazdziora | adelton at #ipa*, #brno 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

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@xxexample.test. That is true, however when I kinit admin, all the following commands

ssh admin@xxexample.test@client.example.tst id ssh admin@XXEXAMPLE.TEST@client.example.tst id ssh admin@example.test@client.example.tst id ssh admin@EXAMPLE.TEST@client.example.tst id

print

uid=1939400000(admin@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@client.example.tst

even if there is no example.test domain defined in sssd.conf anymore?

On Thu, Jul 09, 2015 at 11:33:11AM +0200, Sumit Bose wrote:

Most probable because admin@EXAMPLE.TEST is the Kerberos principal of your user. If SSSD cannot find a matching user name and the name contains an '@' it tries to find a Kerberos principal which matches the full given name.

But realms are case sensitive, aren't they? So while it should work for admin@EXAMPLE.TEST, it should not for admin@example.test.

On Thu, Jul 09, 2015 at 12:35:51PM +0200, Sumit Bose wrote:

On Thu, Jul 09, 2015 at 11:50:06AM +0200, Jan Pazdziora wrote:

...

On Thu, Jul 09, 2015 at 11:33:11AM +0200, Sumit Bose wrote:

...

Most probable because admin@EXAMPLE.TEST is the Kerberos principal of your user. If SSSD cannot find a matching user name and the name contains an '@' it tries to find a Kerberos principal which matches the full given name.

But realms are case sensitive, aren't they? So while it should work for admin@EXAMPLE.TEST, it should not for admin@example.test.

you are absolutely correct, not only realms but the whole principal is case-sensitive. But we want to play nice with AD users and make it easy to log in with the alternative domain suffix feature (some call it log in with email address because they often look the same) which is often used in larger forests.

Since AD treats the names and principals case-in-sensitive most AD user will not know the correct spelling and so we treat them case-in-sensitive in SSSD as well.

bye, Sumit

Restarting stalled thread..

Shall we push this patch to master since it looks correct code wise and doesn't look like it should regress anything or shall we wait for more complete solution in 1.14 that would also address domain-vs-realm concerns?

On Tue, Sep 01, 2015 at 11:06:59AM +0200, Jan Pazdziora wrote:

On Tue, Sep 01, 2015 at 11:00:26AM +0200, Jakub Hrozek wrote:

...

Shall we push this patch to master since it looks correct code wise and doesn't look like it should regress anything or shall we wait for more complete solution in 1.14 that would also address domain-vs-realm concerns?

Is there a risk that the domain-vs-realm solution will cause us want to revert this change? My feeling is it won't, so I'd vote for getting it in master now.

I don't think the code the current patch touches would change, the environment variable clearly states it's domain and the concept of domains is very unlikely to change, ever.

Of course, the domain-vs-realm work can cause the codepaths that populate the value to change but the value and its semantics is likely to stay.

I think it's more likely there would be additional variables which might render this one obsolete but in principle I agree.

On 09/13/2015 11:30 AM, Jakub Hrozek wrote:

On Wed, Jun 10, 2015 at 03:36:04PM +0200, Michal Židek wrote:

...

Hi!

See the attached patch that adds the AUTH_DOMAIN variable to pam reply.

Ticket: https://fedorahosted.org/sssd/ticket/2476

Thanks, Michal

There are some issues with PAM srv test after applying this patch, see: http://sssd-ci.duckdns.org/logs/job/26/50/summary.html

It does not make sense to me, why the test fails only when running under Valgrind. It should fail always. I will need time to investigate the tests. Feel free to push it out of the current milestone it does not seem to be very important.

Michal