Features/ActiveDirectory/TestBed

From FedoraProject

Jump to: navigation, search

Contents

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 and IP addresses 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 dc.ad.example.com.
$ host -t SRV _kerberos._udp.ad.example.com
_kerberos._udp.ad.example.com has SRV record 0 100 88 dc.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 dc.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 swalter@RADI08.SEGAD.LAB.SJC.REDHAT.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

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

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:

User Member of
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
Kif Test Users
LaBarbara Test Users
Wernstrom Test Users
Fry Planet Express, Test Users
Leela Planet Express, Test Users
Zapp Test Users

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
  • After the install completes, edit /etc/named.conf and add the following line to your main options section:
forwarders { 8.8.8.8; /* ... or the address of your ISP DNS server */ };
  • 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; }; };
  • 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
...