Testing Fedora 18 Active Directory Integration

realmd is a DBus based management service that configures membership of realms/domains on the local machine.

realmd documentation: http://www.freedesktop.org/software/realmd/docs/index.html

In addition many bugs and brittleness have been fixed in krb5. This documentation involves some testing of that as well.

Preparation

In order to test realmd with Active Directory, you need the following.

An Active Directory domain to test against. You should have credentials for an administrative account on this domain. For deeper testing you should be able to access the domain and create accounts.

Obviously for real life testing using an already deployed Active Directory domain is desirable. But if you don't have access to an Active Directory domain, here's how to install Windows Server 2008 for free and set one up: http://stef.thewalter.net/2012/08/how-to-create-active-directory-domain.html

Note that the Active Directory will need to be appropriately discoverable via DNS, as it would be "in real life". If DNS is not setup for your Active Directory domain, you can also use steps 8 and 9 in the linked setup instructions above to make DNS work appropriately on your test machine for your domain.

In the following documentation we'll use ad.example.com when referring to the domain.

To install realmd from source:

$ sudo yum install realmd

To build and install realmd from source, do something like this:

$ git clone git://anongit.freedesktop.org/realmd/realmd
$ cd realmd
$ sh autogen.sh --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib64 --enable-debug
$ make
$ sudo make install
$ sudo restorecon -Rv /etc/dbus-1 /usr/bin/realm /usr/lib64/realmd /usr/share/dbus-1 /usr/share/polkit-1

If you wish to later go back to the Fedora 18 version of realmd, just reinstall realmd:

$ sudo yum reinstall realmd

Test using domain without krb5.conf

Work has been done to make krb5.conf configurationless, and unbreak the default /etc/krb5.conf that was distributed with Fedora 17 and earlier.

Move /etc/krb5.conf away.

$ sudo mv /etc/krb5.conf /etc/krb5.conf.bak

If you wish to test with a default neutral /etc/krb5.conf file, use the following file, as included in the krb5-libs package:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
# default_realm = EXAMPLE.COM

[realms]
# EXAMPLE.COM = {
#  kdc = kerberos.example.com
#  admin_server = kerberos.example.com
# }

[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM

But again, it is not required to have a /etc/krb5.conf at all.

Now do a kinit against your Active Directory domain:

$ kinit Administrator@AD.EXAMPLE.COM
$ klist -e

You should see kerberos tickets listed.

Possible non-systemic problems:

Make sure the domain is capitalized as above. This is the kerberos realm name for the Active Directory domain.
Make sure that the domain can be resolved via DNS: $ host -t SRV _kerberos._udp.ad.example.com

Test realmd Discovery

realmd discovers domains and what kind of domain they are. To test this use the realm command to drive realmd.

Against an Active Directory domain the output should look like this:

$ realm discover --verbose ad.example.com
 * Searching for kerberos SRV records for domain: _kerberos._udp.ad.example.com
 * Searching for MSDCS SRV records on domain: _kerberos._tcp.dc._msdcs.ad.example.com
 * dc.ad.example.com:88 
 * Found kerberos DNS records for: ad.example.com
 * Found AD style DNS records for: ad.example.com
 * Successfully discovered: ad.example.com
AD.EXAMPLE.COM
  configured: no
  type: active-directory
  realm-name: AD.EXAMPLE.COM
  domain-name: ad.example.com

Against an IPA domain the output should look something like this:

$ realm --verbose discover ipa.example.com
 * Searching for kerberos SRV records for domain: _kerberos._udp.ipa.example.com
 * Searching for MSDCS SRV records on domain: _kerberos._tcp.dc._msdcs.ipa.example.com
 * dc.ipa.example.com:88
 * Trying to retrieve IPA certificate from dc.ipa.example.com
 ! Couldn't read certificate via HTTP: No PEM-encoded certificate found
 ! Couldn't discover IPA KDC: No PEM-encoded certificate found
 * Found kerberos DNS records for: ipa.example.com
 * Successfully discovered: ipa.example.com
NULLROUTE.EU.ORG
  configured: no
  type: freeipa
  realm-name: IPA.EXAMPLE.COM
  domain-name: ipa.example.com

Against a generic kerberos domain, such as redhat.com, or nullroute.eu.org, it should look something like this:

$ realm discover --verbose nullroute.eu.org
 * Searching for kerberos SRV records for domain: _kerberos._udp.nullroute.eu.org
 * Searching for MSDCS SRV records on domain: _kerberos._tcp.dc._msdcs.nullroute.eu.org
 * virgule.cluenet.org:88 panther.nathan7.eu:88 
 * Trying to retrieve IPA certificate from virgule.cluenet.org
 * Trying to retrieve IPA certificate from panther.nathan7.eu
 ! Couldn't read certificate via HTTP: No PEM-encoded certificate found
 ! Couldn't discover IPA KDC: No PEM-encoded certificate found
 * Found kerberos DNS records for: nullroute.eu.org
 * Successfully discovered: nullroute.eu.org
NULLROUTE.EU.ORG
  configured: no
  type: kerberos
  realm-name: NULLROUTE.EU.ORG
  domain-name: nullroute.eu.org

Join an Active Directory domain using sssd

Join the current machine to an Active Directory domain using sssd as an AD client. Domain accounts are usable on the local machine once this is done.

$ realm join ad.example.com
Password for Administrator:

You can use the --user argument to specify a different user other than Administrator. If you use the --verbose command you can see the details of what's going on:

$ realm join --verbose ad.example.com
 * Searching for kerberos SRV records for domain: _kerberos._udp.ad.example.com
 * Searching for MSDCS SRV records on domain: _kerberos._tcp.dc._msdcs.ad.example.com
 * dc.ad.example.com:88 
 * Found kerberos DNS records for: ad.example.com
 * Found AD style DNS records for: ad.example.com
 * Successfully discovered: ad.example.com
 * Required files present: /usr/sbin/sssd, /usr/sbin/adcli
 * LANG=C /usr/sbin/adcli join --verbose --show-details --domain AD.EXAMPLE.COM --login-type computer --no-password
 ! Couldn't find qualified domain name, proceeding with local host name instead: local-machine.example.com: Name or service not known
 * Using domain name: AD.EXAMPLE.COM
 * Calculated computer account name from fqdn: AD.EXAMPLE.COM
 * Calculated domain realm from name: AD.EXAMPLE.COM
 * Resolved LDAP urls from SRV record: _ldap._tcp.AD.EXAMPLE.COM: ldap://dc.ad.example.com:389
 ! Couldn't authenticate as machine account: LOCAL-MACHINE: Client not found in Kerberos database
adcli: couldn't connect to AD.EXAMPLE.COM domain: Couldn't authenticate as machine account: LOCAL-MACHINE: Client not found in Kerberos database
 ! Insufficient permissions to join the domain
Password for Administrator: 
 * Required files present: /usr/sbin/sssd, /usr/bin/net
 * LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf conf setparm global realm AD.EXAMPLE.COM
 * LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf -U Administrator ads join AD.EXAMPLE.COM
Enter Administrator's password:
Using short domain name -- AD
Joined 'LOCAL-MACHINE' to realm 'ad.example.com'
 * LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf -U Administrator ads keytab create
Enter Administrator's password:
 * LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf conf list
[global]
	workgroup = AD
	security = ads
	realm = ad.example.com
 * /usr/bin/systemctl enable sssd.service
 * /usr/bin/systemctl restart sssd.service
 * /usr/sbin/authconfig --update --enablesssd --enablesssdauth
 * Successfully enrolled machine in realm

At this point you should be able to resolve domain accounts locally:

$ getent passwd 'AD\Administrator'
AD\administrator:*:1344600500:1344600513:Administrator:/home/AD/administrator:/bin/bash

You can see that you're joined to the domain with the following command:

$ realm list

Possible problems:

Anaconda in Fedora 18 fails to set up a host name. Make sure this is set in advance.
Clock skew is too great. Work was done to make the clock skew not matter, however this did not make it into Fedora 18. In the interim, make sure your Active Directory domain and local machine are both using NTP. Make sure the timezone on both machines are correct.

Leave an Active Directory domain

Now that you're joined to an Active Directory domain, you can leave it as well.

$ realm leave 
Password for Administrator:

If you want to see details of what's going on, or specify the domain explicitly you can do it like this:

$ realm leave --verbose ad.example.com
Password for Administrator: 
 * LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf -U Administrator ads keytab flush
Enter Administrator's password:
 * LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf -U Administrator ads leave
Enter Administrator's password:
Deleted account for 'LOCAL-MACHINE' in realm 'AD.EXAMPLE.COM'
 * /usr/bin/systemctl disable sssd.service
rm '/etc/systemd/system/multi-user.target.wants/sssd.service'
 * /usr/bin/systemctl stop sssd.service
 * Successfully unenrolled machine from realm

You can see that you're not joined to the domain with the following command:

$ realm list

Join an Active Directory domain using winbind

Join the current machine to an Active Directory domain using winbind as an AD client. Domain accounts are usable on the local machine once this is done.

$ realm join --verbose --client-software=winbind ad.example.com
Password for Administrator: