Integrating IDM with AD (Active directory) using indirect cross-forest trust

Establishing trust with AD Domain

We can accomplish the trust by two methods. By running “trust-add” and enter the Admin password or using the secret method. Here we are using the “trust-add” method.

Once we run, the trusts relationship to “winlinuxsysadmins.local” will become ‘trusted’. It will prompt to enter the “Administrator” account password of the AD server.

# ipa trust-add --type=ad winlinuxsysadmins.local --admin Administrator --password
Adding trust

Now, IPA has created one-way forest trust on the IDM side. We have completed with a one-way trust. To verify from GUI navigate to IPA Server –> Trusts as shown in below picture.

Integrating IDM with AD (Active directory) using indirect cross-forest trust 1

By clicking on it will give more information about the windows trust.

Windows Trust more info

Using Secret method

The above method can be followed or we have an alternative method using a secret. By using this method we don’t need to enter the Admin password. This will help in case we don’t have the Administrator access to the AD.

# ipa trust-add winlinuxsysadmins.local --trust-secret

Creating Trust in Active Directory

Then switch to Windows side and start creating trust, refer below snip.

In DNS Server Service Manager –> AD DS –> Active Directory Domains and Trust –> Right Click –> Properties –> Trust TAB –> “Domain that trust this domain (incoming trusts) { This will be already exists} –> Refresh

Note:> Here we need to keep in mind, only IDM needs to trust the AD for resolving all incoming request.

Trusted one way forest-trust
Trusted one-way forest-trust

Fetch and find the trusted domain on IDM

Once the “linuxsyadmins.local” trusted by AD try to retrieve the list of trusted forest domain from the Active Directory.

# ipa trust-fetch-domains "winlinuxsysadmins.local"
Integrating IDM with AD (Active directory) using indirect cross-forest trust 2

Find the “winlinuxsysadmins.local” now we should get the domain information as follow.

# ipa trustdomain-find "winlinuxsysadmins.local"
Integrating IDM with AD (Active directory) using indirect cross-forest trust 3

To show all the available trust information we can use trust-show –all option with IPA command.

# ipa trust-show --all

Output for your reference

[root@idmns ~]# ipa trust-show --all
 Realm name: winlinuxsysadmins.local
   dn: cn=winlinuxsysadmins.local,cn=ad,cn=trusts,dc=linuxsysadmins,dc=local
   Realm name: winlinuxsysadmins.local
   Domain Security Identifier: S-1-5-21-1731408719-2571748571-251808187
   SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13,
                           S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20
   SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13,
                           S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20
   Trust direction: Trusting forest
   Trust type: Active Directory domain
   gidnumber: 5001
   ipantsecurityidentifier: S-1-5-21-479538025-3999940732-1828893943-1003
   ipantsupportedencryptiontypes: 28
   ipanttrustpartner: winlinuxsysadmins.local
   ipanttrustposixoffset: 0
   objectclass: ipaNTTrustedDomain, ipaIDobject, top
   uidnumber: 5003
 [root@idmns ~]# 

Or to get only our added trust information to specify with a domain name by the following command.

# ipa trust-show winlinuxsysadmins.local

Less information for trust as shown below.

[root@idmns ~]# ipa trust-show winlinuxsysadmins.local
   Realm name: winlinuxsysadmins.local
   Domain Security Identifier: S-1-5-21-1731408719-2571748571-251808187
   Trust direction: Trusting forest
   Trust type: Active Directory domain
 [root@idmns ~]#

Verify AD admin privilege accounts on IDM

Almost most of the configurations are done let obtain a Kerberos ticket for win domains Administrator account. Enter the Administrator account password when prompt.

# kinit Administrator@winlinuxsysadmins.local

Output for your reference

[root@idmns ~]# kinit Administrator@winlinuxsysadmins.local
 Password for Administrator@winlinuxsysadmins.local: 
 [root@idmns ~]#

List the obtained Kerberos ticket using klist command, Here we can find the Administrator has a valid kb ticket.

[root@idmns ~]# klist 
 Ticket cache: KEYRING:persistent:0:krb_ccache_QKwQFhc
 Default principal: Administrator@WINLINUXSYSADMINS.LOCAL
 Valid starting     Expires            Service principal
 06/20/19 03:45:21  06/20/19 13:45:21  krbtgt/WINLINUXSYSADMINS.LOCAL@WINLINUXSYSADMINS.LOCAL
   renew until 06/21/19 03:45:17
 [root@idmns ~]#

Creating external Groups on IDM

To import all users from trusted AD to IDM we need to create external groups.

# ipa group-add --desc='WINLINUXSYSADMINS.local admins external map' winlinuxsysadmins.local_external --external
# ipa group-add --desc='WINLINUXSYSADMINS.local admins' winlinuxsysadmins.local

Adding Users to an external group

Once completed with group add all the users to existing external group from the trusted domain by entering the null value while asking for user/group.

# ipa group-add-member WINLINUXSYSADMINS.local_external --external 'WINLINUXSYSADMINS\Domain Admins'

Leave user and group blank, Just press enter.

Verify all Accounts

Now it’s time to verify all accounts using “getent” command with option and argument by replacing our win domain.

# getent passwd Administrator@winlinuxsysadmins.local
# getent passwd babin@winlinuxsysadmins.local
# getent passwd lonston@winlinuxsysadmins.local

Below output for your reference

[root@idmns ~]# getent passwd Administrator@winlinuxsysadmins.local
[root@idmns ~]#
[root@idmns ~]# getent passwd babin@winlinuxsysadmins.local
 babin@winlinuxsysadmins.local:*:916001104:916001104:Bobin L.:/home/winlinuxsysadmins.local/babin:
[root@idmns ~]#
[root@idmns ~]# getent passwd lonston@winlinuxsysadmins.local
 lonston@winlinuxsysadmins.local:*:916001105:916001105:Lonston L.:/home/winlinuxsysadmins.local/lonston:

Adding external group to POSIX group

Now we required to allow admin users of “winlinuxsysadmins.local_external” with POSIX group.

# ipa group-add-member WINLINUXSYSADMINS.LOCAL --groups WINLINUXSYSADMINS.local_external

Output for reference

# ipa group-add-member WINLINUXSYSADMINS.LOCAL --groups WINLINUXSYSADMINS.local_external
 [root@idmns ~]# ipa group-add-member WINLINUXSYSADMINS.LOCAL --groups WINLINUXSYSADMINS.local_external
   Group name: winlinuxsysadmins.local
   Description: WINLINUXSYSADMINS.local admins
   GID: 5004
   Member groups: winlinuxsysadmins.local_external
 Number of members added 1

That’s it now let’s verify the accounts.

Verify AD account logins

Quickly do an SSH and verify for all your AD accounts from IDM server.

# ssh babin@winlinuxsysadmins.local@

SSH Session Successful.

[root@idmns ~]# ssh babin@winlinuxsysadmins.local@
 Last login: Thu Jun 20 14:14:21 2019 from idmns.linuxsysadmins.local
 -sh-4.2$ ls -lthra
 total 16K
 drwx--x--x 3 root                          root                           19 Jun 20 14:13 ..
 -rw------- 1 babin@winlinuxsysadmins.local babin@winlinuxsysadmins.local 193 Jun 20 14:13 .bash_profile
 -rw------- 1 babin@winlinuxsysadmins.local babin@winlinuxsysadmins.local  18 Jun 20 14:13 .bash_logout
 -rw------- 1 babin@winlinuxsysadmins.local babin@winlinuxsysadmins.local 231 Jun 20 14:13 .bashrc
 drwx------ 2 babin@winlinuxsysadmins.local babin@winlinuxsysadmins.local  83 Jun 20 14:14 .
 -rw------- 1 babin@winlinuxsysadmins.local babin@winlinuxsysadmins.local  45 Jun 20 14:14 .bash_history

That’s it we are good with all the above steps according to SSH sessions worked. Hence, this guide is too long in our upcoming guide, we will cover with the client setup.

By following below URL, Start setting up Client-side configuration

Setup a Linux server as IDM client to authenticate with Active Directory


Integrating IDM with AD cross-forest trust setup using IDM has a lot of features, will cover up with more topics on IDM. Your comments are most welcome, in case any update/improvement required in topic kindly let us know through comments. Subscribe to our newsletter to stay with us for more nix guides.

6 thoughts on “Integrating IDM with AD (Active directory) using indirect cross-forest trust”

  1. Hi,

    To the point post but does not address another nonSSO case using SSH only.
    That is a client with hostname under the winlinuxsysadmins.local domain (let us call it c1.winlinuxsysadmins.local) to which the AD users would like to log into.

    SSO is out of mind (as the kdc is not within the idm realm), but ssh should still work.

    So `ssh ad-user1@winlinuxsysadmins.local@c1.winlinuxsysadmins.local) theoretically would request PAM authentication using sssd from IdM.

    However in practice this is not the case.

    Any feedback?

    Best regaerds

  2. Hi Babin,

    Our requirement is Active Directory groups are not supposed to be displayed on the IDM clients.
    Three external groups are created in Redhat IDM(3000,4000,5000). Trust is established between with Active Directory to Redhat IDM with these external groups. Mapping UserID and Group Membership as in IDM View and AD Membership .We have issues seeing all the group memberships in AD on the client-side. We need to restrict ONLY the Unix Groups to be visible to the clients..please guide us

    please guide us.

  3. Hi Babin

    Can you please help me understand the below regarding the below commands:

    # ipa group-add –desc=’WINLINUXSYSADMINS.local admins external map’ winlinuxsysadmins.local_external –external
    # ipa group-add –desc=’WINLINUXSYSADMINS.local admins’ winlinuxsysadmins.local

    1. Should the group “winlinuxsysadmins.local” have Administrator permissions in AD? Is it a problem if the group has non-Administrator permissions?
    2. Is the group “winlinuxsysadmins.local” used for managing AD users in IDM?

    Kind regards


Leave a Comment

Subscribe To Our Newsletter

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

We promise not to spam you, and we don't usually send more than one email a week.

You have Successfully Subscribed!