Forum Discussion
Tom_Anderson_91
Nimbostratus
NimbostratusLDAP authentication with specific attribute
We have a situation where we need to do URL authentication based on the makeup of a URL. For example, a URL containing the string "a-" should be accessible to staff only, and a URL containing the string "b-" should be accessible to staff and students.
We have had this working for some time based on OU's in our LDAP - which has been fine, as any students who were also staff (and vice versa) had a separate account for the other login.
Recently we implemented a single signon - so now staff members who enrol as a student keep their existing staff login, but have an attribute added in LDAP to identify them as such.
We're able to authenticate the b- URLs correctly still with this method, as any valid account is permissible. It's the a- URLs that are causing trouble. We need to allow authentication to these URLs only to users in LDAP that contain a particular attribute. This attribute is called staff - and will have a value of 1 for any valid staff member.
I have tried to use staff=1 in the filter field on the LDAP configuration however it doesn't allow authentication at all with this set. I'm not even sure if this is the correct syntax, if this is the correct usage for this field or even if it's possible to do what I want, so any advice is well welcomed!
Thanks in advance,
Tom
hoolioCirrostratus
Hi Tom,
This has been asked a few times. One poster with a very similar scenario seems to have found a solution as noted in this post:
Irule for Ldap auth based on URL syntax
http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&tpage=1&view=topic&postid=58425
We needed to add a second auth profile, and have separate irules assigned to the auth profiles individually.
However, the details are light and the poster didn't reply to a few follow up questions.
Aaron
Tom_Anderson_91Aaron - this is one of my colleagues! That was posted back when we were trying to nut out how to differentiate the authentication based on the URL. We have that part working now (using iRules and two authentication profiles) and it has been reliable in production for us for some months.
What we need to do now is change the authentication profile side of it. Currently it looks at OU's to determine if people are staff or student. Now that we're using single signon it needs to look at a specific value on a specific attribute in LDAP to determine if they have staff and/or student level access.
Example - Joe Bloggs is a staff member. His LDAP profile contains the attribute 'staff=1'. He needs to be able to authenticate to URLs with a- and b-. On the other hand, Mary Jones is a student and has the attribute 'student=1' and 'staff=0' - she needs to authenticate to b- URLs but not a-. Making this part of it happen is what I'm struggling with.- Tom_Anderson_91I'll see what I can do about posting up the configs we used in the other thread, too.
- Tom_Anderson_91Bump. Is this possible?
- hoolioIt looks like v10.0.1 offers some fairly comprehensive config options for validating specific LDAP attributes, including a field named Role Key:
Specifies the name of the attribute in the LDAP database that specifies a user's authorization role.
Which LTM version are you running? Can you post an anonymized copy of your LDAP Auth config object definition?
Thanks,
Aaron - Tom_Anderson_91Hi Aaron.
We're running 9.4.6 presently.
I'm not sure how to get a straight out definition of the config so I've typed it out here. I've only mentioned the fields we actually have set.
Name: LDAP-Staff-New
Remote LDAP Tree: dc=domain,dc=com,dc=a
Hosts: 1.1.1.1
Service Port: 636
LDAP Version: 3
Search time limit: 30
Bind time limit: 30
Filter: staff=1
Check Host attribute: Enabled
SSL: Enabled
Check SSL Peer: Disabled
Warning Logging: Enabled
Debug Logging: Disabled
This prompts us for a username/password but authentication will never pass while the filter attribute is set.
Tom - hoolioHi Tom,
You can list the config using 'b profile auth ldap list' from the command line or in the GUI under System | Console.
Can you also enable warning and debug logging on the profile, retest and check /var/log/ltm for the output?
Thanks,
Aaron - hoolioI tried testing this today, but couldn't get the first auth profile working! Here is a copy of the test config:
auth ldap ad_ldap_auth_config {
debug enable
search base dn "CN=Users,DC=example,DC=net"
bind dn "CN=Administrator,CN=Users,DC=example,DC=net"
bind pw "my_account"
login attr "sAMAccountName"
check host attr enable
group dn "CN=bigip_users_1,CN=Users,DC=example,DC=net"
servers "1.1.1.1"
}
Looking at a tcpdump from the AD server, the initial bind works, but then LTM seems to try to rebind as the user and looks for an attributeDesc of uniquemember which doesn't exist and causes an LDAP error.
If you get a chance, could you post an anonymized copy of your auth profiles from the bigip.conf file?
Thanks,
Aaron - hoolioSo the fix for that problem was just setting a group attribute to "member" on the auth config:
auth ldap ad_ldap_auth_config {
debug enable
search base dn "CN=Users,DC=example,DC=net"
bind dn "CN=Administrator,CN=Users,DC=example,DC=net"
bind pw "my_account"
login attr "sAMAccountName"
check host attr enable
group dn "CN=bigip_users_1,CN=Users,DC=example,DC=net"
group member attr "member"
servers "1.1.1.1"
}
But I'm still not clear on how you're using two auth profiles and iRules on the same VIP. If you're still working on this, can you elaborate on your current auth profile config?
Thanks,
Aaron - Tom_Anderson_91We use some iRule magic to make the multiple authentication profiles happen. First off we specify both the authentication profiles in the VIP configuration. Each authentication profile is tied to an iRule which looks as follows (the AUTH start is different based on the auth profile used). As you'll see this ensures the iRule only executes with a matching URL. The other iRule (tied to the other auth profile) contains the /b- URL search.
Provides authentication for URLs containing a-. when HTTP_REQUEST { if {[HTTP::path] contains "/a-"} { set tmm_auth_ldap_sid [AUTH::start pam ldaps-staffonly] AUTH::username_credential $tmm_auth_ldap_sid [HTTP::username] AUTH::password_credential $tmm_auth_ldap_sid [HTTP::password] AUTH::authenticate $tmm_auth_ldap_sid HTTP::collect } } when AUTH_SUCCESS { if {$tmm_auth_ldap_sid eq [AUTH::last_event_session_id]} { HTTP::release } } when AUTH_FAILURE { if {$tmm_auth_ldap_sid eq [AUTH::last_event_session_id]} { HTTP::respond 401 } } when AUTH_WANTCREDENTIAL { if {$tmm_auth_ldap_sid eq [AUTH::last_event_session_id]} { HTTP::respond 401 } } when AUTH_ERROR { if {$tmm_auth_ldap_sid eq [AUTH::last_event_session_id]} { HTTP::respond 401 } }