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.

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.

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

Personal domain

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.

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:

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.

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.