Features/ActiveDirectory/TestBed

Active Directory Test Domain

Note: In order to test Active Directory effectively you usually need sssd 1.9.x and realmd 0.9.x or later.

Verifying Domain Access

Use the following commands to do some basic smoke testing that your domain DNS works. The output should look similar, replace the dummy domain names (ie: AD.EXAMPLE.COM) and IP addresses (ie: X.X.X.X) with your own.

$ host AD.EXAMPLE.COM
ad.example.com has address X.X.X.X
$ host -t SRV _kerberos._udp.AD.EXAMPLE.COM
_kerberos._udp.ad.example.com has SRV record 0 100 88 domain-controller.ad.example.com.
$ host -t SRV _kerberos._tcp.dc._msdcs.AD.EXAMPLE.COM
_kerberos._tcp.dc._msdcs.ad.example.com has SRV record 0 100 88 domain-controller.ad.example.com.

• If any of the above fail, then DNS is not working properly for your domain. If you set it up yourself, then make sure you the domain delegated to the Active Directory DNS server, or are using a local caching server to forward the domain to the Active Directory DNS server.
• If for some reason your DNS is not setup correctly, follow the instructions below to Setup a Local Caching Server

Use the following commands to test that kerberos is working on you client, and connecting properly to Active Directory. You need an Active Directory domain user account to do this.

$ kinit user@AD.EXAMPLE.COM
Password for user@AD.EXAMPLE.COM

• Make sure that you capitalize the domain name.
• If the above fails with 'Preauthentication failed' then you probably typed the wrong password.
• If the above fails with 'Clock skew' that means your clock and that of the domain are not syncronized. If you setup the Active Directory domain, set its clock appropriately, or use ntpdate to sync time.
• In future Fedora releases clock skew will not be an issue.

Now actually connect to the LDAP directory in Active Directory. You will need the <package>openldap-clients</package> installed to do this. The previous kinit step is a necessary prerequisite for this one. The ticket it retrieved is necessary to do make this LDAP connection.

$ ldapwhoami -H ldap://AD.EXAMPLE.COM -Y GSSAPI
SASL/GSSAPI authentication started
SASL username: user@AD.EXAMPLE.COM
SASL SSF: 56
SASL data security layer installed.
u:AD\user

• No password should be prompted.
• If the above fails with 'Cannot determine realm for numeric host address', but the kinit succeeded, then you liekly have DNS problems.
• If for some reason your DNS is not setup correctly, follow the instructions below to Setup a Local Caching Server

Corporate domain

If you have a real deployed Active Directory domain to test against, this is the best scenario.

In order to test realmd effectively you'll need to be able to create computer accounts in the domain. Sometimes this means you'll have Administrative credentials for the domain. In other cases, you may have been delegated a specific OU which you are able to create accounts in.

To tell realmd to create computer accounts in a specific OU, add something like the following to your /etc/realmd.conf

[domain.example.com]
computer-ou = OU=Linux Computers,DC=domain,DC=example,DC=com

For more details see: http://www.freedesktop.org/software/realmd/docs/guide-configuring-realm.html

For deeper testing you should be able to access the domain and create accounts.

Personal domain

You can setup your own personal 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.

Make sure to Setup a Local Caching Server and verify that the access is AOK.

Red Hat Active Directory Test Bed

WARNING: This server is no longer in operation

If you're on the Red Hat internal network, there's an Active Directory server available for testing. Unfortunately, it is not clear whether this can be made available to the public at this time. In addition this works poorly for testing if you're on a VPN. Because the VPN connection must be up before the Active Directory domain is accessible.

Domain: radi08.segad.lab.sjc.redhat.com
Kerberos Realm: RADI08.SEGAD.LAB.SJC.REDHAT.COM
Domain Controller: ad1.radi08.segad.lab.sjc.redhat.com
Domain Controller IP: 10.14.5.60

However, the Red Hat Active Directory test bed does not yet have DNS configured appropriately. See below for how to do that.

The following users and groups are available on the Test Bed. Add your name when you claim one of them as your own user. Each user has a preset password, which requires changing the first time you use it. You can change the user's password with:

$ kpasswd user@RADI08.SEGAD.LAB.SJC.REDHAT.COM

The initial preset password is: My secret password4

Secondary Active Directory Test Bed

This server is no longer working => use the main test bed only.

There's also a secondary testing Active Directory server run by jpospisi. It has the same user names, groups and initial password as the main test bed and it also lacks proper DNS configuration. Its details are:

Domain: security.baseos.qe
Kerberos Realm: SECURITY.BASEOS.QE
Domain Controller: redmond.security.baseos.qe
Domain Controller IP: 10.34.0.231

Current use of accounts

User	Member of	On primary test bed claimed by	On secondary test bed claimed by
Amy	Planet Express, Test Users	omoris
Bender	Planet Express, Test Users	pkis
Dwight	Test Users
Hermes	Planet Express, Test Users
Farnsworth	Planet Express, Test Users
Zoidberg	Planet Express, Test Users	mvadkert
Kif	Test Users
LaBarbara	Test Users
Wernstrom	Test Users
Fry	Planet Express, Test Users	stefw
Leela	Planet Express, Test Users	jhrozek
Zapp	Test Users

If you need your user to be made an Administrator, then contact stefw on IRC.

Setup a Local Caching Server

Setting up a Local DNS Caching Server allows you to forward certain domains to the Active Directory DNS server directly, without bugging you admins, local router, (or ISP, ha) to do so.

• Install bind like so:

# yum install caching-nameserver

• Don't add a forwarders line.
• And add this to the end of /etc/named.conf. In the example below 'ad.example.com' is the Active Directory domain, and 'A.B.C.D' are the octets of the IPv4 address that the Active Directory controller is listening on. Note that in the second line, you use the first three octets of this IPv4 address in reverse.

zone "ad.example.com" { type stub; masters { A.B.C.D; }; };
zone "C.B.A.in-addr.arpa" { type stub; masters { A.B.C.D; }; };

• For the above Red Hat Active Directory Test Bed, the snippet to add is as follows. You can also use this as a guide for how to munge the IPv4 address on the second line.

zone "radi08.segad.lab.sjc.redhat.com" { type stub; masters { 10.14.5.60; }; };
zone "5.14.10.in-addr.arpa" { type stub; masters { 10.14.5.60; }; };
zone "redhat.com" { type stub; masters {10.38.5.11; 10.38.5.12; }; };

• Restart the named service with:

# systemctl restart named.service

• Before configuring your host to use the local caching nameserver, test it with commands like:

# host radi08.segad.lab.sjc.redhat.com 127.0.0.1
radi08.segad.lab.sjc.redhat.com has address 10.14.5.60
# host google.com 127.0.0.1
google.com has address 209.85.148.139
...

• Once you know it's working, use nm-connection-editor to edit your connection. Choose your connection, and on the IPv4 Settings tab, choose Automatic (DHCP) addresses only. Now set 127.0.0.1 as the DNS servers.
• You should now be able to test you local server with commands like:

# host radi08.segad.lab.sjc.redhat.com
radi08.segad.lab.sjc.redhat.com has address 10.14.5.60
# host google.com
google.com has address 209.85.148.139
...