[Freeipa-devel] [RFC] Serving legacy systems cliens for trusts

[Alexander Bokovoy]

On Thu, 30 May 2013, Sumit Bose wrote:
>On Wed, May 29, 2013 at 09:53:14AM -0400, Dmitri Pal wrote:
>> On 05/29/2013 03:28 AM, Sumit Bose wrote:
>> > On Wed, May 29, 2013 at 08:38:37AM +0300, Alexander Bokovoy wrote:
>> >> On Tue, 28 May 2013, Dmitri Pal wrote:
>> >>> On 05/28/2013 04:29 PM, Alexander Bokovoy wrote:
>> >>>> On Tue, 28 May 2013, Dmitri Pal wrote:
>> >>>>> On 05/28/2013 03:48 PM, Alexander Bokovoy wrote:
>> >>>>>> On Tue, 28 May 2013, Dmitri Pal wrote:
>> >>>>>>> On 05/28/2013 07:50 AM, Alexander Bokovoy wrote:
>> >>>>>>>> Hi,
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts
>> >>>>>>>>
>> >>>>>>>> = Overview =
>> >>>>>>>>
>> >>>>>>>> Since version 3.0 FreeIPA supports cross-realm trusts with Active
>> >>>>>>>> Directory. In order to allow AD users to utilize services on IPA
>> >>>>>>>> clients, up to date version of SSSD should be configured at the IPA
>> >>>>>>>> client. In case it is not possible to install and configure SSSD >
>> >>>>>>>> 1.09,
>> >>>>>>>> Active Directory users cannot access services on IPA clients.
>> >>>>>>>>
>> >>>>>>>> This feature is designed to bridge the gap and provide minimal
>> >>>>>>>> compatibility level that allows to log-in to IPA clients for AD
>> >>>>>>>> users.
>> >>>>>>>> IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd
>> >>>>>>>> version.
>> >>>>>>>> = Use Cases =
>> >>>>>>>>
>> >>>>>>>> Access to IPA client machine resources for AD users in case IPA
>> >>>>>>>> client
>> >>>>>>>> cannot utilize up to date version of SSSD with native support for IPA
>> >>>>>>>> cross-realm trusts.
>> >>>>>>>>
>> >>>>>>>> = Design=
>> >>>>>>>> Since IPA client is configured with the use of older SSSD or
>> >>>>>>>> nss_ldap/pam_ldap, all work should be performed at the IPA master.
>> >>>>>>>> Primary design decision is to provide a separate LDAP tree,
>> >>>>>>>> similar to
>> >>>>>>>> compat tree, that has following features:
>> >>>>>>>>
>> >>>>>>>> * information about both IPA and AD users can be queried;
>> >>>>>>>> * it ispossible to enumerate members of IPA and AD groups;
>> >>>>>>>> * authentication bind to IPA LDAP as AD users should automatically
>> >>>>>>>> * trigger obtaining ticket from AD DC; in case TGT is obtained,
>> >>>>>>>> * authentication bind should be treated as successful.
>> >>>>>>>>
>> >>>>>>> >From a client perspective, use of the separate LDAP tree is viewed as
>> >>>>>>>> traditional nss_ldap/pam_ldap configuration.
>> >>>>>>>>
>> >>>>>>>> Proposed base for the LDAP tree:
>> >>>>>>>> '''cn=users,cn=trust-accounts,dc=example,dc=com'''
>> >>>>>>>>
>> >>>>>>>> = Implementation =
>> >>>>>>>>
>> >>>>>>>> # IPA server sets SSSD configuration to 'ipa_server_mode = true' on
>> >>>>>>>> install or upgrade
>> >>>>>>>> # ipa-adtrust-install configures additional directory server
>> >>>>>>>> plugin to
>> >>>>>>>> serve trusted domains tree
>> >>>>>>>> # Directory server plugin uses  getpwnam_r(), getgrnam_r() and
>> >>>>>>>> related
>> >>>>>>>> calls to obtain information about AD user. For IPA users the
>> >>>>>>>> information is fetched directly from the LDAP.
>> >>>>>>>> # IPA KDC database driver adds MS-PAC information into ticket
>> >>>>>>>> granting
>> >>>>>>>> ticket for host/fqdn at REALM principal of IPA master. This is required
>> >>>>>>>> to allow SSSD on IPA master to authenticate against AD using
>> >>>>>>>> host/fqdn at REALM principal.
>> >>>>>>>>
>> >>>>>>>> For SSSD design see
>> >>>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode
>> >>>>>>>>
>> >>>>>>>> = Feature Management =
>> >>>>>>>>
>> >>>>>>>> === UI ===
>> >>>>>>>>
>> >>>>>>>> The feature is transparent and not exposed in UI
>> >>>>>>>>
>> >>>>>>>> === CLI ===
>> >>>>>>>>
>> >>>>>>>> The feature is not directly exposed in CLI.
>> >>>>>>>> IPA idrange management is expanded to specify idrange type (IPA
>> >>>>>>>> local,
>> >>>>>>>> AD trust, AD with winsync, IPA trust, ..) to affect the way how AD
>> >>>>>>>> users
>> >>>>>>>> SIDs are mapped to POSIX IDs.
>> >>>>>>>>
>> >>>>>>>> = Major configuration options and enablement =
>> >>>>>>>>
>> >>>>>>>> sssd.conf will have 'ipa_server_mode = true' set for IPA master.
>> >>>>>>>>
>> >>>>>>>> = Replication =
>> >>>>>>>>
>> >>>>>>>> No effect on replication. Since directory server plugin is only
>> >>>>>>>> configured when ipa-adtrust-install is run, IPA masters may opt out
>> >>>>>>>> from
>> >>>>>>>> serving AD clients.
>> >>>>>>>>
>> >>>>>>>> = Updates and Upgrades =
>> >>>>>>>>
>> >>>>>>>> During upgrade of IPA master, sssd.conf should be updated to set
>> >>>>>>>> 'ipa_server_mode = true'.
>> >>>>>>>>
>> >>>>>>>> = Dependencies =
>> >>>>>>>>
>> >>>>>>>> Depends on SSSD implementing IPA server mode (sssd 1.10.x)
>> >>>>>>>>
>> >>>>>>>> = External Impact =
>> >>>>>>>>
>> >>>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode
>> >>>>>>>>
>> >>>>>>>> = Backup and Restore =
>> >>>>>>>>
>> >>>>>>>> No external configuration files are affected
>> >>>>>>>>
>> >>>>>>>> = Test Plan =
>> >>>>>>>>
>> >>>>>>>> Testing the feature will require following:
>> >>>>>>>>
>> >>>>>>>> # Configure IPA to serve AD trusts
>> >>>>>>>> # Establish trust with AD domain
>> >>>>>>>> # Configure a client to use nss_ldap/pam_ldap against AD-compatible
>> >>>>>>>> tree
>> >>>>>>>> # Attempt to log-in to the client as AD user
>> >>>>>>>>
>> >>>>>>>> = RFE Author =
>> >>>>>>>>
>> >>>>>>>> [[User:Ab|ab]] ([[User talk:Ab|talk]])
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>> Can you please explain how the older SSSD or other UNIX versions would
>> >>>>>>> use Kerberos for authentication?
>> >>>>>> pam_krb5 should work as it is, as well as older SSSD, since any AD user
>> >>>>>> attempting to connect using GSSAPI to IPA services will have
>> >>>>>> cross-realm
>> >>>>>> TGT issued for us by the trusting AD DC prior to that attempt.
>> >>>>>>
>> >>>>>> The whole idea was to make sure for old clients these users will look
>> >>>>>> like normal users, via nss_ldap/SSSD.
>> >>>>>>
>> >>>>>> We still will need to configure principal mapping in /etc/krb5.conf
>> >>>>>> like
>> >>>>>> we do for AD users with trusts.
>> >>>>>>
>> >>>>>>> I thought we would have to issue some patch for client to switch the
>> >>>>>>> clients from using Kerberos for authentication to using LDAP.
>> >>>>>> No need to. pam_ldap would go through LDAP bind automatically, that's
>> >>>>>> why the proposal talks about attempting to obtain TGT in place of a
>> >>>>>> user
>> >>>>>> instead of proxying such LDAP bind back to AD DC. This would require us
>> >>>>>> enforcing clear password bind over TLS/SSL but it is simpler to
>> >>>>>> achieve.
>> >>>>>>
>> >>>>> I am missing something. How a simple kinit would work?
>> >>>>> Can you please describe the sequence and workflow?
>> >>>> I'm talking about the case when AD user logs in into IPA client using
>> >>>> PuTTY from Windows machine. In such case there is already service ticket
>> >>>> and cross-realm TGT available.
>> >>>>
>> >>>> For kinit on IPA client all what is needed is /etc/krb5.conf
>> >>>> configuration that forces to talk to AD DC for principals in AD realm.
>> >>>>
>> >>>> It can be done via SRV records in DNS or manually in /etc/krb5.conf.
>> >>>>
>> >>>> For example, on the machine I'm writing this email I added manual
>> >>>> routing to my VMs with AD and IPA to /etc/krb5.conf and I'm able to do
>> >>>> following:
>> >>>>
>> >>>> # klist
>> >>>> klist: No credentials cache found (ticket cache
>> >>>> DIR::/run/user/0/krb5cc/tkt)
>> >>>> # kinit Administrator at AD.LAN
>> >>>> Password for Administrator at AD.LAN: Warning: Your password will expire
>> >>>> in 2 days on Пт. 31 мая 2013 07:29:10
>> >>>> # klist
>> >>>> Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO
>> >>>> Default principal: Administrator at AD.LAN
>> >>>>
>> >>>> Valid starting       Expires              Service principal
>> >>>> 28.05.2013 23:24:44  29.05.2013 09:24:44  krbtgt/AD.LAN at AD.LAN
>> >>>>        renew until 04.06.2013 23:24:44
>> >>>> # kvno HTTP/red.bird.clone at BIRD.CLONE
>> >>>> HTTP/red.bird.clone at BIRD.CLONE: kvno = 2
>> >>>> # klist
>> >>>> Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO
>> >>>> Default principal: Administrator at AD.LAN
>> >>>>
>> >>>> Valid starting       Expires              Service principal
>> >>>> 28.05.2013 23:24:44  29.05.2013 09:24:44  krbtgt/AD.LAN at AD.LAN
>> >>>>        renew until 04.06.2013 23:24:44
>> >>>> 28.05.2013 23:25:45  29.05.2013 09:24:44  krbtgt/BIRD.CLONE at AD.LAN
>> >>>>        renew until 04.06.2013 23:24:44
>> >>>> 28.05.2013 23:26:42  29.05.2013 09:24:44  HTTP/red.bird.clone at BIRD.CLONE
>> >>>>        renew until 04.06.2013 23:24:44
>> >>>>
>> >>> This is exactly the problem I am try to get to.
>> >>> Let us take CentOS 6.3 machine and configure SSSD against IPA. It has
>> >>> absolutely no knowledge about AD. This is the whole point.
>> >>> But AD users should be able to walk to the console and authenticate. The
>> >>> flow will be:
>> >>> User -> SSSD -> kerberos library -> KDC -> ???? -> SSSD on IPA -> AD
>> >>> But there is no design for such flow. And IMO it is too much.
>> >> For this use case LDAP-based authentication has to be configured.
>> >>
>> >> For any remote login we can rely on Kerberos authentication.
>> >>
>> >> For over console login we cannot rely on Kerberos authentication without
>> >> explicit help from either KDC or SSSD.
>> >>
>> >> What we can do in our KDB driver is to force KDC to issue KDC referral
>> >> for users from trusted domains, rewriting the realm and redirecting to
>> >> AD DC. This is how AD DC performs in a forest when a client talks to
>> >> non-root DC in request of a ticket for a service in a trusted domain.
>> >>
>> >> However, I think it could be a good target for 3.4.
>> >>
>> >>> What you are suggesting here is a sort of "split brain solution" that we
>> >>> did not recommend in the past are we going to change out assessment of
>> >>> this approach?
>> >> No. What I suggested did not include direct console logins.
>> >>
>> >>> So to summarize we are talking about the case:
>> >>> a) Legacy/UNIX systems are configured to authenticate/joined to IPA and
>> >>> do not know about AD
>> >>> b) User from AD walks to the console and uses his name and password
>> >>>
>> >>> He needs to be authenticated. How?
>> >> See above. KDC needs to recognize this user is from a trusted domain (by
>> >> the domain's realm) and issue a referral to AD DCs which handle it.
>> > If I understand the issue correctly then only 'dns_lookup_kdc = true'
>> > must be set in /etc/krb5.conf on the client.
>> >
>> > For passowrd based console logins the client must the able to resolve
>> > the trusted AD DC with a DNS SRV lookup and must be able to connect to
>> > one of the returned DCs because only the AD DC can authenticate the
>> > user. It is the same way as this type of authentication is working for
>> > sssd in 6.4. And it is basically the same way as it works for Windows
>> > clients, only that here the AD DC of the Windows client is contacted
>> > first and returns a Kerberos client referral to the Windows client as
>> > Alexander mentioned above. Then the Windows client also has to find a DC
>> > of the trusted domain and send the request to the trusted DC.
>> >
>> > HTH
>> >
>> > bye,
>> > Sumit
>>
>>
>> This whole discussion is missing from the design page.
>> However we are not yet out of the woods.
>>
>> In the upstream version we need to support SSSD 1.5 and later on Fedora,
>> RHEL CentOS, etc.
>> pam_krb5 from 1.7 and later
>> Solaris 10, 11
>> AIX 6.x
>> HP-UX may be
>>
>> For UNIXes you really can't patch the client so there should be a
>> procedure to setup these clients.
>> In most cases these clients use LDAP rather than kerberos so I think it
>> is acceptable to not support Kerberos console login from those systems
>> for AD users.
>> The systems should be configured using LDAP against IPA and would know
>> only native IPA users (in console login).
>> But if Kerberos can be made to work fine I am all for it. For those
>> clients we do not have an automated install procedure so it is given
>> that the setup will be manual.
>
>There are two type of Kerberos based authentication here. First and
>preferred one, if the client can handle Kerberos authentication it
>should do it directly against AD. In most cases this would give the user
>a valid ticket in his credential cache which he can use for SSO to other
>services.
>
>Second is the Kerberos authentication we are planning on the server
>side. The client does an authenticated LDAP bind to validate the
>credentials the user gave at the login prompt. Since the IPA server
>cannot do the validation itself it will forward the credentials via the
>PAM pass-through plugin which in the end will do a kinit with the
>forwarded credentials of the user. In this case the user on the client
>will not have any Kerberos tickets after login, but at least
>authentication of AD users would be possible even for an LDAP only
>client.
>
>>
>> For Lunix and older SSSD version we in fact have a problem.
>> What I want to avoid is to have to define procedures and patches for all
>                ^^^^^^ ?
>> the clients. However if you use ipa-client-install it would configure
>> sssd the old way.
>> How to make it configured the new way? Manually? This is error prone and
>> people will be reluctant to reconfigure SSSD. Automatically? Means
>> patches to all the versions of the clients.
>> How we are going to deal with the huge test matrix?
>
>I think rolling out patches to old sssd versions is not a good idea and
>I think we won't have the time to prepare all the needed patches in a
>reasonable time-frame.
>
>For SSSD versions which do not allow multiple search bases (1.5 and 1.6)
>I would suggest to add a new domain section for the AD user with LDAP
>and Kerberos provider. This would allow IPA users to works as before and
>add the AD users to the client. Maybe this would also be a better
>solution for the other SSSD versions instead of multiple search bases,
>at least it's a solution for all versions.
>
>Since we have the python config API for SSSD the needed changes to the
>sssd.conf might be scriptable with a reasonable effort. Maybe this can
>be added to ipa-client-install with a new option like
>--enable-legacy-trust-support which can add the news section to existing
>configuration or include it for new installations?
Bigger question is what is simpler: write configuration instructions or
modify/provide additional script for old SSSD?

Remeber that trusts with AD are most likely established when IPA clients
are already rolled out. Changing ipa-client-install is not helpful for
this case since the clients are already there.

Perhaps a better approach would be documentation for non-SSSD case and a
simple snippet that can be run alone or in use with puppet/etc to deploy
massively. The snippet would use SSSDConfig Python API to add needed
modifications to the clients' SSSD configuration.

We can even extend IPA server tools to allow generating such snippets
based on the trusts configuration. After all, we do have control over
IPA server in such cases.


I have updated wiki page with discussed ideas.
-- 
/ Alexander Bokovoy