Problems adding XenServer to a domain and specifying the OU

I recently encountered a bizarre XenServer issue which I though I’d share as it will save you some time if you encounter the same. I was surprised there was no information already available about it, and Googling the error (which is generally a good first step) only showed up one very old forum thread for XenServer.
Updated 19/01/15 with details of the FQDN hostname issue affecting domain joins

Objective: To lock down XenCenter and XAPI user authentication to authorised users based on exsting Active Directory groups.

As you might know, XenServer supports native AD integration for management user authentication by adding the host to the domain. To achieve this, XenServer uses code from BeyondTrust called Likewise (since renamed PowerBroker) which gets called via the relevant XE commands or equivalent XAPI via XenCenter actions.

Like the majority of AD users, the client (being a large enterprise) makes extensive use of Organisation Units (OUs). The standard approach to adding computers to the domain was to pre-create the computer account in the correct OU using a build account, then join the computer to the domain.

The user account that was being used to add computer accounts  had no rights to the top level “Computers” OU which computer objects get placed by default, however I did not think this would be an issue as I planned to follow the existing process of pre-creating the computer accounts for the XenServer hosts, then run the XE command to join the host to the domain using the same credentails.

However, upon following this procedure, the XenServer host refused to join the domain, regardless of whether the computer account existed or not, giving the error message:

[sourcecode language=”plain”]# xe pool-enable-external-auth auth-type=AD service-name=mydomainname.com config:user=BuildAccount config:pass=Buildpass
The pool failed to enable external authentication.
host: c3258eff-76f1-4af3-88a7-b1528d20a74c (mydomainname.com)
message: 1816 (0x718) ERROR_NOT_ENOUGH_QUOTA – Unknown error[/sourcecode]

Taking a look at /var/log/xensource.log we see the same error with a bit more detail on the command line being used:

[sourcecode language=”plain”]Jan  7 23:00:18 xapi: [debug|myhostname.net|1087 UNIX /var/xapi/xapi|host.enable_external_auth D:2678fd616cba|extauth_plugin_ADlikewise] Likewise raised an error for cmd /usr/bin/domainjoin-cli "–minimal" "join" "–ignore-pam" "–ignore-ssh" "–notimesync" "mydomain.com" "BuildAccountName" : (524359) 1816 (0x718) ERROR_NOT_ENOUGH_QUOTA – Unknown error[/sourcecode]

My gut feeling was that the Likewise client was still trying to create the computer account in the default “Computers” OU which the Build account had no rights to. But I had created the computer account already, so what was going on?

The problem was actually three issues compounded:

1. XenServer had been installed with a FQDN as the hostname. Whilst this is valid in the Linux world, it causes problems in XenServer when servers are joined to AD.
2. Because of #1, XenServer didn’t use the short hostname as returned by “hostname” as the computer account name when creating the computer account, and thus wasn’t using the computer account I had pre-created, but was trying to create a new one in the default “Computers” OU 
3. The parameter to allow the OU to be specified as part of the XE command is undocumented

The computer account I had pre-created was not being used by XenServer at all which was trying to create a different computer account with a different hostname in the root “Computers” OU. I proved this by manually executing the Likewise code, and adding the correct OU (which XE didn’t appear to allow me to do)

[sourcecode language=”plain”]# /opt/likewise/bin/domainjoin-cli join –ou "OU=Servers,OU=XENAPP,OU=Citrix,OU=Lab,DC=dev,DC=mydomain,DC=com" dev.mydomain.com BuildAccount[/sourcecode]

This command executed without issue, which is when I noticed that the computer account that appeared in AD was different to the hostname of my server (which turned out to be a known bug issue as documented in CTX128918)

After a chat with a Citrix TRM, it transpires that it is possible to specify the OU via the XE command using an undocumented parameter:

[sourcecode language=”plain”]# xe pool-enable-external-auth auth-type=AD service-name=myhostname.com config:user=BuildAccount config:pass=Buildpass config:ou="OU=Servers,OU=XENAPP,OU=Citrix,OU=Lab,DC=dev,DC=mydomain,DC=com"[/sourcecode]

Problem now sorted, but be aware that the domain-joining process for XenServer isn’t as straightforward as one might think when needing to specify the OU!