QA:Testcase Active Directory Setup

These are requirements for the various Active Directory test cases.

In the following instructions replace ad.example.com with your active directory domain, and X.X.X.X with the IP address of an active directory domain controller.

Active Directory

For these tests you need to have a valid active directory domain. You can set one up like this: http://stef.thewalter.net/how-to-create-active-directory-domain.html

DNS Setup

For most of the adcli tests you'll need working DNS access. Some of the tests ask you to break that DNS access, but that will be explicitly noted.

If your Active Directory server is not resolvable using your normal DNS servers, you can temporarily replace your /etc/resolv.conf with one that looks like:

nameserver X.X.X.X

• The Active Directory server you choose should be running DNS. This is the default behavior if you set up your own Active Directory server.
• You would replace the IP address above with the IP address of your Active Directory server.

Alternatively you can setup a local caching server that routes DNS requests for the Active Directory domain to that server.

If you choose to place the Active Directory DNS records directly in another non-Active Directory DNS server, then you need to make sure they're all there: http://technet.microsoft.com/en-us/library/cc961719.aspx

Testing DNS

Use the following commands to do some basic smoke testing that your domain DNS works. The output should look similar, obviously specifics different for your domain.

$ 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 _ldap._tcp.ad.example.com
_ldap._tcp.ad.example.com has SRV record 0 100 389 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.

Kerberos Setup

Your /etc/krb5.conf shouldn't have the domain listed. It should be relatively simple without non-standard options. You should have the rdns = false option.

In general you could have a /etc/krb5.conf that looks like this (without anything else):

[libdefaults]
  rdns = false

This is the default in Fedora 19 and later, but you may need to add the rdns setting if you're testing elsewhere.

Testing Kerberos

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.
  • You should not see this message with krb5 1.11 or later (ie: using Fedora 19 or later)

LDAP

You should be able to connect to the Active Directory LDAP using Kerberos (ie: GSSAPI).

There is one required option to do this reliably. In /etc/openldap/ldap.conf you should have the line:

SASL_NOCANON on

This will be the default in Fedora 19 and later. See rhbz #949864.

Testing LDAP

Use the following commands to test your LDAP access:

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

Use the SRV record to find a domain controller, and then use it to connect to LDAP:

$ host -t SRV _ldap._tcp.ad.example.com
_ldap._tcp.ad.example.com has SRV record 0 100 389 domain-controller.ad.example.com.
$ ldapwhoami -Y GSSAPI -H ldap://domain-controller.ad.example.com
SASL/GSSAPI authentication started
SASL username: user@AD.EXAMPLE.COM
SASL SSF: 56
SASL data security layer installed.
u:AD\user

Using the SRV records directly requires a bit of gymnastics. Note that the %2C bits are commas:

$ ldapwhoami -Y GSSAPI -H ldap:///DC=ad%2CDC=example%2CDC=com
SASL/GSSAPI authentication started
SASL username: user@AD.EXAMPLE.COM
SASL SSF: 56
SASL data security layer installed.
u:AD\user

• There should be no error messages
• If you see the the error message Cannot determine realm for numeric host address then the SASL_NOCANON option did not take effect.
• If you see the error message Server not found in Kerberos database then you are not using the host name to connect. Use the full name of a domain controller.