Problem returning attributes to Bluesocket
Hi, I am trying to set a wireless network where a client will use a Bluesocket gateway in conjunction with Freeradius to perform authentication. I want the radius server to authenticate a user in LDAP and return certain attributes to the Bluesocket gateway so that the gateway can place the user in a role based on those attributes. A sniffer trace of the attempted authentication reveals that the Freeradius does request the attributes that I am interested in (x121address and edupersonprimaryaffiliation) and does receive the values back from LDAP. My problem is that these values are not then passed on to the Bluesocket gateway. What am I missing? Output from debug mode follows: rad_recv: Access-Request packet from host A.B.C.D:32801, id=140, length=145 User-Name = "someuser" User-Password = "somepwd" NAS-IP-Address = A.B.C.D Service-Type = Login-User Framed-IP-Address = W.X.Y.Z Called-Station-Id = "00:90:0B:02:DF:24" Calling-Station-Id = "" NAS-Identifier = "wg1.wireless.uab.edu" Acct-Session-Id = "00:90:0B:02:DF:24:1140706217" NAS-Port-Type = Wireless-802.11 rlm_ldap: - authorize rlm_ldap: performing user authorization for someuser rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: (re)connect to myldap.com:389, authentication 0 rlm_ldap: bind as / to myldap.com:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: looking for check items in directory... rlm_ldap: Adding edupersonprimaryaffiliation as edupersonprimaryaffiliation, value staff & op=21 rlm_ldap: Adding x121address as radiusx121address, value wifi & op=21 rlm_ldap: looking for reply items in directory... rlm_ldap: user someuser authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: - authenticate rlm_ldap: login attempt by "someuser" with password "somepwd" rlm_ldap: user DN: uid=someuser, ou=people, dc=uab, dc=edu rlm_ldap: (re)connect to myldap.com:389, authentication 1 rlm_ldap: bind as uid=someuser, ou=people, dc=uab, dc=edu/somepwd to ldap.com:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: user someuser authenticated succesfully Sending Access-Accept of id 140 to A.B.C.D:32801 Portion of ldap.attrmap follows: checkItem radiusx121address x121address checkItem edupersonprimaryaffiliation edupersonprimaryaffiliation replyItem x121address radiusx121address LDAP portion of radiusd.conf follows: ldap { server = myldap.com # identity = "cn=admin,o=My Org,c=UA" # password = mypass basedn = dc=uab,dc=edu filter = "(uid=%u)" # base_filter = "(objectclass=radiusprofile)" # set this to 'yes' to use TLS encrypted connections # to the LDAP database by using the StartTLS extended # operation. # The StartTLS operation is supposed to be used with normal # ldap connections instead of using ldaps (port 689) connections start_tls = no # tls_cacertfile = /path/to/cacert.pem # tls_cacertdir = /path/to/ca/dir/ # tls_certfile = /path/to/radius.crt # tls_keyfile = /path/to/radius.key # tls_randfile = /path/to/rnd # tls_require_cert = "demand" # default_profile = "cn=radprofile,ou=dialup,o=My Org,c=UA" # profile_attribute = "radiusProfileDn" # Mapping of RADIUS dictionary attributes to LDAP # directory attributes. dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 5 # # NOTICE: The password_header directive is NOT case insensitive # # password_header = "{clear}" # # The server can usually figure this out on its own, and pull # the correct User-Password or NT-Password from the database. # # Note that NT-Passwords MUST be stored as a 32-digit hex # string, and MUST start off with "0x", such as: # # 0x000102030405060708090a0b0c0d0e0f # # Without the leading "0x", NT-Passwords will not work. # This goes for NT-Passwords stored in SQL, too. # # password_attribute = userPassword # groupname_attribute = cn # groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=Gr oupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))" # groupmembership_attribute = radiusGroupName timeout = 4 timelimit = 3 net_timeout = 1 # compare_check_items = yes # do_xlat = yes # access_attr_used_for_allow = yes } Thanks, dwolford
"David L Wolford" <dwolford@uab.edu> wrote:
A sniffer trace of the attempted authentication reveals that the Freeradius does request the attributes that I am interested in (x121address and edupersonprimaryaffiliation) and does receive the values back from LDAP. My problem is that these values are not then passed on to the Bluesocket gateway. What am I missing?
Those attributes are defined in LDAP, but not in RADIUS. Therefore, they can't go into a RADIUS packet.
Portion of ldap.attrmap follows:
checkItem radiusx121address x121address checkItem edupersonprimaryaffiliation edupersonprimaryaffiliation
The last column should be RADIUS attributes, as defined in a dictionary file. If you didn't define those attributes in a dictionary, then they will never go into a packet. In addition, if the Bluesocket gateway doesn't mention those attributes in it's documentation, then it won't understand them in a RADIUS packet. Please read the bluesocket docs to see what RADIUS attributes it understands. Then, see if those attributes are in the FreeRADIUS dictionaries. If they're not, add them. Then, make FreeRADIUS send those attributes. See "man dictionary" for additional details. Alan DeKok.
participants (2)
-
Alan DeKok -
David L Wolford