HOWTO: Managing Active Directory users under Linux with adtool

Usually people manages Linux boxes using Windows clients but sometimes, someone (like me, for example) needs to manage a Windows server from a Linux host (it could be a normal client or another server which wants to talk to Windows).

IMO, Active Directory is one of the best product from Microsoft, since it’s based on a well known standard like X.500 (aka LDAP) and it has a good interoperabilty (although it could be better, see all the problems Samba people had in the past).  So, even if there are tools like PHPLdapAdmin which are pretty good, if you need to automate users and groups management, there’s nothing better than a command line tool. Enter adtool.

adtool is very simple to use, but it’s not so simple to have it up&running, because this involves, amongst other things, to activate Secure LDAP in your Active Directory installation. To do this, you can follow this guide which will lead you through all the steps you have to do to enable LDAPS in Windows Server 2003. It may look scary but it works indeed, I used it myself.

Then, install adtool. In Debian/Ubuntu

# aptitude install adtool


Probably adtool is already present in your distribution’s repositories, so use your package manager. In the case it’s not present, simply download the adtool tarball from its homepage and do the usual

$ tar xzvf adtool-1.3.tar.gz
$ cd adtool-1.3
$ ./configure
$ make
# make install


It should be quite straightforward.
Now we have everything installed, so we can configure adtool.
Create /etc/adtool.cfg or, even better $HOME/.adtool.cfg because it will contain sensitive information, so lock it up to the user you’re willing to employ to modify Active Directory.
Put this in the config file (adapt to your needs)

uri ldaps://domain-controller.domain.tld
binddn cn=Administrator,cn=Users,dc=domain,dc=tld
bindpw $ADMIN_PASSWORD
searchbase dc=domain,dc=tld


As you can see we are using LDAPS here, because otherwise some adtool features like changing users’ passwords wouldn’t be available.
You don’t necessarily have to use the Administrator account, you can use whatever account you want, it just needs to have the right permissions (create user, change passwords etc).

So you can start poking your AD from the Linux command line, like this:

# create a new user with a dn like cn=$NAME,ou=$DEP,dc=domain,dc=tld
$ adtool usercreate "$NAME" "ou=$DEP,dc=domain,dc=tld"

# set user logon password
$ adtool setpass "$NAME" $my_secret_password

# to unlock the account (locked by default)
$ adtool userunlock "$NAME"

# to disable all the "account options" in the user's account tabe. Amongst them the "Password never expires" which is again enabled by default
$ adtool attributereplace "$NAME" userAccountControl 512

# to set user's mail address
$ adtool attributeadd "$NAME" mail user@domain.tld

# add the user to a group of users
$ adtool groupadduser $my_group "$NAME"

This could be very useful for user scripting and system integration if you’re in a mixed environment, just like we are.

HOWTO: Active Directory authentication in Ubuntu 8.04 and 8.10

This is a second version of this other guide that applied to previous Ubuntu versions.
Since Ubuntu 8.04 (Hardy Heron), and now Ubuntu 8.10 (Intrepid Ibex) it come the Likewise Open package that makes basic Active Directory authentication in Ubuntu a breeze.

Just follow these steps:

1. sudo apt-get update
2. sudo apt-get install likewise-open
3. sudo domainjoin-cli join fqdn.of.your.domain Administrator
4. sudo update-rc.d likewise-open defaults
5. sudo /etc/init.d/likewise-open start

and you can now log into your machine using your DOMAIN\user credentials. Remember that the DOMAIN\ part is mandatory and that it represents the short name of your Active Directory domain. You can join the domain using any user with sufficient privileges (there’s no need to use Administrator), and you can even directly join the PC in a particular OU passing the –ou argument to domainjoin-cli. The fourth point maybe won’t be necessary when Ubuntu 8.04 LTS wil be released because it seems to be a bug in the package (it won’t start likewise on reboot, so if you don’t issue this command it would seem that nothing is working after a reboot).

I’ve just started to use this method on a test machine so I’ll leave more opinions on this product in the future.

EDIT: First impressions

After some days of not so extensive usage, I’ve seen a couple of things that it’s worth notice:

• the likewise-open process seems to “die” from time to time, blocking all your login accesses with a “ERROR” message. Restarting it through init script solves the issue… but it’s something that definitely should not happen
• It informs you on login if your password is going to expire in X days (as set in your GPO). Very nice indeed.

Notes to the readers: if you’re experiencing installation problem, the best way is to report them to the likewise-open-discuss mailing list. There you can contact directly likewise developers (of Samba fame) and solve your problems or doubts.

EDIT2: it seems that with the final Ubuntu 8.04 update, likewise-open package is now 100% stable, I didn’t have a single failure since last update (one week up, while before it died at least once per day)

EDIT3: as mentioned in the comment, with likewise-open 4.x you can add

winbind use default domain = yes

in /etc/samba/lwiauthd.conf so you d’nt have to specify the DOMAIN\ part every time you log in your box.

Windows 2003 DHCP/DNS server and non-Windows clients

Usually, in a 100% Microsoft environment, DHCP that automagically updates the DNS entries for every new DHCP client in the network is not a problem, since every client is part of the Active Directory and every machine as by default the rights to “talk” to the DNS server and tell it which is the client’s new IP address and hostname.

But if you have other clients in your network (for example Linux, FreeBSD, embedded devices like JetPrint etc) that need DHCP and you want automatic DNS update, this will not work because they don’t have the rights to write in the DNS records list.

To solve this problem, the update has top be done by the DHCP server itself, and to do the trick you have

• Go to an AD user management snap-in
• Create a new user called, for example, dhcp2dns and make it member of the DnsUpdateProxy group
• Give a password to the dhcp2dns user
• Go to the DHCP snap-in, and select the server you want to configure
• Right click on the server name /address, and select properties
• Here, select the DNS tab
• Tick the Enable DNS dynamic updates checkbox
• Select Always dynamically update DNS A and PTR records
• Now, select the “Advanced” tab and click the “Credentials” button
• Here, put the credentials of the dhcp2dns user you have created in the first steps

and you are done, it should work or, at least, it did work for me :)

Change DNS cache expire time in Windows

Windows XP and Vista (and maybe 2000 too) by default have a DNS cache set with a 15 minutes expire time. That is, if you have made changes in your DNS server, a WinXP box will get this changes only after 15 minutes. If you want to change this, you have to add a key to the Windows Registry. Rant: add? ADD?!? why defaults have to be hardcoded and why a key doesn’t already exists with the default value in it? Rationals? Anyway, the path to the registry is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters

and you have to create a dword key here called NegativeCacheTime, and set its value to whateveer you want. 0 in case you want to disable this feature. Remember that the values is in second.
If you want to deploy this change, the quickest (and easiest) method I found was to create a registry file delete_dnscache.reg like this:


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]
"NegativeCacheTime"=dword:0

(remember to change the final :0 with the seconds of cache you want.

and then create a simple batch (.bat) file to put in the Group Policy machine’s startup scripts with something like this:

regedit /s \\YOURSERVER\netlogon\delete_dnscache.reg

Then, give a gpupdate /force on your DC, reboot a WinXP machine and check its registry for the new parameter.

Active Directory authentication with Ubuntu

DISCLAIMER: This entry is almost an integral copy of this post on the Ubuntu Forums, so let’s give the credit where is due and I give a huge THANKS to tfiedler. Now, why am I doing this? The reason is simple: I’m using this blog as a scratchbook/memo/notepad so if one day I’m going to need again this howto, I will know for sure where to find it easily. Moreover I will cover more in depth a couple of points so… let’s go!

1. Install the required packages with all their dependencies:
   apt-get install krb5-user
apt-get install winbind samba
   Note: you have to enable the Universe repository in your Ubuntu configuration (edit your /etc/apt/sources.list) or you will not find krb5-user

Quasi-high-availability for Windows 2003 Active Directory/DNS

If you have a single AD domain controller that it’s going to be SPOF (single point of failure) for your infrastructure, you can easily add another DC to the domain and create a secondary DNS in case of failure.

DISCLAIMER: this little how to is for little/medium organizations with a simple Windows infrastructure and with a low budget (it’s plenty of more expensive tools that do a better job). Follow it at your own risk, you have been warned!!

Assuming you’ve already up&running your first DC, follow this steps to enhance yur configuration:

• Install a second copy of Windows 2003 Server on another machine (a virtual machine could be perfect for this purpose)
• Install the second domain controller following these instructions from TechNet
• Install the secondary DNS in the new machine like Microsoft tells you to do
  
• Create the same DHCP configuration in the second server as the one you have in the first Domain Controller, just let it inactive
• Configure all your clients’ DNS to point to the primary and the secondary ones
• Now, in the primary DNS, create a round robin entry pointing to the two IP’s of the two domain controllers. To do this, simply create to A entries with the same name (in the same domain, obviously), pointing to two different IP’s
• Configure all your thid-party software authenticating against Actide Directory to point to this new entry

So…? What’s happening now?

Ok, your configuration is almost finished. Now, every user validating against the AD will use both domain controllers, in round robin strategy, and both will saty perfectly synchronized all the time (AD forest and DNS as well).

And in case of disaster??

If one of the two DC fails, remember we are in a quasi-HA environment, so we have to act manually to restore a 100% working system. But all we have to do is to delete, in the working DNS, the A entry of the died DC, disabling this way the round robin trick we did, so everything will authenticate against the surviving DC.