Freeipa Active Directory Trust

  Security, System
 

The need to trust freeipa identity management with active directory is very interesting. It permits to centralize the user management leaving in freeipa the authorization process. Very useful for system administrator to have to manage one only user account.

In this context this article explains how to integrate Freeipa with Active Directory describing all the kerberos packets involved in the process.

The reference architectures involved in this article are:

This scenario happens when the windows user connects with username and password:

Freeipa Active Directory Trust

Freeipa Active Directory Trust

This scenario happens when the windows user connects via kerberos ticket:

Freeipa Active Directory Trust

Freeipa Active Directory Trust

As you can see the authentication process is managed by Active directory by AS exchange messages; in the first picture the ssh login to linux client is by password; in the second with the TGT trust ticket obtained by AD, the windows client asks to Freeipa Server the service ticket for authenticating to ssh service without password: single sign on authentication. For who are new to kerberos protocol can be useful to read this article: https://www.securityandit.com/network/kerberos-understanding/.

The goal is to create an environment where every user is stored in active directory and the authorization process is performed by freeipa. Every user should be able to:

  1. Login to client linux by ssh if freeipa administrator permit it.
  2. Sudo enabled if freeipa administrator permit it.
  3. Changing password directly on linux system.

Let’s start with Freeipa Server Installation

Freeipa Server Installation with Active Directory Trust

The freeipa documentation available at http://www.freeipa.org/page/Active_Directory_trust_setup is very clear even if something is missing. I will follow this documentation for installing and configuring the freeipa server 4.2 trusted with Active directory Server 2012.

For Windows 2012 I installed the iso downloaded from https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2012-r2. I installed and configured an active directory instance: I don’t explain how to do because in internet there are a lot of articles about that.

Before starting, the meaning of trust between Freeipa and Windows must be cleared. The trust is only one way: it means that the configuration permits the users from AD domain to access to freeipa domain resources and not viceversa.

Windows  domain users like stefano.gristina@kali.it can be authenticated to linux domain resources with a principal like host/clientipa.linux.kali.it@LINUX.KALI.IT because the Ticket Granting Ticket Trust released by active directory is signed by a secret key shared with freeipa KDC during trust operation. This ticket is used for obtaining service ticket.

After this introduction, let’s to show the realms, the domains and the ip address involved in my laboratory.

System Operating Realm Domain Netbios Name IP
Windows 2012 KALI.IT kali.it KALI 192.168.1.50
Linux Centos 7.2 LINUX.KALI.IT linux.kali.it LINUX Freeipa Server 192.168.1.51
Freeipa Client  192.168.1.52

The active directory forest with root domain kali.it is trusted with the forest root freeipa domain that is linux.kali.it. In this scenario the freeipa domain is a subdomain of window domain.

The freeipa server is 4.2, it doesn’t use anymore old cipher like DES and RC4: it means that the trust will not work with old windows server 2003.

Let’s start with the installation with the first packages to install on freeipa server:

[root@ipaserver etc]# vi hosts | grep ipa
192.168.1.51 ipaserver.linux.kali.it ipaserver
[root@ipaserver ~]# yum install -y “*ipa-server” “*ipa-server-trust-ad” bind bind-dyndb-ldap ipa-server-dns

Next the ipa-server is installed and configured:

[root@ipaserver ~]# ipa-server-install –domain=linux.kali.it –realm=LINUX.KALI.IT –setup-dns –no-forwarders
The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will set up the IPA Server.
This includes:
* Configure a stand-alone CA (dogtag) for certificate management
* Configure the Network Time Daemon (ntpd)
* Create and configure an instance of Directory Server
* Create and configure a Kerberos Key Distribution Center (KDC)
* Configure Apache (httpd)
* Configure DNS (bind)
To accept the default shown in brackets, press the Enter key.
Enter the fully qualified domain name of the computer
on which you’re setting up server software. Using the form
<hostname>.<domainname>
Example: master.example.com.
Server host name [ipaserver.linux.kali.it]:
Warning: skipping DNS resolution of host ipaserver.linux.kali.it
Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and has full access
to the Directory for system management tasks and will be added to the
instance of directory server created for IPA.
The password must be at least 8 characters long.
Directory Manager password:
Password (confirm):
The IPA server requires an administrative user, named ‘admin’.
This user is a regular system account used for IPA server administration.
IPA admin password:
Password (confirm):
Existing BIND configuration detected, overwrite? [no]: yes
Do you want to configure the reverse zone? [yes]:
Please specify the reverse zone name [1.168.192.in-addr.arpa.]:
Using reverse zone(s) 1.168.192.in-addr.arpa.
The IPA Master Server will be configured with:
Hostname: ipaserver.linux.kali.it
IP address(es): 192.168.1.51
Domain name: linux.kali.it
Realm name: LINUX.KALI.IT
BIND DNS server will be configured to serve IPA domain with:
Forwarders: No forwarders
Reverse zone(s): 1.168.192.in-addr.arpa.
Continue to configure the system with these values? [no]: yes

Support for trusted domain is enabled setting a netbios name for linux domain. This is a prerequisite because active directory expects from remote side a netbios name.

[root@ipaserver ~]# ipa-adtrust-install –netbios-name=LINUX.KALI.IT
The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will setup components needed to establish trust to AD domains for
the IPA Server.
This includes:
* Configure Samba
* Add trust related objects to IPA LDAP server
To accept the default shown in brackets, press the Enter key.
Do you want to enable support for trusted domains in Schema Compatibility plugin?
This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.
Enable trusted domains support in slapi-nis? [no]:
Configuring cross-realm trusts for IPA server requires password for user ‘admin’.
This user is a regular system account used for IPA server administration.
admin password:
Illegal NetBIOS name [LINUX.KALI.IT].
Up to 15 characters and only uppercase ASCII letter and digits are allowed.
Enter the NetBIOS name for the IPA domain.
Only up to 15 uppercase ASCII letters and digits are allowed.
Example: EXAMPLE.
NetBIOS domain name [EXAMPLE]: LINUX
WARNING: 3 existing users or groups do not have a SID identifier assigned.
Installer can run a task to have ipa-sidgen Directory Server plugin generate
the SID identifier for all these users. Please note, the in case of a high
number of users and groups, the operation might lead to high replication
traffic and performance degradation. Refer to ipa-adtrust-install(1) man page
for details.
Do you want to run the ipa-sidgen task? [no]:

Let’s configure now DNS forwarder on freeipa server. Remember to configure as resolve name server the ipa server ip address for all linux systems.

[root@ipaserver ~]# ipa dnsforwardzone-add kali.it –forwarder=192.168.1.50 –forward-policy=only
Server will check DNS forwarder(s).
This may take some time, please wait …
Zone name: kali.it.
Active zone: TRUE
Zone forwarders: 192.168.1.50
Forward policy: only
Install required packages
[root@ipaserver ~]# dig SRV _ldap._tcp.kali.it
; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> SRV _ldap._tcp.kali.it
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48313
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;_ldap._tcp.kali.it. IN SRV
;; ANSWER SECTION:
_ldap._tcp.kali.it. 600 IN SRV 0 100 389 win-irb94ovlapt.kali.it.
;; ADDITIONAL SECTION:
win-irb94ovlapt.kali.it. 1200 IN A 192.168.1.50
;; Query time: 431 msec
;; SERVER: 192.168.1.50#53(192.168.1.50)
;; WHEN: Fri Jun 03 23:53:42 CEST 2016
;; MSG SIZE rcvd: 106
[root@ipaserver ~]# dig SRV _kerberos._tcp.kali.it
; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> SRV _kerberos._tcp.kali.it
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33747
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;_kerberos._tcp.kali.it. IN SRV
;; ANSWER SECTION:
_kerberos._tcp.kali.it. 600 IN SRV 0 100 88 win-irb94ovlapt.kali.it.
;; ADDITIONAL SECTION:
win-irb94ovlapt.kali.it. 1200 IN A 192.168.1.50
;; Query time: 57 msec
;; SERVER: 192.168.1.50#53(192.168.1.50)
;; WHEN: Fri Jun 03 23:54:23 CEST 2016
;; MSG SIZE rcvd: 110

As showed above, the SRV query is forwarded to AD (win-irb94ovlapt.kali.it) and it’s returned the reference of kerberos (port 88) and ldap services (port 389). In this way the sssd client is able to know how to contact the active directory services

The same thing in active directory:

C:\>dnscmd 127.0.0.1 /RecordAdd kali.it linux.kali.it. NS ipaserver.linux.kali.it
C:\>dnscmd 127.0.0.1 /RecordAdd kali.it ipaserver.linux.kali.it A 192.168.1.51
C:\>dnscmd 127.0.0.1  /ZoneAdd   linux.kali.it. /Forwarder 192.168.1.51

DNS query from AD is ok:

Active Directory dns forwarders

Active Directory dns forwarders

Before enabling the trust we resolve a issue that would not permit to restart freeipa:

[root@ipaserver ~]# systemctl status ipa
● ipa.service – Identity, Policy, Audit
Loaded: loaded (/usr/lib/systemd/system/ipa.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2016-06-04 03:26:17 CEST; 5min ago
Process: 3915 ExecStart=/usr/sbin/ipactl start (code=exited, status=1/FAILURE)
Main PID: 3915 (code=exited, status=1/FAILURE)
Jun 04 03:26:16 ipaserver.linux.kali.it ipactl[3915]: Starting kadmin Service
Jun 04 03:26:16 ipaserver.linux.kali.it ipactl[3915]: Starting named Service
Jun 04 03:26:16 ipaserver.linux.kali.it ipactl[3915]: Starting ipa_memcached Service
Jun 04 03:26:16 ipaserver.linux.kali.it ipactl[3915]: Starting httpd Service
Jun 04 03:26:16 ipaserver.linux.kali.it ipactl[3915]: Starting pki-tomcatd Service
Jun 04 03:26:16 ipaserver.linux.kali.it ipactl[3915]: Starting smb Service
Jun 04 03:26:17 ipaserver.linux.kali.it systemd[1]: ipa.service: main process exited, code=exited, status=1/FAILURE
Jun 04 03:26:17 ipaserver.linux.kali.it systemd[1]: Failed to start Identity, Policy, Audit.
Jun 04 03:26:17 ipaserver.linux.kali.it systemd[1]: Unit ipa.service entered failed state.
Jun 04 03:26:17 ipaserver.linux.kali.it systemd[1]: ipa.service failed.
[root@ipaserver ~]#systemctl restart ipa

From another shell, before that freeipa goes down a samba service principal must be created and the keytab imported on ipaserver.

[root@ipaserver ~]# kinit admin
Password for admin@LINUX.KALI.IT:
[root@ipaserver run]# ipa service-add cifs/ipaserver.linux.kali.it@LINUX.KALI.IT –force
———————————————————-
Added service “cifs/ipaserver.linux.kali.it@LINUX.KALI.IT”
———————————————————-
Principal: cifs/ipaserver.linux.kali.it@LINUX.KALI.IT
Managed by: ipaserver.linux.kali.it
[root@ipaserver run]# ipa-getkeytab -s ipaserver.linux.kali.it -p cifs/ipaserver.linux.kali.it@LINUX.KALI.IT -k /etc/samba/samba.keytab
Keytab successfully retrieved and stored in: /etc/samba/samba.keytab

Now it’s time, with AD Administrator credential, to enable the trust beewten freeipa and active directory.

[root@ipaserver ~]# ipa trust-add –type=ad kali.it –admin Administrator –password
Active Directory domain administrator’s password:
————————————————
Added Active Directory trust for realm “kali.it”
————————————————
Realm name: kali.it
Domain NetBIOS name: KALI
Domain Security Identifier: S-1-5-21-3730397366-1172298099-1548305149
SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17,
S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0,
S-1-5-19, S-1-5-18
SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17,
S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0,
S-1-5-19, S-1-5-18
Trust direction: Trusting forest
Trust type: Active Directory domain
Trust status: Established and verified
[root@ipaserver ~]#

In Active Directory:

Freeipa Active Directory Trust

Freeipa Active Directory Trust

Add these lines in /etc/krb5.conf and restart kadmin and sssd.

[root@ipaserver ~]# vi /etc/krb5.conf
dns_lookup_realm = true
dns_lookup_kdc = true
[realms]
auth_to_local = RULE:[1:$1@$0](^.*@KALI.IT)s/@KALI.IT/@kali.it/
auth_to_local = DEFAULT
[root@ipaserver ~]# systemctl restart sssd
[root@ipaserver ~]# systemctl restart kadmin

The last step to do is to create external group mapped to posix freeipa group: it permit to give to right grant to external group. Following the active directory domain admin group is mapped to ad_admins group that belongs to admins user. In this case every domain admin windows has the some grant of admin freeipa:

[root@ipaserver ~]# ipa group-add –desc=’ad_domain admins external map’ ad_admins_external –external
——————————–
Added group “ad_admins_external”
——————————–
Group name: ad_admins_external
Description: ad_domain admins external map
[root@ipaserver ~]# ipa group-add –desc=’ad_domain admins’ ad_admins
———————–
Added group “ad_admins”
———————–
Group name: ad_admins
Description: ad_domain admins
GID: 5400004
[root@ipaserver ~]# ipa group-add-member ad_admins_external –external ‘KALI\Domain Admins’
[member user]:
[member group]:
Group name: ad_admins_external
Description: ad_domain admins external map
External member: S-1-5-21-3730397366-1172298099-1548305149-512
————————-
Number of members added 1
————————-
[root@ipaserver ~]# ipa group-add –desc=’ad_domain admins’ ad_admins
[root@ipaserver ~]# ipa group-add-member ad_admins –groups ad_admins_external
Group name: ad_admins
Description: ad_domain admins
GID: 5400004
Member groups: ad_admins_external
————————-
Number of members added 1
————————-
[root@ipaserver ~]# ipa group-add-member admins –groups ad_admins
Group name: admins
Description: Account administrators group
GID: 5400000
Member users: admin
Member groups: ad_admins
Indirect Member groups: ad_admins_external
————————-
Number of members added 1

If everything has been done fine, it will be possible to login by ssh to ipaserver with a windows user without credentials. Remember to align the date on Windows and Linux system to equal value.

[root@ipaserver ~]# kinit Administrator@KALI.IT
Password for Administrator@KALI.IT:
[root@ipaserver ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: Administrator@KALI.IT
Valid starting Expires Service principal
06/04/2016 07:42:34 06/04/2016 17:42:34 krbt
[root@ipaserver ~]# ssh -l Administrator@kali.it ipaserver.linux.kali.it
Could not chdir to home directory /home/kali.it/administrator: No such file or directory
-sh-4.2$ exit
logout
Connection to ipaserver.linux.kali.it closed.
[root@ipaserver ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: Administrator@KALI.IT
Valid starting Expires Service principal
06/04/2016 07:43:08 06/04/2016 17:42:34 host/ipaserver.linux.kali.it@LINUX.KALI.IT
renew until 06/05/2016 07:42:31
06/04/2016 07:43:22 06/04/2016 17:42:34 krbtgt/LINUX.KALI.IT@KALI.IT
renew until 06/05/2016 07:42:31
06/04/2016 07:42:34 06/04/2016 17:42:34 krbtgt/KALI.IT@KALI.IT
renew until 06/05/2016 07:42:31
[root@ipaserver ~]#

Perfect: the ssh login completed without password. The sssd using the windows TGT obtained by kinit asks a new TGT for linux domain. The AD releases to sssd a TGT signed with a secret key shared with KDC freeipa. With this ticket the sssd asks with success a service ticket for host/ipaserver.linux.kali.it@LINUX.KALI.IT to KDC Linux

These kerberos transactions will be explained better after client freeipa installation and configuration.

Freeipa Client Installation

The freeipa client is installed on centos 7 linux machine. After installing and configuring it, it’s possible to login by ssh with windows credential or using service ticket obtained from a windows user authenticated to a windows client.

The first thing to do, after installing ipa client, is to configure it.

[root@ipaclient etc]#more hosts |grep ipa
192.168.1.52 ipaclient.linux.kali.it ipaclient
192.168.1.51 ipaserver.linux.kali.it
[root@ipaclient etc]#more resolver.conf
192.168.1.51 ipaserver.linux.kali.it
[root@ipaclient etc]# yum -y install ipa-client
[root@ipaclient ~]# ipa-client-install –hostname=ipaclient.linux.kali.it –server=ipaserver.linux.kali.it –domain=linux.kali.it –realm=LINUX.KALI.IT –enable-dns-updates –mkhomedir
Autodiscovery of servers for failover cannot work with this configuration.
If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]: yes
Client hostname: ipaclient.linux.kali.it
Realm: LINUX.KALI.IT
DNS Domain: linux.kali.it
IPA Server: ipaserver.linux.kali.it
BaseDN: dc=linux,dc=kali,dc=it

The sssd configuration must be changed in this way (in bolt the new configurations):

[root@ipaclient sssd]# vi sssd.conf
[domain/linux.kali.it]
override_shell=/bin/bash
homedir_substring = /home
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = linux.kali.it
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ipaclient.linux.kali.it
chpass_provider = ipa
dyndns_update = True
ipa_server = _srv_, ipaserver.linux.kali.it
dyndns_iface = enp0s3
ldap_tls_cacert = /etc/ipa/ca.crt
sudo_provider = ldap
ldap_uri = ldap://ipaserver.linux.kali.it
ldap_sudo_search_base = ou=sudoers,dc=lx,dc=kali,dc=it
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/ipclient.linux.kali.it
ldap_sasl_realm = LINUX.KALI.IT
krb5_server = ipaserver.linux.kali.it
[sssd]
services = nss, sudo, pam, ssh,pac
config_file_version = 2
domains = linux.kali.it

In the krb5.conf the following line need to add inside realms section:

auth_to_local = RULE:[1:$1@$0](^.*@KALI.IT)s/@KALI.IT/@kali.it/

The dns_lookup must be true: it force the sssd to find by dns query the active directory services

dns_lookup_realm = true
dns_lookup_kdc = true

Check in the nsswitch.conf the presence of the following line:

sudoers: files sss

Now the sssd and ssh can be started:

[root@ipaclient etc]# systemctl restart sssd
[root@ipaclient etc]# systemctl restart ssh

If everything has been done fine, the ssh kerberos authentication to ipaclient from freeipa client or windows client must be completed with success.

Below the ssh connection is done by ipaserver. The user used is windows administrator that has the right grant to access to any system because the domain admins belong to freeipa admin.

[root@ipaserver ~]# kinit Administrator@KALI.IT
Password for Administrator@KALI.IT:
kinit: Preauthentication failed while getting initial credentials
[root@ipaserver ~]# kinit Administrator@KALI.IT
Password for Administrator@KALI.IT:
[root@ipaserver ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: Administrator@KALI.IT
Valid starting Expires Service principal
06/04/2016 10:44:34 06/04/2016 20:44:34 krbtgt/KALI.IT@KALI.IT
renew until 06/05/2016 10:44:33
[root@ipaserver ~]# ssh -l Administrator@kali.it ipaclient.linux.kali.it
Last login: Sat Jun 4 10:40:58 2016 from ipaserver.linux.kali.it
[administrator@kali.it@ipaclient ~]$ id
uid=97200500(administrator@kali.it) gid=97200500(administrator@kali.it) groups=97200500(administrator@kali.it),5400000(admins),5400004(ad_admins),97200512(domain admins@kali.it),97200513(domain users@kali.it),97200518(schema admins@kali.it),97200519(enterprise admins@kali.it),97200520(proprietari autori criteri di gruppo@kali.it)
[administrator@kali.it@ipaclient ~]$ pwd
/home/kali.it/administrator
[administrator@kali.it@ipaclient ~]$ exit
logout
Connection to ipaclient.linux.kali.it closed.
[root@ipaserver ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: Administrator@KALI.IT
Valid starting Expires Service principal
06/04/2016 10:42:04 06/04/2016 20:44:34 host/ipaclient.linux.kali.it@LINUX.KALI.IT
renew until 06/05/2016 10:44:33
06/04/2016 10:44:43 06/04/2016 20:44:34 krbtgt/LINUX.KALI.IT@KALI.IT
renew until 06/05/2016 10:44:33
06/04/2016 10:44:34 06/04/2016 20:44:34 krbtgt/KALI.IT@KALI.IT
renew until 06/05/2016 10:44:33

The freeipa client installation and configuration is completed. In the next paragraph an real life example is showed: a windows user with sudo grant connects to linux system and from here changes his password in active directory.

Freeipa and windows user with sudo grant

The trust beewteen active directory and freeipa has been completed. A windows user from windows system can login remoteley by ssh to linux world using kerberos authenticating.

For our case the administrator user is used for the tests. As done above, the domain admins belong to admin freeipa group: it has the grant for login to all linux systems.

After installing winscp on windows system, we tried successfully the ssh kerberos authentication:

winscp kerberos authentication

winscp active directory trust

winscp active directory trust

winscp kerberos authentication

We could do the same login by a normal domain users. The important thing is to create on freeipa the right mapping beewteen domain users and freeipa group and give to this freeipa group the right grant for accessing to linux system. All that can be done by GUI freeipa.

Next the Administrator windows user is able to change his password correctly on linux system:

[administrator@kali.it@ipaclient ~]$ passwd
Changing password for user administrator@kali.it.
Current Password:
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[administrator@kali.it@ipaclient ~]$ kinit Administrator@KALI.IT
Password for Administrator@KALI.IT:
[administrator@kali.it@ipaclient ~]$ klist
Ticket cache: KEYRING:persistent:97200500:krb_ccache_Q2NIGAo
Default principal: Administrator@KALI.IT
Valid starting Expires Service principal
06/09/2016 08:43:02 06/09/2016 18:43:02 krbtgt/KALI.IT@KALI.IT
renew until 06/10/2016 08:42:58
[administrator@kali.it@ipaclient ~]$

Configuring a sudo policy on freeipa for ad_admins,  it’s possible to get root permission by sudo command.

Configure the sudo rule on freeipa by GUI clicking on add button in Policy/Sudo sheet.

ssh kerberos authentication

ssh kerberos authentication

Let’s try now the “sudo su -” command:

[root@ipaserver ~]# kinit Administrator@KALI.IT
Password for Administrator@KALI.IT:
[root@ipaserver ~]# ssh -l Administrator@kali.it ipaclient.linux.kali.it
Last login: Thu Jun 9 09:03:11 2016 from ipaserver.linux.kali.it
[administrator@kali.it@ipaclient ~]$ id
uid=97200500(administrator@kali.it) gid=97200500(administrator@kali.it) groups=97200500(administrator@kali.it),5400000(admins),5400004(ad_admins),5400005(ad_users),97200512(domain admins@kali.it),97200513(domain users@kali.it),97200518(schema admins@kali.it),97200519(enterprise admins@kali.it),97200520(proprietari autori criteri di gruppo@kali.it)
[administrator@kali.it@ipaclient ~]$ pwd
/home/kali.it/administrator
[administrator@kali.it@ipaclient ~]$ sudo su –
Last login: Thu Jun 9 09:33:35 CEST 2016 from 192.168.1.5 on pts/1
[root@ipaclient ~]#

Following the kerberos packet exchanged between linux system with active directory kerberos and with freeipa kdc:

freeipa active directory

freeipa active directory

  1. AS/REQ is sent from linux sytem to active directory kerberos. The ad kerebros ip address is detected by dns: a srv query like _kerberos._udp.kali.it.
  2. The AD returns in AS REP a TGT that is used next for a service ticket to host/ipaclient.linux.kali.it@LINUX.KALI.IT. The TGT_REQ for this service ticket is always sent to AD.
  3. The AD returns in TGT_REP a new ticket signed with a key shared with freeipa during trust procedure.
  4. With the ticket above, the linux client can ask to freepa KDC the service ticket for host/ipaclient.linux.kali.it@LINUX.KALI.IT.

The important thing to understand is that: Active directory manages the authentication, freeipa the authorization. That’s all.

Conclusions

The freeipa trust with active directory is very interesting for a company. The access to linux system is centralized in active directory and freeipa has the responsability for the authorization process.

It’s possible to have more freeipa server replicated with more linux domains under a principal domain that is in trusted with windows. In this way every organizational unit with its domain (uk.linux.kali.it, fr.linux.kali.it, etc..)  is trusted with active directory domain root kali.it.

The freeipa is the right and best solution for who wants to have an identity management like active directory for linux world. Use it and you will save time for managing the linux authentication and authorization process.

Doesn’t hesitate to contact me for any problem during freeipa trust installation and configuration.

13 thoughts on - Freeipa Active Directory Trust

  • Stefano,
    Excellent instructions; this is the closest to what I’ve been trying to do. I need to allow AD users the right to login to a Linux host and run ‘sudo’. These are the same steps I had used, but I’m continually getting errors with ‘sudo’ that the user is not in the sudoers file. I have a 2012 AD domain (one way trust) with a CentOS 7.2 IPA domain. I’ve found some troubleshooting documentation regarding problems with sssd 1.13 (need 1.14), but from your instructions, it doesn’t seem to be an issue.
    Do you have any suggestions? Thanks!

     
  • This is one of the best technical blog post ever. Identity management is a big headache in the industry. Your best was very detailed and well explained. I have a similar setup done 2 years ago. It took me a long time before I was able to figure this out. Good job

     
  • Great guide. Thanks for sharing.
    I’m trying to find how to grant AD users access to freeipa UI and assign SSH Public Key to them. Any ideas ? Thanks.

     
    • Great Question. I think that this is not possible. The ssh public key can be assigned only to freeipa user. I will investigate about it.

      You could use GSS API authentication for having a free password authentication.

      I will let you know.

      Stefano

       
  • The method from the link I pasted should do the trick, but in my case it takes ages for the submitted public key to work.

     
  • Hello.
    can anybody explain here why
    “ipa trust-add –type=ad win.ipa –admin Administrator –password –two-way=true”
    command not working. I always got thos message

    “ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most likely it is a DNS or firewall issue”
    from IPA and
    “This computer was not able to set up a secure session with a domain controller in domain LIN due to the following:
    There are currently no logon servers available to service the logon request.
    This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.”
    from AD side

     
    • Hi Saimon,

      You must be sure before starting the trust command that the dns integration between IPA and Windows has already been done.

      From Linux, this command must work:

      dig SRV _ldap._tcp.win.ipa.

      This permit to ipa to discovery the win.ipa Controller domain.

      Let me know if it’s enough.

      Best Regards

      Stefano

       
      • Hello. Thank you for help.
        DNS resolving works correctly
        But i cant establish trust.
        one way trust worked once before reboot
        and it did not showed sid blacklists when trust was established

         
        • Hi,

          The important thing is to have this in the output result:

          Trust direction: Trusting forest
          Trust type: Active Directory domain
          Trust status: Established and verified

          Stefano

           

LEAVE A COMMENT