Description
Configuring and testing cross-realm trust with Active Directory.
Setup
- Make sure your FreeIPA server is set up as in QA:Testcase_freeipa_trust_server_installation.
- You have to select name for the IPA realm different from Active Directory domain name.
- There are two types of installation for FreeIPA:
- without integrated DNS setup
- with integrated DNS setup
How to test
Planned configuration
Instructions below will assume following setup:
- There is an Active Directory domain, set up under name AD.EXAMPLE.ORG. Domain controller for AD.EXAMPLE.ORG server is dc.ad.example.org and has IP-address DC-AD-IPaddr.
- There is a FreeIPA realm, set up under name IPA.EXAMPLE.ORG. FreeIPA server for the realm IPA.EXAMPLE.ORG is srv.ipa.example.org and has IP-address DC-IPA-IPaddr.
FreeIPA realm will gain a short name used for NetBIOS communication, known as 'domain name' in SMB. Usually it is the same as leftmost component of the realm, i.e. IPA for IPA.EXAMPLE.ORG.
Add cross-realm trust
Add cross-realm trust to Active Directory domain:
# ipa trust-add --type=ad ad.example.org --admin Administrator --password
Active directory domain adminstrator's password:
-------------------------------------------------
Added Active Directory trust for realm "ad.example.org"
-------------------------------------------------
Realm name: ad.example.org
Domain NetBIOS name: AD
Domain Security Identifier: S-1-5-21-16904141-148189700-2149043814
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: Two-way trust
Trust type: Active Directory domain
Trust status: Established and verified
Configure realm and domain mapping
For time being one has to manually configure krb5.conf on FreeIPA server to perform cross-realm-specific operations.
Look into /etc/krb5.conf and change/add following, replacing realm names appropriately:
[realms]
IPA.EXAMPLE.ORG = {
....
auth_to_local = RULE:[1:$1@$0](^.*@AD.EXAMPLE.ORG$)s/@AD.EXAMPLE.ORG/@ad.example.org/
auth_to_local = DEFAULT
}
Allow access for users from trusted domain to protected resources
Before users from trusted domain can access protected resources in FreeIPA realm, they have to be explicitly mapped to FreeIPA groups. The mapping is performed in two steps:
- Add users and groups from trusted domain to an external group in FreeIPA. External group serves as a container to reference trusted domain users and groups by their security identifiers.
- Map external group to an existing POSIX group in FreeIPA. This POSIX group will be assigned proper group id (gid) that will be used as default group for all incoming trusted domain users mapped to this group.
Create external and POSIX groups for trusted domain users
Create external group in FreeIPA for trusted domain admins:
# ipa group-add --desc='ad.example.org admins external map' ad_admins_external --external
Create POSIX group for external ad_admins_external group:
# ipa group-add --desc='ad.example.org admins' ad_admins
Add users and groups from trusted domain to an external group in FreeIPA
Add Domain Admins of the AD.EXAMPLE.ORG to the ad_admins_external group:
# ipa group-add-member ad_admins_external --external 'AD\Domain Admins' [member user]: [member group]: Group name: ad_admins_external Description: AD.EXAMPLE.ORG admins external map External member: S-1-5-21-16904141-148189700-2149043814-512 ------------------------- Number of members added 1 -------------------------
Add external group to POSIX group
Allow members of ad_admins_external group to be associated with ad_admins POSIX group:
# ipa group-add-member ad_admins --groups ad_admins_external
Starting from this point, FreeIPA server will be able to authenticate and recognize any trusted domain user that belongs to Domain Admins group of AD.EXAMPLE.ORG domain.
Using cross-realm trust
The following sections contains a couple of simple cases that illustrate how to test the trust has been established correctly.
Identity information
On the FreeIPA server, attempt to retrieve information about a user from AD:
# getent passwd Administrator@AD.EXAMPLE.ORG
You can test the same on the client - the getent command executed on the client would exercise a different code path, so it's worth trying out!
Password-based authentication
Apart from the Kerberos authentication below, you can also test password-based authentication. From another machine, attempt to ssh to the server:
$ ssh srv.ipa.example.org -l Administrator@AD.EXAMPLE.ORG
As with the previous case, the same test would execute different code when you log into the client:
$ ssh client.ipa.example.org -l Administrator@AD.EXAMPLE.ORG
SSH
A GSSAPI aware Windows ssh client must be installed on the windows server. The putty version from Quest http://rc.quest.com/topics/putty/ should work, but recently GSSAPI support was also added to the "standard" putty http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html. If you now log on to the windows server as the test use abc and use putty to connect with GSSAPI to the FreeIPA server it should just work without asking for a password.
When asked by SSH for credentials, use <username>@<domain> instead of <domain>\<username>. Please note that <domain> should be specified in as in the auth_to_local stanza in krb5.conf, OpenSSH server is very sensitive to change of user name. Thus, Administrator@ad.example.org, not administrator@AD.EXAMPLE.ORG, should be used wherever possible.
One needs to make sure home directory exists for users from trusted domains. By default sssd will define them as /home/<domain>/<user name>.
Expected Results
All the test steps should end with the specified results.