Re: bug in rlm_ldap?

16 Dec 2005

      Dusty Doris wrote:
...
...
Did you get the second email I sent.  I don't believe you can use that 
check item from ldap in the users file.  Try the ldap-group options I 
sent over in the last email.  That should work for you.
Thank you, I got it and already tried that attribute. The behaviour is a 
bit better, but does not really lead to the desired result, as the 
client gets an:
Incoming RADIUS packet did not have correct Message-Authenticator - dropped

With a users file:
###############
DEFAULT Ldap-Group == "515", Auth-Type := Accept
        Framed-Type = Framed,
        Tunnel-Type:1 = VLAN,
        Tunnel-Medium-Type:1 = IEEE-802,
        Tunnel-Private-Group-ID:1 = 100

DEFAULT Auth-Type := Reject

an ldap module:
ldap ldap1 {
                server = "globalcatalogue"
                port = 3268     #global catalogue server
                identity = "testrad@TDE002.MYDOM.NET"
                password = "mypass"
                basedn = "dc=MYDOM,dc=NET"
                filter = 
"(&(servicePrincipalName=%{Stripped-User-Name:-%{User-Name}})(objectClass=computer)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"
                ldap_debug= 0xFFFF
                timeout = 40
                timelimit = 30
                net_timeout = 10
                tls {
                        start_tls = no
                }
                dictionary_mapping = ${raddbdir}/ldap.attrmap
                groupmembership_attribute = "primaryGroupID"
        }
a files section of:
files files1 {
                usersfile = ${confdir}/users
                acctusersfile = ${confdir}/acct_users
                preproxy_usersfile = ${confdir}/preproxy_users
                compat = no
        }

and an authorize section:
authorize {
        preprocess
        eap
        ldap1 {
                notfound = reject
                }
        files1 {
                notfound = reject
                }
}

radiusd -AX gives me:
....

....
rlm_ldap::ldap_groupcmp: User found in group 515
rlm_ldap: ldap_release_conn: Release Id: 0
    users: Matched entry DEFAULT at line 1
  modcall[authorize]: module "files1" returns ok for request 0
modcall: leaving group authorize (returns updated) for request 0
  rad_check_password:  Found Auth-Type Accept
  rad_check_password: Auth-Type = Accept, accepting the user
Sending Access-Accept of id 0 to 149.246.133.44 port 32770
        Tunnel-Type:1 = VLAN
        Tunnel-Medium-Type:1 = IEEE-802
        Tunnel-Private-Group-Id:1 = "100"
Finished request 0

Seems ok, but unfortunately on the other side, the result is not that 
good. Alan proposed eapol_test recently for testing of such 
connections(thank you, very usefull) and this tool shows me:
...
Received RADIUS message
RADIUS message: code=2 (Access-Accept) identifier=0 length=38
   Attribute 64 (?Unknown?) length=6
   Attribute 65 (?Unknown?) length=6
   Attribute 81 (?Unknown?) length=6
STA 00:00:00:00:00:02: Received RADIUS packet matched with a pending 
request, round trip time 0.15 sec
No Message-Authenticator attribute found
Incoming RADIUS packet did not have correct Message-Authenticator - dropped
STA 00:00:00:00:00:02: No RADIUS RX handler found (type=0 code=2 id=0) - 
dropping packet
EAPOL: startWhen --> 0
EAPOL test timed out
MPPE keys OK: 0  mismatch: 1
FAILURE

Any idea?

Re: bug in rlm_ldap?

Norbert Wegener