sssd with AD/krb5 authentication and non-standard userPrincipalName

[Rosile, Mike]

I have somewhat of a unique situation which causes the userPrincipalName value in Active
Directory to use a public DNS domain as its realm, but the Active Directory was designed
with a private DNS domain.

For example, user John Smith would typically be
[e-mail]<mailto:[e-mail]> but his userPrincipalName is
[e-mail]<mailto:[e-mail]>.

Unfortunately when trying to authenticate with pam_sss, the "krb5" child process
will complain that the KDC is not local to the realm.  The KDC might be something like
kdc.example.local, and in this instance the realm is EXAMPLE.COM.  Same situation if I try
to `kinit [e-mail]`<mailto:[e-mail]%60>, the error about the KDC
not being local to Realm occurs.

Is there some other way that sssd could construct the userPrincipalName instead of me
trying to create and populate a custom AD attribute?
--
Mike

[Jakub Hrozek]

On Wed, Sep 26, 2012 at 07:37:50PM +0000, Rosile, Mike wrote:
>  I have somewhat of a unique situation which causes the
> userPrincipalName value in Active Directory to use a public DNS domain as its realm, but
> the Active Directory was designed with a private DNS domain.
>  
>  For example, user John Smith would typically be
> [e-mail]<mailto:[e-mail]> but his userPrincipalName is
> [e-mail]<mailto:[e-mail]>.
>  
>  Unfortunately when trying to authenticate with pam_sss, the "krb5" child
> process will complain that the KDC is not local to the realm.  The KDC might be something
> like kdc.example.local, and in this instance the realm is EXAMPLE.COM.  Same situation if
> I try to `kinit [e-mail]`<mailto:[e-mail]%60>, the error about
> the KDC not being local to Realm occurs.
>  
>  Is there some other way that sssd could construct the userPrincipalName instead of me
> trying to create and populate a custom AD attribute?
>  --
>  Mike
>   
Would user@REALM (where REALM is the krb5_realm option value) be the
correct principal for you?

If so, then there is a simple workaround that Stephen Gallagher came up with --
you could set the ldap_user_principal config option to some attribute
that does not exist which would make the SSSD default to user@REALM..

Your situation is not as unique as you might think, this is actually the
second similar feature request we've gotten this week. I think we should
think about introducing a new option:
    https://fedorahosted.org/sssd/ticket/1545