Having issues interpreting ldap search/filter attributes

[Alan DeKok]

On Aug 17, 2020, at 9:55 PM, Steve Phillips <steve at focb.co.nz> wrote:
> Firstly, can I say thanks for the previous mail, it helped quite a bit when it came to understanding how to check the rlm_ldap 'search' parameter against ldapsearch to see what comes back. I've since noticed some interesting things.

  OK.

> Firstly, nested groups, I can say we are not searching for nested groups, the group being searched against (Lets call it "ACCESS_2FA") is happily returning the user object when a search is done using ldapsearch on this group.

  That's good.

> I think I have found the issue though but I am unsure on how to fix it.
> 
> When I perform the initial bind, I am doing this as a user supplied in the user-name radius attribute, and this is then converted to "username at domain" as an LDAP-UserDN using the 'sites-enabled' section as follows
> 
> authorize {
>        auth_log
>        if (&User-Password) {
>                # If !State and User-Password (PAP) then force LDAP
>                update control {
>                        Ldap-UserDN := "%{User-Name}@example.com"
>                        Auth-Type := LDAP
>                }
>        }
> }

  OK... 

> From here, authentication happens
> 
> authenticate {
>        Auth-Type LDAP {
>                # Attempt to authenticate with a direct bind
>                ldap
>        }
> }
> 
> And this seems to succeed. (I was using files for authorization to perform the LDAP-Group match but changed to post-auth)

  That's good.

> post-auth {
>        update {
>                &reply: += &session-state:
>        }
>        if (LDAP-Group == "ACCESS_2FA") {
>                update reply {
>                        Reply-Message = "OMG, it worked"
>                }
>        }
> }
> 
> No problem, and now I can see it is trying to check that the LDAP-Group matches for the LDAP-UserDN username OR username at example.com
> 
> (From the modules-enabled/ldap) 
> 
> group {
>   membership_filter = "(|(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}}))"
> }
> 
> Which seems to fail, as the group match is looking for CN=<fullname>,OU=Users,DC=example,DC=com. I can verify this by changing the membership_filter to

  I'm not sure what you mean by <fullname>.  Which field is it actually using?

> membership_filter = '(|(member=CN=Steve Phillips,OU=Users,DC=example, 
> DC=com)(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))'
> 
> And this actually works (though is obviously not practical as no one logs in with their 'full name')
> 
> No problem, we are getting somewhere, I had read that we can also perform a lookup on the user object rather than the group object (filter = '(objectclass=user)') as this way I can match the account name using the sAMAccountName and then perform a match on memberOf object using the full "CN=<group>
> 
> Checking with ldapsearch, I worked out that the search (&(objectclass=user)(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})) 
> 
> Returns the user object, but when I try to implement this in the ldap module it seems to want to turn the search into..
> 
> Debug: (0)     Searching for user in group "ACCESS_2FA"
> ...
> Debug: (0)       EXPAND (&(cn=ACCESS_2FA)(objectclass=user)(|(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})))
> Debug: (0)          --> (&(cn=ACCESS_2FA)(objectclass=user)(|(sAMAccountName=user001)))
> 
> And the check fails again.

  What user identifier should be used for the ldap search?

> My ldap module is as follows
> 
> ldap {
>        server = '10.0.0.50'
>        basedn = "dc=example,dc=com"
>        identity = 'CN=Steve Phillips,OU=Users,DC=example,DC=com'
>        password = MyPassword

  That should be a "read-only" LDAP admin account.  It should generally NOT be the account of a particular user.

> Am I missing a directive to say 'please lookup the user objectClass not the group objectClass' to get it to lookup the group in the user object rather than the user in the group object? - I couldn’t see anything in the rlm_ldap comments.

  The LDAP schema should be normal.  Why does it have to look up something in a different place?

  Alan DeKok.