On Tue, Dec 15, 2015 at 11:38:08AM -0500, Alexander Bokovoy wrote:
> 
> 
> ----- Original Message -----
> > Hi,
> > 
> > If PAC is not being used using key, how is group membership determined?
> By asking IPA master to give list of groups AD user belongs to.
> The complexity of this process makes it hard to have full list of groups 
> available in advance in all cases.
> MS-PAC record in Kerberos ticket has its feature that AD DC will put the 
> correct and full list of groups
> the user is a member of at the time of issuing TGT, signed by the AD DC's 
> signature. This means after validating
> the ticket we can trust its content for caching. In case of no PAC data 
> available we have to resort to less precise
> methods that would give incomplete information for some of situations like 
> incomplete GC content for multidomain
> AD forests.
> 
> > Also: it feels like the Linux client is contacting AD to obtain a Kerberos
> > ticket and not the IPA-server. (for AD users). Is that true?
> Yes, how would you imagine doing it differently? AD DCs are authoritative for 
> their users, not IPA KDC.
> This is basic feature of Kerberos protocol.

This is true for getting a TGT for the user, but when it comes to
authentication against an IPA client there is a step which involves the
IPA KDC as well. Either if you use Kerberos/GSSAPI authentication, e.g.
with ssh, or password authentication, in both cases a Kerberos service
ticket for the IPA client is needed which is issued by the IPA KDC and
here is were the SIDs for IPA group memberships are added.

In the ssh case the ssh client will ask the IPA KDC for the service
ticket by sending a valid TGT or cross-realm TGT in the trust case. In
the password authentication case SSSD will ask for the same service
ticket after getting a TGT for the user from the AD DC. This step is
called validation because SSSD needs a prove that the TGT was really
issued by a valid KDC. A user calling kinit can but pretty sure that the
KDC is valid because the password is a shared secret between the user
and the KDC in this case. A service like SSSD cannot be sure that the
user is not an attacker which spoofed e.g. DNS and let SSSD talk to a
invalid KDC which of course will issue TGTs for the attacker. To make
sure the ticket is valid SSSD uses the shared secret it has with the
valid KDC, the host keys in /etc/krb5.keytab, to validate the TGT by
requesting a service ticket for the host itself. If the service ticket
can be decrypt with the keys in the keytab SSSD can be pretty sure that
the service ticket and hence the TGT are valid.

Coming back to the original issue with the missing group. Can you share
the definition of the IPA external group and the related IPA POSIX group
for a group which is still present and one which got deleted. The output
of 'ipa group-show --all --raw group_name' should be sufficient for a
start. Feel free to send the output to me directly if it contains
sensitive data.

bye,
Sumit

> 
> With IPA 4.2 on systems like RHEL 7.2/CentOS 7.2/Fedora 23 you can configure 
> MIT Kerberos to use MS-KKDC proxy provided by IPA.
> In such case IPA masters can be used as Kerberos proxy but the actual 
> authentication decision is done by AD DCs anyway.
> -- 
> / Alexander Bokovoy

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to