A while back I wrote an article on remote authorization via tacacs+.  I got a question in the comments yesterday about the same functionality with active directory.  I hadn’t done anything with active directory outside of APM, so I wasn’t sure I could help. However, after reading up on a few solutions on askF5 (10929 and 11072 specifically), I gave it a shot and turns out it’s not so difficult at all.  For more details on the roles themselves, reference the tacacs+ article.  This tech tip will focus solely on defining the administrator and guest roles in the remoterole configuration on BIG-IP and setting up the active directory attributes.

Mapping AD Attributes

The attribute in the remoterole for active directory will look like this:

memberOF=cn=<common name>, ou=<organizational unit>,dc=x,dc=y

Let's break down the attribute string:

  • The cn can be a single account, or a group.  For example, jason.rahm (single account) or grp-Admins (security group)  In the string, they’re represented as such:
    • memberOF=cn=jason.rahm
    • memberOF=cn=grp-Admins
  • The ou is the organization unit where the cn is defined.  It can be deeper than one level (So if the OU organization was IT->Ops and IT->Eng, the ou part of the string would like this:
    • ou=Ops,ou=IT
    • ou=Eng,ou=IT
  • The dc is the domain component.  So for a domain like devcentral.test, the dc looks like this
    • dc=devcentral,dc=test

Putting the examples all together, one attribute would look like this:

memberOF=cn=grp-Admins,ou=Ops,ou=IT,dc=devcentral,dc=test

Defining the Remote Role Configuration

In tmsh, the remote-role configuration is under the auth module.  The configuration options available to a specific role (defined under role-info) are shown below

(tmos.auth.remote-role)# modify role-info add { F5Guest { ?
Properties:
  "}"             Close the left brace
  attribute       Specifies the name of the group of remotely-authenticated users for whom you are configuring specific access rights to the BIG-IP system.
                  This value is required.
  console         Enables or disables console access for the specified group of remotely authenticated users. You may specify bpsh, disabled, tmsh or use
                  variable substitution as describe in the help page. The default value is disabled.
  deny            Enables or disables remote access for the specified group of remotely authenticated users. The default value is disable.
  line-order      Specifies the order of the line in the file, /config/bigip/auth/remoterole. The LDAP and Active Directory servers read this file line by
                  line. The order of the information is important; therefore, F5 recommends that you set the first line at 1000. This allows you, in the
                  future, to insert lines before the first line. This value is required.
  role            Specifies the role that you want to grant to the specified group of remotely authenticated users. The default value is no-access. The
                  available roles and the corresponding number that you use to specify the role are: admin (0), resource-admin (20), user-manager (40),
                  manager (100), application-editor (300), operator (400), guest (700), policy-editor (800) and no-access (900).
  user-partition  Specifies the user partition to which you are assigning access to the specified group of remotely authenticated users. The default value
                  is Common.

With that syntax information and the AD attribute strings, I can define both roles:

tmsh modify auth remote-role role-info add { F5Admins { attribute memberOF=cn=grp-F5Admins,ou=Groups,dc=devcentral,dc=test console enable line-order 1 role administrator user-partition all } }

tmsh modify auth remote-role role-info add { F5Guests { attribute memberOF=cn=grp-F5Staff,ou=Groups,dc=devcentral,dc=test console disabled line-order 2 role guest user-partition all } }

Next I confirm the settings took.

tmsh show running-config /auth remote-role

auth remote-role {
    role-info {
        F5Admins {
            attribute memberOF=cn=grp-F5Admins,ou=Groups,dc=devcentral,dc=test
            console enable
            line-order 1
            role administrator
            user-partition all
        }
        F5Guests {
            attribute memberOF=cn=grp-F5Staff,ou=Groups,dc=devcentral,dc=test
            console disabled
            line-order 2
            role guest
            user-partition all
        }
    }
}

Configure the BIG-IP to Use Active Directory

Here I set the BIG-IP to use ldap authentication, defining my base-dn and the login attribute (samaccountname) and the user template (%s@devcentral.test).

tmsh modify auth ldap system-auth login-attribute samaccountname search-base-dn dc=devcentral,dc=test servers add { 192.168.202.110 } user-template %s@devcentral.test

And once again confirming the settings:

tmsh show running-config /auth ldap system-auth

auth ldap system-auth {
    login-attribute samaccountname
    search-base-dn dc=devcentral,dc=test
    servers { 192.168.202.110 }
    user-template %s@devcentral.test
}

Testing the Configuration

For the test there are two users.  test.user belongs the grp-F5Staff cn, and jason.rahm belongs to the grp-F5Admins cn.  Therefore, test.user should have Guest access to the GUI and no access to the console, whereas jason.rahm should have Administrator access to the GUI and console access.  Let’s see if that’s the case.

 

 

 

 

 

 

Conclusion

In this tech tip I walked through the steps required to configure remote authorization utilizing the BIG-IP remoterole configuration and Active Directory.  I didn’t cover the custom attributes like the in tacacs+ article, but the same process applies, so if you’d rather define the roles within Active Directory that can be done as well.

Comments on this Article
Comment made 28-Apr-2011 by hoolio 2420
That's a really thorough and easy to follow guide for remote admin auth. Thanks for yet another great article Jason.

Aaron
0
Comment made 06-May-2011 by naladar 10
Two thumbs up! Thanks for putting this together man!
0
Comment made 10-May-2011 by Wintrode 0
Jason,
Have you tried using an SRV record as the AD Auth server?
I'm going to plug that in and see what happens. I'm curious how the F5 will handle the return from the lookup.

I'll post my findings shortly.
0
Comment made 10-May-2011 by Wintrode 0
Ok, it does NOT like the service record method (_ldap._tcp.dc._msdcs.yourdomain.com), either through ldapsearch or the F5 gui.
Time to come up with another redundancy method. I'm just going to create a name on the GTM that will LB to both data centers.
0
Comment made 09-Jul-2012 by Jim 0
What ports does this use? Are there any other resources that need to be allowed for this to work in a DMZ setup?
0
Comment made 09-Jul-2012 by Jason Rahm
tcp port 49
0
Comment made 09-Jul-2012 by Wintrode 0
Jason,
Doesn't it depend on how you have defined it in the authentication configuration? I know we use TCP 3269 (MSFT GC SSL) for our implementation.
0
Comment made 09-Jul-2012 by Jason Rahm
sorry, I was thinking tacacs, not ldap. yes, it depends on implementation.
0
Comment made 27-Oct-2014 by David 0
So I've followed this article to a T, with the exception that instead of using a user template I've defined a specific bind. I know the ldap request is successful because if I set the External Users role to Guest under the Users:Authentication tab, I get guest access as desired. However, I cannot seem to make the remote role groups work. To give you my scenario - I need a group for ReadOnly (guest role) and a group for ASM Administrators for our IS Security Team. Any help is greatly appreciated.
0