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

Alexander Bokovoy abokovoy at redhat.com
Tue May 28 20:29:00 UTC 2013


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

-- 
/ Alexander Bokovoy




More information about the Freeipa-devel mailing list