Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology

LTM V12 upgrade test run, lost Active DIrectory auth

Upgraded from Virtual Edition 11.6.0 Build 6.119.442 Engineering Hotfix HF6 to BIG-IP 12.0.0 Build 2.0.644 Hotfix HF2.

We've just performed an LTM upgrade from v11 to v12, I'm on UAT duty. I note I can only login as "admin", AD authentication fails with no clues in any logs I can find. Under Audit I see these messages, nothing following that...

Wed Apr 20 10:22:35 CST 2016    root    0-0 pam_ldap initiating connection to non-SSL ldap server domain-controller.myorg.com on port 389.:
Wed Apr 20 10:22:35 CST 2016    root    0-0 pam_ldap validating credentials for user 'my-username' against non-SSL ldap server domain-controller.myorg.com on port 389.:
Wed Apr 20 10:22:35 CST 2016    root    0-0 pam_ldap terminating connection to non-SSL ldap server domain-controller.myorg.com on port 389.:

I also note that I can't login using Firefox 45.0.1, I had to use Chrome to avoid a 401 page with this message...

"This server could not verify that you are authorized to access the URL "/tmui/logmein.html". You either supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required. In case you are allowed to request the document, please check your user-id and password and try again. "

Here's what list /auth looks like. I thought the two servers might be the problem as that's not possible to enter via the GUI, but I get the same issue specifying just one...

auth ldap system-auth {
    bind-dn "BIND_USER_DN"
    bind-pw SOMETHING
    check-roles-group enabled
    login-attribute samaccountname
    search-base-dn DC=myorg,DC=com
    servers { dc1.myorg.com dc2.myorg.com }
    user-template %s@myorg.com
auth password-policy { }
auth remote-role {
    role-info {
        F5-Admins {
            attribute "memberOF=ADMIN_GROUP_DN>"
            console tmsh
            line-order 1000
            role administrator
            user-partition All
        F5-Guests {
            attribute "memberOF=GUEST_GROUP_DN"
            console tmsh
            line-order 1100
            role guest
            user-partition All
        F5-iRulers {
            attribute "memberOF=IRULER_GROUP_DN"
            line-order 1050
            role irulemanager
            user-partition All
auth remote-user { }
auth source {
    type active-directory
auth user admin {
    description "Admin User"
    encrypted-password SOMETHING
    partition Common
    partition-access {
        all-partitions {
            role admin
    shell none
Rate this Discussion
Comments on this Discussion
Comment made 20-Apr-2016 by Josiah
Probably you want to packet capture the ldap traffic (and dns) and make sure it's behaving the way you expect. the DC may give some clues to as to why it's rejecting it. admin will always work because it's a local account and doesn't go to ldap. also you might try deleting and recreating your ldap remote auth config, or just the password.
Comment made 20-Apr-2016 by Seth
Hello Sam, Are you performing this upgrade on Hardware or a Virtual Edition? Knowing the platform/hypervisor may help in the diagnosis. Which version of 11.x are you using as the base for the upgrade? When upgrading from versions prior to 11.6 to 12.0, the root login and password is disabled for Virtual Editions. https://support.f5.com/kb/en-us/solutions/public/16000/100/sol16163.html?sr=53204327
Comment made 20-Apr-2016 by Sam Hall 383
Root and admin accounts work fine. Upgraded from Virtual Edition 11.6.0 Build 6.119.442 Engineering Hotfix HF6 to BIG-IP 12.0.0 Build 2.0.644 Hotfix HF2.
Comment made 10-Jan-2017 by Egor 0

Hi, I have exactly the same problem. Upgraded from 11.6.0HF5 to 12.1.1HF2 Did someone managed to resolve this issue? This is a VE deployment. Prior software upgrading, changed 2 CPU with 1 socket(2 in total) to 2 CPU with 2 Sockets (4 in total) and raised memory from 4GB to 16GB with reservation of 8GB in ESX.

Comment made 17-Jan-2017 by Sam Hall 383

Egor, see my answer below with the solution hyperlink. You have to replace any spaces in the Active Directory group names with "\20".

Comment made 18-Jan-2017 by Daniel AIG 1

Hi Sam, I've tried to replace the spaces with no luck... It seems that as soon I disabling the SSL everything works like a charm.

Any suggestions? Was working fine before upgrading to 12.1.1HF2 from 11.6.0HF6.

Comment made 18-Jan-2017 by Sam Hall 383

No idea sorry, your problem is a little different. If I were you I would raise a support request.


Replies to this Discussion


I raised a support request for this, and after some analysis the culprit was found to be bug ID 512130 "Remote role group authentication fails with a space in LDAP attribute group name".

See... https://support.f5.com/kb/en-us/solutions/public/k/54/sol54204296.html

This bug has been around for a while, not sure why it only impacted us on v12. The workaround listed in the solution above worked fine.


Got it working, not sure why yet but when I changed the AD server to an actual AD server and not an LTM load balanced virtual (on a different F5, not this same one) it suddenly let me in.

Update: Nope, it wasn't just the servers setting, I also changed the default Role setting via the GUI, and this seems to have gotten me in. Getting closer though, it must be a problem looking up group membership and assigning LTM permissions based on that.



I ran into this at the customer today and did not come up with any solution so I tried it in my lab and ran into the same problem: new VE with 12.0HF1 just deployed from the OVA. I configured AD authentication with remote role group matching. User gets authenticated but not matched to the group.

I took a look at the tcpdump: I see that the BIG-IP successfully authenticates my user, DC says success.

If I remove the remote role matching and set either the default role or configure a local user with the same name and assign a role I can successfully log in! Only the remote role matching does not work.

I can remember, when I tried to upgrade our own two VEs from 11.6.0 to 12.0 AD auth was broken... but I had to revert anyway...