On Mon, 18 Feb 2013, Brian Cook wrote:
This fixed in.  That makes perfect sense, but nothing in the log made
me think that this was the problem.

There was an auth_to_local rule setup, which I saved, which did not
work.  Is this a bug that we need to open a ticket for?  Seems like
installer is putting an inadequate regular expression in the rule.
Installer does not put auth_to_local rules into /etc/krb5.conf. Since we
don't know what will be your trusted domains until you would really
establish the trust, we cannot fill in proper auth_to_local rule.

That rule has to be written manually, as described in
http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Edit_.2Fetc.2Fkrb5.conf

Log actually hints about it:
Feb 18 16:02:54 ipa1 sshd[21048]: debug3: mm_ssh_gssapi_userok: user not 
authenticated

this is a stage where openssh calls for gss_userok -- is this user which
credentials were already authenticated would be authorized by the local
system? Failure of this call means it was not possible to relate
principal to local account.

The way MIT Kerberos does this action is currently limited to use of
manual mapping rules, either in krb5.conf (auth_to_local) or .k5login.
We hope to get a pluggable interface in future versions of MIT Kerberos
which would allow us to dynamically hook into it on SSSD side and verify
against currently configured list of trusted domains.

--
/ Alexander Bokovoy

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to