[SSSD] Access denied by pam_sss(sshd:account)

Sumit Bose sbose at redhat.com
Mon Jul 1 09:46:16 UTC 2013


On Mon, Jul 01, 2013 at 09:32:45AM +0200, Jakub Hrozek wrote:
> On Fri, 2013-06-28 at 10:39 -0400, Dmitri Pal wrote:
> > >> Also in 1.10 SSSD should support transitive trusts so if there is a
> > >> trust between the domains SSSD 1.10 should be able to authenticate users
> > >> from both domains.
> > > You can use the TGT to access both trusted domains in a trust, but the
> > > TGT must be obtained from the KDC you are enrolled with. At least
> > > with AD, because there are no krb5-master SRV records by default on the
> > > AD side, so the libkrb5 has no means of asking who to contact to if the
> > > keytab is not local to the domain. One could work around by adding the
> > > SRV records or adding the master_kdc option to krb5.conf, but the AD
> > > provider only talks to the local KDC when acquiring a TGT by default.
> > >
> > > I learned this the hard way when debugging the trusts in the AD provider
> > > recently :)
> > > _______________________________________________
> > > sssd-devel mailing list
> > > sssd-devel at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> > 
> > Are you saying that if there are two domins A & B user is from A and
> > system is from B and user logs into the system using his user name and
> > password (not SSH with GSSAPI) he needs to have additional DNS records?
> > My understanding (may be limited) of the flow would be that when you try
> > to authenticate the request would go to domain B, it will recognize that
> > the user is from trusted domain and issue a cross realm ticket to the
> > client and redirect it to domain A. Is this the place where the client

What your describing is the flow if you want to get a service ticket
(AS-REQ) but you have to replace 'user from a trusted domain' with
'service from a trusted domain'.

As Jakub already said a TGT for a principal from domain/realm A can only
be issued from a KDC from realm A and the client has to speak directly
to the KDC. If a user from domain A wants to log in with a password on a
host from domain B, the host from domain B can either try to determine a
KDC for the realm A on its own by looking at krb5.conf or using DNS SRV
requests. Or it can send a request with the enterprise principal
user\@A at B to a KDC from its own realm B and let the KDC sort out where
the principal user at A might belong to. If the KDC knows about realm A it
will send a referral to the host with the right realm (btw, this realm
might be different than A, which is usual the case if additional domain
suffixes are used in AD, this is why enterprise principal and client
referrals are the preferred way in an AD environment). The host now
resolves a KDC from the realm returned in the referral and sends the
request for a TGT (TGS-REQ) to this KDC.

But obtaining a TGT for a user is different from obtaining a TGT for
SSSD to access the LDAP server. Here SSSD should always contact servers
from the configured realm (if there are multiple domains configured each
backend should contact servers the specific domain) and use keytab
entries from the local domain. Although in an environment with trusts
using enterprise principals and KDC from different realms would work as
well, I think it makes no sense to support it at this point, because in
the end the KDC from the configured domain has to be resolved to get a
TGT.

HTH

bye,
Sumit

> > should be able to resolve the domain A? Would adding local records or
> > records into AD DNS solve the problem? Is this what you are suggesting
> > above?
> > 
> 
> Sorry, I forgot to reply earlier, my focus was on releasing 1.11 :)
> 
> With the help of enterprise principals you can kinit against any KDC in
> the forest and then use the TGT to access any trusted server in the
> forest. But at least for acquiring the TGT for LDAP we don't support
> enterprise principals at the moment, so we decided to kinit with the KDC
> of the SSSD domain, i.e. the KDC the client enrolled with. I don't have
> access to the test environment anymore, will have against next week, so
> I don't know if "kinit -E" would work automatically without the help of
> any additional records. Maybe Sumit can clarify in the meantime..
> 
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list