From Fedora Project Wiki

(Fixed so we don't require login, which is broken)
No edit summary
 
(One intermediate revision by the same user not shown)
Line 13: Line 13:


|actions=
|actions=
# Configure the Active Directory provider of SSSD to perform dynamic DNS updates. Open the <code>/etc/sssd/sssd.conf</code> file and put the following into the <code>[domain]</code> section:
# Configure the Active Directory provider of SSSD to perform dynamic DNS updates. Open the <code>/etc/sssd/sssd.conf</code> file and put the following into the <code>[domain/$DOMNAME]</code> section:
#: <pre> dyndns_update = True </pre>
#: <pre> dyndns_update = True </pre>
# Save the <code>sssd.conf</code> and restart the SSSD:
# Save the <code>sssd.conf</code> and restart the SSSD:
Line 27: Line 27:
# Restart the SSSD to make sure its online status is reset.
# Restart the SSSD to make sure its online status is reset.
# Log in as an AD user to make sure the SSSD connects to the remote server.
# Log in as an AD user to make sure the SSSD connects to the remote server.
#: To work around the login bug, you can also request a user that does not exist on the AD
#: <code>getent passwd ADSERVER\\nosuchser</code>
# Look into the "DNS Manager" MMC concole on the AD server. The record of your client machine should have been updated with the address you changed the client's IP address to. The reverse zone (if present) should be updated, too.
# Look into the "DNS Manager" MMC concole on the AD server. The record of your client machine should have been updated with the address you changed the client's IP address to. The reverse zone (if present) should be updated, too.
# The timestamp of a dynamically added record will be updated, but rounded down to the nearest hour by AD automatically.
}}
}}



Latest revision as of 15:46, 16 May 2013

Description

This test case verifies an Active Directory client is able to update its DNS record.

Setup

  1. Verify that your Active Directory domain access works. If you don't have an Active Directory domain, you can set one up.
  2. Run through the test case to join the domain.
  3. Make sure that your Active Directory Server manages the DNS domain of your client
    In the DNS manager, make sure that the DNS zone of your client is present in the "Forward Lookup Zones" subtreee
    For example, if your client was configured with a host name client.example.com, then you'd be looking for a zone called example.com in the DNS manager
  4. Make sure DNS updates are enabled on the zone
    Right-click the zone and select the "Properties->General" tab
    There is a combo-box labeled "Dynamic updates". Toggle it to "Secure only".
    Click "Apply"

How to test

  1. Configure the Active Directory provider of SSSD to perform dynamic DNS updates. Open the /etc/sssd/sssd.conf file and put the following into the [domain/$DOMNAME] section:
     dyndns_update = True 
  2. Save the sssd.conf and restart the SSSD:
    $ sudo service sssd restart 
  3. Clear caches and retrieve user information to make sure the SSSD connects to the remote server.
    $ sudo sss_cache --users
    getent passwd 'DOMAIN\user'

Expected Results

  1. Look into the "DNS Manager" MMC concole on the AD server. The record of your client machine should have been "refreshed" and you should see a "timestamp" value with the date and time of when you connected to the AD
    Make sure to refresh the "DNS Manager" MMC
  2. Change the IP address of the client by assigning some unused address manually
  3. Restart the SSSD to make sure its online status is reset.
  4. Log in as an AD user to make sure the SSSD connects to the remote server.
    To work around the login bug, you can also request a user that does not exist on the AD
    getent passwd ADSERVER\\nosuchser
  5. Look into the "DNS Manager" MMC concole on the AD server. The record of your client machine should have been updated with the address you changed the client's IP address to. The reverse zone (if present) should be updated, too.
  6. The timestamp of a dynamically added record will be updated, but rounded down to the nearest hour by AD automatically.



Cleanup after the test

  1. Don't forget to restore the IP address to the original value after completing the test

Troubleshooting

  1. Make sure the Active Directory server is reachable and the SSSD can connect to the AD
    A good way to make sure is to log in as a domain user while cached_credentials is set to False
  2. Check if the client contains the IP address of the AD server in /etc/resolv.conf
  3. Raise the SSSD debugging
    put debug_level=8 into the [domain] section of the sssd.conf and restart the SSSD
    inspect the SSSD logs, search for nsupdate. Make sure there is a nsupdate message that contains the name of your client machine and its current IP address