ISE, Active Directory and Hostname Limitation

[xxkozxx]

FYI. I opened a TAC case on this, but thought I'd also post here in case someone has come across this:

I realize that in the end, I will likely have to just rename my hosts. I am, however curious about this because the character limitation impedes the ability to adhere to device naming conventions that an organization may have. 

Hostnames Longer than 15 characters

I am in the process of installing and migrating to 3595’s. During the installation I mistakenly named the devices with a host name longer than 15 characters (oversight on my part). Now, due to the 15-character hostname limitation, I cannot join them to active directory (see error log below). The actual access denied message that I received was not because my account didn't have permission. It was because AD saw it as an invalid object. I tested AD Users and Computers with the account in question and was able to create accounts just fine.

At any rate, I had a couple of thoughts about a workaround for this but am unclear as to whether it is supported and what the effects may be. Curious to know if anyone else has tried this.

Prestage Computer Object in AD with a Pre-2000 Account Name

I tested this by creating a pre-windows 2000 name in Active Directory. This is a field that is available in the menu when creating and object using Active Directory Users and Computers. It still failed, but I noticed in the error log (see below) that it appears to randomize a name for the SAM Account name. I assume that ISE does this if the host name is too long so that it will avoid creating and AD object that is too long and ensure that if each host name starts the same, as is traditional with device naming conventions, that the AD SAM Account name object would be unique. 

1. What is the random name that it is generating and what is the mechanism through which it is generating that name?

2. Can I take that randomly generated samName and populate that in a staged AD Computer account that has its object name reflected as the true hostname and the pre-windows 2000 accout name be the randomly generated account name as seen below in the logs. EDIT: I have tested this and you can take that sAmAccountName from below and set it as the pre-windows 2000 Account name when prestaging. It allows a successful join to Active Directory.

3. If that is possible, are there any ramifications, from an ISE perspective, in terms of User or Machine auth?

4. The log below says it found the random name below (XXX-XXX-6EL5K0B$). However, no AD object with that name actually exists. The log is a bit ambiguous as to where it actually found that object. Is this a reference to a created object in the ISE database from the first join attempt that failed?

ERROR LOG
Error Description: Access is denied

Support Details...
Error Name: ERROR_ACCESS_DENIED
Error Code: 5

Detailed Log:

Error Description :
Cannot create machine account (empty) : access denied.

Error Resolution :
Please check for sufficient permissions to create machine account object

Join steps :
06:56:40 Joining to domain mydomain.com using user iseuser
06:56:40 Searching for DC in domain mydomain.com
06:56:40 Found DC: dc.mydomain.com , client site is myDataCenter , dc site is myDataCenter
06:56:40 Checking credentials for user iseuser
06:56:40 Getting TGT for account iseuser@mydomain.com 
06:56:40 TGT for account iseuser@mydomain.com was retrieved successfully
06:56:40 Credentials for user iseuser were verified
06:56:40 Searching for DC in domain mydomain.com
06:56:40 Found DC: dc.mydomain.com , client site is myDataCenter , dc site is myDataCenter
06:56:40 Generating account name for ISE machine in mydomain.com
06:56:40 Searching for an existing machine account
06:56:40 Searching object by filter : (&(objectCategory=computer)(servicePrincipalName=host/XXX-XXX-ise-adm1.mydomain.com))
06:56:40 Account: XXX-XXX-ise-adm1 was not found
06:56:40 Searching for an existing machine account
06:56:40 Searching object by filter : (&(objectClass=computer)(sAMAccountName=XXX-XXX-6EL5K0B$))
06:56:40 Account: XXX-XXX-6EL5K0B$ was found
06:56:40 ISE Machine account name is : XXX-XXX-6EL5K0B$
06:56:40 Creating machine account XXX-XXX-6EL5K0B$
06:56:40 Connecting to AD using DC dc.mydomain.com 
06:56:40 Connection to dc.mydomain.com established
06:56:40 Opening domain MYDOMAIN 
06:56:40 Domain MYDOMAIN was opened successfully
06:56:40 Creating machine account object XXX-XXX-6EL5K0B$
06:56:40 Cannot create machine account (empty) : access denied.

[Colby LeMaire · Accepted solution]

The limitation is because of NetBIOS.  I would hope that future versions of Active Directory start to disable NetBIOS by default and remove this limitation.  But we are stuck with what we have for now.  I am not sure how ISE is randomizing the hostname when it is over 15 characters.  The underlying software within ISE that handles the AD communication is called Centrify.  I checked Centrify documentation and didn't find anything about it randomizing hostnames.  So it must be ISE doing that before calling the Centrify functions/commands.

As far as trying to work around it using the pre-2000 name, that would be fine since directory lookups rely on the samAccountName attribute.  So make sure the pre-2000 name you enter shows up in the attribute the same way.  Of course there will be a "$" added to the end.  I wouldn't expect any issues with user or computer authentication and you could test that just to make sure.

However, the best option you have to work around this limitation is to use LDAP instead of AD.  Just configure your AD domain controllers as LDAP servers and adjust your policies as necessary.  I would rather do that than take a chance on name mismatches.

Downside of LDAP over AD as an external identity source is that you are limited to a primary and secondary server with LDAP.  Whereas AD uses DNS and Sites & Services to locate the closest domain controller to handle requests.  LDAP can also be a little more difficult to setup initially if you aren't familiar with the LDAP structure and distinguished names.  Other than that, it can do what AD can without having to join your ISE nodes to it.

[xxkozxx]

Colby,
Thanks for the reply. I hadn't thought of LDAP as an alternative but it makes sense. As a side note, one way to mitigate the lack of sites and services limitation out of this would be to topology load balance LDAP against the regional controllers you wished to have handling that. That might level the playing field a bit.

I'll keep you posted on what TAC comes back with.

[Arne Bier]

Hi @Colby LeMaire 

That's a cool summary of why things are the way they are.

I just need to caution here that LDAP is not 100% equivalent to an AD join because for authentication methods that involve passwords, since there are complications/limitations when using the LDAP method.  LDAP does not handle challenged handshake password exchanges. e.g. you cannot do EAP-PEAP against an LDAP directory/AD.

[xxkozxx]

Arne,

Thanks for the information and the chart. I do find the use of LDAP interesting but you are correct in that it would limit my ability to support other authentication methods. 

I currently use EAP-TLS / PEAP / MSCHAP for our environment and thus need that capability. I am planning on adding the devices to AD as per the "work around" I noted above and doing some testing.