I run FreeRADIUS Version 2.0.5, for host i686-pc-linux-gnu and testing FreeRADIUS Version 2.1.3 both on gentoo systems, I want to peap authenticate, authorize and set VLANs on a Cisco Cat 4500 according to a ldap Attribute. * What does work already: I can authenticate peap using certificates from an XP machine store as well as from the user store. Adding the machine and user to users file DEFAULT Auth-Type := EAP, User-Password == "" Service-Type = Shell-User, Fall-Through = Yes, Tunnel-Type = 13, Tunnel-Medium-Type = 6 # Tunnel-Private-Group-Id = 101 user@domain Auth-Type := EAP, User-Password == "" Service-Type = Shell-User, Fall-Through = Yes, Tunnel-Type = 13, Tunnel-Medium-Type = 6, Tunnel-Private-Group-Id = 101 sets the VLAN correctly on the Cisco; removing user uses DEFAULT and works as well when the Tunnel-Private-Group-Id is enabled. * What does not work: removing the users entry and setting up ldpa: sites-enabled/MySite authorize { preprocess mschap eap { ok = return } files Autz-Type LDAP1 { ldap_client1 } ldap_client1 expiration logintime pap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } digest pam unix Auth-Type LDAP1{ ldap_client1 } eap } modules/ldap ldap ldap_client1 { server = "ldapserver" identity = "cn=ldapuser,ou=users,...." password = "password" basedn = "dc=ad,..." dictionary_mapping = ${raddbdir}/ldap.attrmap filter = "(userPrincipalName=%{Stripped-User-Name:-%{User-Name}})" ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 ldap_debug = 0xFFFF } ldap.attrmap checkItem Tunnel-Private-Group-Id comment My VLAN is in the comment Attribute: ldapsearch -h ldaserver -b "dc=casedn" -D "ldapuser@ldaserver" -w "password" -x '(userPrincipalName=user@domain)' comment --> .... comment: 101 Major problem in the debug: new result: res_errno: 1, res_error: <000004DC: LdapErr: DSID-0C0906DD, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1772>, res_matched: <> read1msg: ld 0x81c1068 0 new referrals In tcpdump from ldapsearch there is one bind + one searchRequest In tcpdump from radiusd there is one bind + one searchRequest with searchResDone ... vals 101 - This is perfect. But right thereafter is an anonymous bind which uses the searchResRef and issues the same query again and fails, as it is not allowed for anonymous bind. Is there any idea how to resolve this or how to use ldap differently. Thanks Joerg