| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Expanding a principle to an enterprise principal only makes sense if
there is a KDC available which can process it. If we are offline the
plain principal should be used, e.g. to create an expired ccache.
Fixes https://fedorahosted.org/sssd/ticket/2060
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The krb5 child contacts the PAC responder for any user except for the
IPA native users if the PAC is configured. This works fine for the
general case but the ipa_server_mode is a special one. The PAC responder
is there, but since in the server mode we should be operating as AD
provider default, the PAC shouldn't be analyzed either in this case.
|
| | |
|
| |
|
|
| |
https://fedorahosted.org/sssd/ticket/1992
|
| |
|
|
|
|
| |
When renewing a ticket we already know the canonical principal hence it
is not needed to expand it to an enterprise principal but we can contact
the KDC of the corresponding realm directly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
So far we didn't send the PAC of IPA users to the PAC responder during
password authentication because group memberships for IPA users can be
retrieved efficiently with LDAP calls. Recently patches added PAC
support for the AD provider as well and removed the restriction for the
IPA users. This patch restores the original behaviour by introducing a
new flag in struct krb5_ctx which is only set for the IPA provider.
Additionally a different flag is renamed to make it's purpose more
clear.
Fixes https://fedorahosted.org/sssd/ticket/1995
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Definition of structure sss_auth_token was removed from header file
authtok.h and there left only declaration of this structure.
Therefore only way how to use this structure is to use accessory function from
same header file.
To creating new empty authotok can only be used newly created function
sss_authtok_new(). TALLOC context was removed from copy and setter functions,
because pointer to stuct sss_auth_token is used as a memory context.
All declaration of struct sss_auth_token variables was replaced with
pointer to this structure and related changes was made in source code.
Function copy_pam_data can copy from argument src which was dynamically
allocated with function create_pam_data() or zero initialized struct pam_data
allocated on stack.
https://fedorahosted.org/sssd/ticket/1830
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
krb5 1.11 adds support for a new method for responding to
structured data queries. This method, called the responder,
provides an alternative to the prompter interface.
This patch adds support for this method. It takes the password
and provides it via a responder instead of the prompter. In the
case of OTP authentication, it also disables the caching of
credentials (since the credentials are one-time only).
|
| |
|
|
| |
Use the new authtok abstraction and interfaces throught the code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In general Kerberos is case sensitive but the KDC of Active Directory
typically handles request case in-sensitive. In the case where we guess
a user principal by combining the user name and the realm and are not
sure about the cases of the letters used in the user name we might get a
valid ticket from the AD KDC but are not able to access it with the
Kerberos client library because we assume a wrong case.
The client principal in the returned credentials will always have the
right cases. To be able to update the cache user principal name the
krb5_child will return the principal for further processing.
|
| |
|
|
|
|
|
| |
The different_realm flag which was set by the responder is send to the
krb5_child so that it can act differently on users from other realms. To
avoid code duplication and inconsistent behaviour the krb5_child will
not set the flag on its own but use the one from the provider.
|
| |
|
|
| |
https://fedorahosted.org/sssd/ticket/1379
|
| |
|
|
| |
Coverity #12784
|
| |
|
|
|
| |
krb5-child-test will be another consumer. It also makes the code more
readable by splitting a huge function.
|
| |
|
|
|
| |
The krb5-child-test will want to run the child from the current
directory.
|
| | |
|
| | |
|
| | |
|
|
|
I took the opportunity to move everything related to the handling of the
krb5_child into a separate file and cleaned the interfaces and related
structures a bit.
|
