diff options
author | Sumit Bose <sbose@redhat.com> | 2013-03-25 17:41:19 +0100 |
---|---|---|
committer | Jakub Hrozek <jhrozek@redhat.com> | 2013-04-22 15:33:40 +0200 |
commit | edaa983d094c239c3e1ba667bcd20ed3934be3b8 (patch) | |
tree | 3772f4bd4c396cb72784c698a2e66d911793aeff /src/tests/krb5_child-test.c | |
parent | b3e247cef1f1c81a24ae7759903c11289744e94c (diff) | |
download | sssd-edaa983d094c239c3e1ba667bcd20ed3934be3b8.tar.gz sssd-edaa983d094c239c3e1ba667bcd20ed3934be3b8.tar.bz2 sssd-edaa983d094c239c3e1ba667bcd20ed3934be3b8.zip |
Allow usage of enterprise principals
Enterprise principals are currently most useful for the AD provider and
hence enabled here by default while for the other Kerberos based
authentication providers they are disabled by default.
If additional UPN suffixes are configured for the AD domain the user
principal stored in the AD LDAP server might not contain the real
Kerberos realm of the AD domain but one of the additional suffixes which
might be completely randomly chooses, e.g. are not related to any
existing DNS domain. This make it hard for a client to figure out the
right KDC to send requests to.
To get around this enterprise principals (see
http://tools.ietf.org/html/rfc6806 for details) were introduced.
Basically a default realm is added to the principal so that the Kerberos
client libraries at least know where to send the request to. It is not
in the responsibility of the KDC to either handle the request itself,
return a client referral if he thinks a different KDC can handle the
request or return and error. This feature is also use to allow
authentication in AD environments with cross forest trusts.
Fixes https://fedorahosted.org/sssd/ticket/1842
Diffstat (limited to 'src/tests/krb5_child-test.c')
0 files changed, 0 insertions, 0 deletions