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 X.X.X.X X.X.X.X.in-addr.arpa domain name pointer domain-controller.AD.EXAMPLE.COM. $ 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
ntpdateto 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
kinitsucceeded, 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
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
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 | ||
| Bender | Planet Express, Test Users | ||
| 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 | ksrot | |
| 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
forwardersline. - 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 ...