[Solved] AD Auth for Admin Users in Admin Groups : When "Admin has no enabled groups" is not true. [ Edited ]

[#1]

tl;dr

Username in AD > 20 characters. Login fails with "Invalid login."

Edit: You can also get this error if you fail to put the InfoBlox group into the list in the:

   Administration | Administrators | Authentication Policy | "Map the remote admin group to the local group in this order" List

Edit: Title changed from ...is a Lie, to ...not True.
For those aggrieved.

Audit log shows:
2019-06-10 12:01:00 BST mytwentyonecharusrnme LOGIN_DENIED to=AdminConnector ip=10.11.12.13 info=Admin has no enabled groups apparently_via=GUI:

Long story is that a user account created with a name more than 20 characters long, in AD, has its sAMAccountName LDAP field truncated to the first twenty characters. The InfoBlox appliance will make an LDAP Bind with the username fine, but when it looks up group membership, it takes the username as a Filter on, you guessed it, sAMAccountName, so you get Zero Results for groups this user is a member of, because there is no user with sAMAccountName=mytwentyonecharusrnme

The user you want to lookup groups for has the unfortunately truncated sAMAccountName=mytwentyonecharusrnm

InfoBlox lies, because it doesn't know any better. Don't suppose you could update this LDAP filter to use the 'name' field, or maybe the prefix to @ on the 'userPrincipalName'
e.g.
userPrincipalName=mytwentyonecharusrnme@doh.mydomain.com

This took me packet captures, Wireshark merges of pcap files and Apache Directory Studio to solve. Also a whole working day. Hope I can save someone else the hassle

[#2]

I cannot imagine requiring a user to enter a more than 20-character username every time they need to access some system.  I'd suggest shortening the user's username.

Submit this as a bug to support as I imagine it may not be an issue that occurs that often and Infoblox may not have been asked to look into this issue.

I'm not sure why you say they lie.  You're just running into a technical issue.  To say someone lies usually means they intended to mislead you. 

[#3]

> I cannot imagine requiring a user to enter a more than 20-character username every time they need to

> access some system.  I'd suggest shortening the user's username.

I think that's quite presumptious. I have worked with many customers, some of which have had quite arcane/extreme security policies. You cannot predict what daft policy a security department is going to dream up next, if that means 20+ character user names, and if the underlying authentication service supports it, then the product needs to be able to support this.

I agree, get it logged as a bug, but if Infoblox product management take the same attitude then be prepared for a long wait!

[#4]

Thank you for being understanding and supportive paulr.

The reason we would like to have long usernames is because this account, and others like it, are service accounts used by automation systems. We like to have a username that describes the purpose of the account. In large scale estabishments with a lot of interconnected systems, documentation can be sparse. It is wise to make the purpose of something as obvious as possible.

I am back again at this behaviour with an additional account, this time however, it appears the username is within length, yet I still get the same login failure message. I'm off to do more packet capture to get to the bottom of this one.

Edit: Solved: Forgot to add InfoBlox group to the: Administration | Administrators | Authentication Policy | "Map the remote admin group to the local group in this order" List
  derp.