Pot ent ial Behavior Issues wit h Act ive Direct ory T rust

5 .1 .6 .1 . Act ive Dire ct o ry Use rs and IdM Adm inist rat io n

Trust relationships are unidirectional. Active Directory users exist only within the Active Directory domain and are limited to what resources within the IdM domain they can access. Act ive Direct o ry u sers can n o t b e ad min ist rat o rs f o r Id M b ecau se t h ey d o n o t exist wit h in Id M.

Active Directory users, then, cannot use any IdM administrative tools, including the web UI and command-line tools.

5 .1 .6 .2 . Aut he nt icat ing De le t e d Act ive Dire ct o ry Use rs

By default, every IdM client uses the System Security Services Daemon to cache user identities and credentials. This allows the local system to reference identities for users who have already logged in successfully once, even if one of the backend providers (IdM or Active Directory) is temporarily unavailable.

Because SSSD maintains a list of users locally, it is possible that changes that are made on the backend are not immediately visible to clients.

If an Active Directory user has successfully logged into an IdM client resource, that user identity is cached in SSSD on both the local client and on the IdM server. If that Active Directory user is then deleted in Active Directory, that identity is still cached in IdM, which means that the user could successfully log into IdM resources.

The deleted Active Directory user will be able to log into IdM resources until the SSSD cache on any local client and on the IdM server expire. Then, when the IdM server attempts to retrieve the identity from Active Directory, it will receive notification that the user does not exist, and the login attempt fails.

5 .1 .6 .3. Cre de nt ial Cache and Se le ct ing Act ive Dire ct o ry Principals

The Kerberos credentials cache attempts to match a client principal to a server principal based on the service name, then the hostname, then (possibly) the realm name. Because the client/server mapping is done using the hostname and the realm name, this can create seemingly unexpected behavior in binding as an Active Directory user because the realm name of the Active Directory user is different than the realm name of the IdM system.

What this means in practice is that if an Active Directory user ki ni ts and then uses SSH to connect to an IdM resource, that principal is not selected for the resource ticket; an IdM principal is used because the IdM principal matches the resource's realm name.

For example, if the Active Directory user is Ad mi ni strato r and the domain is AD EXAMP LE. AD R EALM, the principal is Ad mi ni strato r@ AD EXAMP LE. AD R EALM.

[root@ server ~]# kinit Administrator@ ADEXAMPLE.ADREALM Password for Administrator@ ADEXAMPLE.ADREALM:

[root@ server ~]# klist

Ticket cache: KEYRING:persistent:0:0

Default principal: Administrator@ ADEXAMPLE.ADREALM

Valid starting Expires Service principal 27.11.2013 11:25:23 27.11.2013 21:25:23

krbtgt/ADEXAMPLE.ADREALM@ ADEXAMPLE.ADREALM renew until 28.11.2013 11:25:16

This is set as the default principal in the Active Directory ticket cache. However, if any IdM user also has a Kerberos ticket (such as ad mi n), then there is a separate IdM credentials cache, with an IdM default principal. That IdM default principal is selected for a host ticket if the Active Directory user uses SSH to connect to a resource.

[root@ vm-197 ~]# ssh -l Administrator@ adexample.adrealm ipaclient.example.com 27.11.2013 11:25:23 27.11.2013 21:25:23

krbtgt/ADEXAMPLE.ADREALM@ ADEXAMPLE.ADREALM renew until 28.11.2013 11:25:16

Ticket cache: KEYRING:persistent:0:0

D efaul t pri nci pal : ad mi n@ EXAMP LE. C O M >>>>> IdM user

⁠Chapt er 5. Creat ing Cross- Realm T rust s wit h Act ive Direct ory and Ident it y Management

Valid starting Expires Service principal

27.11.2013 11:25:18 28.11.2013 11:25:16 krbtgt/EXAMPLE.COM@ EXAMPLE.COM 27. 11. 20 13 11: 25: 4 8 28. 11. 20 13 11: 25: 16

ho st/i pacl i ent. exampl e. co m@ EXAMP LE. C O M >>>>> host principal

This is because the realm name of the IdM principal matches the realm of the IdM resource.

5 .1 .6 .4 . Re so lving Gro up SIDs Lo sin g Kerb ero s T icket s

Running any command to obtain a SID from the Samba service — such as net g etl o cal si d or net g etd o mai nsi d — kills any existing admin ticket in the Kerberos cache.

Can n o t Verif y G ro u p Memb ersh ip f o r Users

There is no way to verify that a specific trusted user is associated with a specific IdM group, external or POSIX.

Can n o t Disp lay ( Remo t e) Act ive Direct o ry G ro u p Memb ersh ip s f o r an Act ive Direct o ry User

For Linux system users, local group associations can be shown for a user using the i d command.

However, Active Directory group memberships are not displayed with i d for Active Directory users, even though they are with Samba tools.

The wbi nfo command can be used to obtain a SID for an Active Directory user and then to display groups associated with that SID.

[root@ ipaserver ~]# wbinfo -n ADDOMAIN\\jsmith

S-1-5-21-1689615952-3716327440-3249090444-1104 SID_USER (1)

[root@ ipaserver ~]# wbinfo --user-domgroups=S-1-5-21-1689615952-3716327440-3249090444-1104

S-1-5-21-1689615952-3716327440-3249090444-513 S-1-5-21-1689615952-3716327440-3249090444-1106

The same query using i d shows only the user information, not the Active Directory group membership information.

[root@ ipaserver ~]# id ADDOMAIN\\jsmith

uid=1921801104(jsmith@ adexample.com) gid=1921801104(jsmith@ adexample.com) groups=1921801104(jsmith@ adexample.com)

TIP

To work around this, ssh into an IdM client machine as the given Active Directory user. After the first successful login, the Active Directory group memberships are detected and returned in the i d search.

[root@ ipaserver ~]# id ADDOMAIN\jsmith uid=1921801107(jsmith@ adexample.com) gid=1921801107(jsmith@ adexample.com)

groups=1921801107(jsmith@ adexample.com),129600004(ad_users),192180051 3(domain users@ adexample.com)