Hi, i'm using freeradius-1.1.2 with openldap for storing users account, for authenticate a WI-FI LAN. I need of a transparent authentication method since for the clients are heterogeneous so i can't use any type of EAP* authentication because I cannot install Xsupplicant on every Client. Can I use mschap authentication for this and there are some specific documentation ?,i've searched a lot but i haven't found exhaustive documentation. And if I cannot use mschap, are there others solution for wi-fi authentication via LDAP? Excuse my bad english. Giusy Venezia
Giuseppina Venezia wrote:
Hi, i'm using freeradius-1.1.2 with openldap for storing users account, for authenticate a WI-FI LAN. I need of a transparent authentication method since for the clients are heterogeneous so i can't use any type of EAP* authentication because I cannot install Xsupplicant on every Client.
If you mean 802.1x authentication, I don't think you understand how it works. All 802.1x (link layer) authentication methods use EAP, so all clients must have SOME kind of supplicant. Non-802.1x authentication is normally done via some kind of web-based login. Google for "captive portal" or "walled garden". The auth types you can use with a captive portal depend on the captive portal. See the docs for your portal.
Can I use mschap authentication for this and there are some specific documentation ?,i've searched a lot but i haven't found exhaustive documentation. And if I cannot use mschap, are there others solution for wi-fi authentication via LDAP?
I'm afraid this doesn't make sense to me. Can you describe in more detail what you're trying to do?
Sorry but my english is not so good, we need to implement a web-based login (Chillispot + Apache) connected to FreeRadius. FreeRadius needs to read informations on users using OpenLDAP. We need an exclusively web-based authentication for clients, avoiding the installation of external programs to check access like Xsupplicant. The implementation works fine with a MySQL Database, but the question is if is possible realize the same implementation using OpenLDAP instead of MySQL keeping for clients the same web-based login criterions. Thanks for your attention On 7/20/06, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Giuseppina Venezia wrote:
Hi, i'm using freeradius-1.1.2 with openldap for storing users account, for authenticate a WI-FI LAN. I need of a transparent authentication method since for the clients are heterogeneous so i can't use any type of EAP* authentication because I cannot install Xsupplicant on every Client.
If you mean 802.1x authentication, I don't think you understand how it works. All 802.1x (link layer) authentication methods use EAP, so all clients must have SOME kind of supplicant.
Non-802.1x authentication is normally done via some kind of web-based login. Google for "captive portal" or "walled garden". The auth types you can use with a captive portal depend on the captive portal. See the docs for your portal.
Can I use mschap authentication for this and there are some specific documentation ?,i've searched a lot but i haven't found exhaustive documentation. And if I cannot use mschap, are there others solution for wi-fi authentication via LDAP?
I'm afraid this doesn't make sense to me. Can you describe in more detail what you're trying to do? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
"Giuseppina Venezia" <giusy.venezia@gmail.com> wrote:
We need an exclusively web-based authentication for clients, avoiding the installation of external programs to check access like Xsupplicant. The implementation works fine with a MySQL Database, but the question is if is possible realize the same implementation using OpenLDAP instead of MySQL keeping for clients the same web-based login criterions.
Yes. Alan DeKok.
We have tried to integrate OpenLDAP and FreeRadius. When we try to authenticate with the clients this is the error message: Thu Jul 20 20:53:45 2006 : Info: Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1:32801, id=0, length=217 User-Name = "misterc" CHAP-Challenge = 0xa26932d73791f27d1314426f740ab34e CHAP-Password = 0x002e07a2cc1f27e7fbd22e7bb3721a3986 NAS-IP-Address = 0.0.0.0 Service-Type = Login-User Framed-IP-Address = 192.168.182.2 Calling-Station-Id = "XX-XX-XX-XX-XX-XX" Called-Station-Id = "AA-AA-AA-AA-DD-AA" NAS-Identifier = "nas01" Acct-Session-Id = "44bfd15d00000000" NAS-Port-Type = Wireless-802.11 NAS-Port = 0 Message-Authenticator = 0xf61479bee3c987c66cca254dcfa39c0a WISPr-Logoff-URL = "http://192.168.182.1:3990/logoff" Thu Jul 20 20:54:50 2006 : Debug: Processing the authorize section of radiusd.conf Thu Jul 20 20:54:50 2006 : Debug: modcall: entering group authorize for request 0 Thu Jul 20 20:54:50 2006 : Debug: modsingle[authorize]: calling eap (rlm_eap) for request 0 Thu Jul 20 20:54:50 2006 : Debug: rlm_eap: No EAP-Message, not doing EAP Thu Jul 20 20:54:50 2006 : Debug: modsingle[authorize]: returned from eap (rlm_eap) for request 0 Thu Jul 20 20:54:50 2006 : Debug: modcall[authorize]: module "eap" returns noop for request 0 Thu Jul 20 20:54:50 2006 : Debug: modsingle[authorize]: calling ldap (rlm_ldap) for request 0 Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: - authorize Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: performing user authorization for misterc Thu Jul 20 20:54:50 2006 : Debug: radius_xlat: '(uid=misterc)' Thu Jul 20 20:54:50 2006 : Debug: radius_xlat: 'ou=utenti,dc=XXXX,dc=it' Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: ldap_get_conn: Checking Id: 0 Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: ldap_get_conn: Got Id: 0 Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: attempting LDAP reconnection Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: (re)connect to 192.168.1.221:389, authentication 0 Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: bind as / to 192.168.1.221:389 Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: waiting for bind result ... Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: Bind was successful Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: performing search in ou=utenti,dc=XXXX,dc=it, with filter (uid=misterc) Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: object not found or got ambiguous search result Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: search failed Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: ldap_release_conn: Release Id: 0 Thu Jul 20 20:54:51 2006 : Debug: modsingle[authorize]: returned from ldap (rlm_ldap) for request 0 Thu Jul 20 20:54:51 2006 : Debug: modcall[authorize]: module "ldap" returns notfound for request 0 Thu Jul 20 20:54:51 2006 : Debug: modcall: leaving group authorize (returns noop) for request 0 Thu Jul 20 20:54:51 2006 : Debug: auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user Thu Jul 20 20:54:51 2006 : Debug: auth: Failed to validate the user. This is the Radius configuration we are using: my radius.conf modules { pap { encryption_scheme = clear } ldap { server="192.168.1.221" port="389" basedn="ou=utenti,dc=uniroma1,dc=it" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" start_tls = no access_attr = "uid" dictionary_mapping = ${raddbdir}/ldap.attrmap authtype = ldap ldap_connections_number = 5 password_header = "{SHA}" password_attribute = userPassword } } authorize { eap ldap } authenticate { Auth-Type PAP { pap } Auth-Type LDAP { ldap } } And this is the my OpenLDAP directory (maybe can be useful): My LDAP directory tree dn: dc=xxxx,dc=it dc: xxxx objectClass: dcObject objectClass: organizationalUnit ou: uniromaProject structuralObjectClass: organizationalUnit entryUUID: 8344c65e-aa07-102a-869a-1bfd23c6a14f creatorsName: cn=Manager,dc=xxxx,dc=it modifiersName: cn=Manager,dc=xxxx,dc=it createTimestamp: 20060717174334Z modifyTimestamp: 20060717174334Z entryCSN: 20060717174334Z#000000#00#000000 dn: dc=xxxx,dc=it dc: xxxx objectClass: dcObject objectClass: organizationalUnit ou: uniromaProject structuralObjectClass: organizationalUnit entryUUID: 8344c65e-aa07-102a-869a-1bfd23c6a14f creatorsName: cn=Manager,dc=xxxx,dc=it modifiersName: cn=Manager,dc=xxxx,dc=it createTimestamp: 20060717174334Z modifyTimestamp: 20060717174334Z entryCSN: 20060717174334Z#000000#00#000000 dn: cn=Luca Ricci,ou=utenti,dc=xxxx,dc=it uid: misterc description: bel giovine sn: Ricci cn: newperson cn: Luca Ricci structuralObjectClass: inetOrgPerson entryUUID: 729c0282-ab64-102a-8ceb-c14bbfafb8b4 creatorsName: cn=Manager,dc=xxxx,dc=it createTimestamp: 20060719112120Z userPassword:: e1NIQX1TQ01UU1l5cVpESHcvSXhqRUJGWHdQQnFTTXM9 objectClass: radiusprofile objectClass: inetOrgPerson radiusAuthType: LDAP entryCSN: 20060719135155Z#000000#00#000000 If you need any other information please ask us; sorry if we are boring you but we are trying and trying without any significant result. Thanks. On 7/20/06, Alan DeKok <aland@nitros9.org> wrote:
"Giuseppina Venezia" <giusy.venezia@gmail.com> wrote:
We need an exclusively web-based authentication for clients, avoiding the installation of external programs to check access like Xsupplicant. The implementation works fine with a MySQL Database, but the question is if is possible realize the same implementation using OpenLDAP instead of MySQL keeping for clients the same web-based login criterions.
Yes.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rad_recv: Access-Request packet from host 127.0.0.1:32801, id=0, length=217 User-Name = "misterc" CHAP-Challenge = 0xa26932d73791f27d1314426f740ab34e CHAP-Password = 0x002e07a2cc1f27e7fbd22e7bb3721a3986 NAS-IP-Address = 0.0.0.0 Service-Type = Login-User Framed-IP-Address = 192.168.182.2 Calling-Station-Id = "XX-XX-XX-XX-XX-XX" Called-Station-Id = "AA-AA-AA-AA-DD-AA" NAS-Identifier = "nas01" Acct-Session-Id = "44bfd15d00000000" NAS-Port-Type = Wireless-802.11 NAS-Port = 0 Message-Authenticator = 0xf61479bee3c987c66cca254dcfa39c0a WISPr-Logoff-URL = "http://192.168.182.1:3990/logoff"
Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: - authorize Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: performing user authorization for misterc Thu Jul 20 20:54:50 2006 : Debug: radius_xlat: '(uid=misterc)' Thu Jul 20 20:54:50 2006 : Debug: radius_xlat: 'ou=utenti,dc=XXXX,dc=it'
Ok rlm_ldap is initialized
Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: bind as / to 192.168.1.221:389 Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: waiting for bind result ... Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: Bind was successful
bind to the directory is Ok
Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: performing search in ou=utenti,dc=XXXX,dc=it, with filter (uid=misterc) Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: object not found or got ambiguous search result Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: search failed
Ah... Seems that the used bound to the ldap directory can't find uid=misterc in ou=utenti,dc=XXXX,dc=it
Thu Jul 20 20:54:51 2006 : Debug: auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
So Auth-Type isn't setted to Ldap
Thu Jul 20 20:54:51 2006 : Debug: auth: Failed to validate the user.
This is logical
ldap { server="192.168.1.221" port="389" basedn="ou=utenti,dc=uniroma1,dc=it" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" start_tls = no access_attr = "uid" dictionary_mapping = ${raddbdir}/ldap.attrmap authtype = ldap ldap_connections_number = 5 password_header = "{SHA}" password_attribute = userPassword } }
Well isn't it a pb of rights ? Is the anonymous user able to search the openldap directory for users entries ? What is the result of a simple "ldapsearch" with the same ldap filter.
If you need any other information please ask us; sorry if we are boring you but we are trying and trying without any significant result. Thanks.
Have you got ACLs in your openldap directory configuration files ? Regards, Thibault
Here is mi slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/samba.schema include /usr/local/etc/openldap/schema/RADIUS-LDAPv3.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org #Aggiungiamo il livello di logging loglevel 296 pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args #Direttive SSL #TLSCipherSuite HIGH #TLSCertificateFile /usr/local/etc/openldap/slapd-cert.pem #TLSCertificateKeyFile /usr/local/etc/openldap/slapd-key.pem # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=uniroma1,dc=it" rootdn "cn=Manager,dc=uniroma1,dc=it" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}gUlr8Lqr7eYgfSti9+Dl76lbkbgK3fqc # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data/uniroma1.it mode 0600 # Indices to maintain index objectClass eq,pres index cn eq,pres index uid eq,pres index userPassword eq,pres cachesize 2000 Thanks in advance Giusy Venezia On 7/20/06, Thibault Le Meur <Thibault.LeMeur@supelec.fr> wrote:
rad_recv: Access-Request packet from host 127.0.0.1:32801, id=0, length=217 User-Name = "misterc" CHAP-Challenge = 0xa26932d73791f27d1314426f740ab34e CHAP-Password = 0x002e07a2cc1f27e7fbd22e7bb3721a3986 NAS-IP-Address = 0.0.0.0 Service-Type = Login-User Framed-IP-Address = 192.168.182.2 Calling-Station-Id = "XX-XX-XX-XX-XX-XX" Called-Station-Id = "AA-AA-AA-AA-DD-AA" NAS-Identifier = "nas01" Acct-Session-Id = "44bfd15d00000000" NAS-Port-Type = Wireless-802.11 NAS-Port = 0 Message-Authenticator = 0xf61479bee3c987c66cca254dcfa39c0a WISPr-Logoff-URL = "http://192.168.182.1:3990/logoff"
Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: - authorize Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: performing user authorization for misterc Thu Jul 20 20:54:50 2006 : Debug: radius_xlat: '(uid=misterc)' Thu Jul 20 20:54:50 2006 : Debug: radius_xlat: 'ou=utenti,dc=XXXX,dc=it'
Ok rlm_ldap is initialized
Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: bind as / to 192.168.1.221:389 Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: waiting for bind result ... Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: Bind was successful
bind to the directory is Ok
Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: performing search in ou=utenti,dc=XXXX,dc=it, with filter (uid=misterc) Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: object not found or got ambiguous search result Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: search failed
Ah... Seems that the used bound to the ldap directory can't find uid=misterc in ou=utenti,dc=XXXX,dc=it
Thu Jul 20 20:54:51 2006 : Debug: auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
So Auth-Type isn't setted to Ldap
Thu Jul 20 20:54:51 2006 : Debug: auth: Failed to validate the user.
This is logical
ldap { server="192.168.1.221" port="389" basedn="ou=utenti,dc=uniroma1,dc=it" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" start_tls = no access_attr = "uid" dictionary_mapping = ${raddbdir}/ldap.attrmap authtype = ldap ldap_connections_number = 5 password_header = "{SHA}" password_attribute = userPassword } }
Well isn't it a pb of rights ? Is the anonymous user able to search the openldap directory for users entries ?
What is the result of a simple "ldapsearch" with the same ldap filter.
If you need any other information please ask us; sorry if we are boring you but we are trying and trying without any significant result. Thanks.
Have you got ACLs in your openldap directory configuration files ?
Regards, Thibault
Sorry, "dc=xxxx,dc=it" is the correct not "dc=uniroma1,dc=it" as appear in the other configuration file. Giusy Venezia On 7/20/06, Giuseppina Venezia <giusy.venezia@gmail.com> wrote:
Here is mi slapd.conf
# # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/samba.schema include /usr/local/etc/openldap/schema/RADIUS-LDAPv3.schema # Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org
#Aggiungiamo il livello di logging loglevel 296 pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args
#Direttive SSL #TLSCipherSuite HIGH #TLSCertificateFile /usr/local/etc/openldap/slapd-cert.pem #TLSCertificateKeyFile /usr/local/etc/openldap/slapd- key.pem # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la
# Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base= "" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING!
####################################################################### # BDB database definitions #######################################################################
database bdb suffix "dc=xxxx,dc=it" rootdn "cn=Manager,dc=xxxx,dc=it" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}gUlr8Lqr7eYgfSti9+Dl76lbkbgK3fqc # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data/xxxx.it mode 0600 # Indices to maintain index objectClass eq,pres index cn eq,pres index uid eq,pres index userPassword eq,pres cachesize 2000
Thanks in advance Giusy Venezia
On 7/20/06, Thibault Le Meur <Thibault.LeMeur@supelec.fr> wrote:
rad_recv: Access-Request packet from host 127.0.0.1:32801, id=0, length=217 User-Name = "misterc" CHAP-Challenge = 0xa26932d73791f27d1314426f740ab34e CHAP-Password = 0x002e07a2cc1f27e7fbd22e7bb3721a3986 NAS-IP-Address = 0.0.0.0 Service-Type = Login-User Framed-IP-Address = 192.168.182.2 Calling-Station-Id = "XX-XX-XX-XX-XX-XX" Called-Station-Id = "AA-AA-AA-AA-DD-AA" NAS-Identifier = "nas01" Acct-Session-Id = "44bfd15d00000000" NAS-Port-Type = Wireless-802.11 NAS-Port = 0 Message-Authenticator = 0xf61479bee3c987c66cca254dcfa39c0a WISPr-Logoff-URL = " http://192.168.182.1:3990/logoff"
Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: - authorize Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: performing user authorization for misterc Thu Jul 20 20:54:50 2006 : Debug: radius_xlat: '(uid=misterc)' Thu Jul 20 20:54:50 2006 : Debug: radius_xlat: 'ou=utenti,dc=XXXX,dc=it'
Ok rlm_ldap is initialized
Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: bind as / to 192.168.1.221:389 Thu Jul 20 20:54:50 2006 : Debug: rlm_ldap: waiting for bind result ... Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: Bind was successful
bind to the directory is Ok
Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: performing search in ou=utenti,dc=XXXX,dc=it, with filter (uid=misterc) Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: object not found or got ambiguous search result Thu Jul 20 20:54:51 2006 : Debug: rlm_ldap: search failed
Ah... Seems that the used bound to the ldap directory can't find uid=misterc in ou=utenti,dc=XXXX,dc=it
Thu Jul 20 20:54:51 2006 : Debug: auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
So Auth-Type isn't setted to Ldap
Thu Jul 20 20:54:51 2006 : Debug: auth: Failed to validate the user.
This is logical
ldap { server="192.168.1.221" port="389" basedn="ou=utenti,dc=uniroma1,dc=it" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" start_tls = no access_attr = "uid" dictionary_mapping = ${raddbdir}/ldap.attrmap authtype = ldap ldap_connections_number = 5 password_header = "{SHA}" password_attribute = userPassword } }
Well isn't it a pb of rights ? Is the anonymous user able to search the openldap directory for users entries ?
What is the result of a simple "ldapsearch" with the same ldap filter.
If you need any other information please ask us; sorry if we are boring you but we are trying and trying without any significant result. Thanks.
Have you got ACLs in your openldap directory configuration files ?
Regards, Thibault
On 7/20/06, Thibault Le Meur <Thibault.LeMeur@supelec.fr> wrote:
Well isn't it a pb of rights ? Is the anonymous user able to search the openldap directory for users entries ?
Yes, the anonymous user is able to search. What is the result of a simple "ldapsearch" with the same ldap filter. ldapsearch -x -b "dc=xxxx,dc=it" "(uid=misterc)" # extended LDIF # # LDAPv3 # base <dc=xxxx,dc=it> with scope subtree # filter: (uid=misterc) # requesting: ALL # # Vito Cu, utenti, xxxx.it dn: cn=Vito Cu,ou=utenti,dc=xxxx,dc=it uid: misterc description: bel giovine sn: Cu cn: newperson cn: Vito Cu userPassword:: e1NIQX1TQ01UU1l5cVpESHcvSXhqRUJGWHdQQnFTTXM9 objectClass: radiusprofile objectClass: inetOrgPerson radiusA 10:21 uthType: LDAP # search result search: 2 result: 0 Success 10:21 # numResponses: 2 # numEntries: 1 Have you got ACLs in your openldap directory configuration files ? All the users have the rights. Well, after some changes in OpenLDAP config, this is the result: Fri Jul 21 11:15:51 2006 : Debug: Processing the authorize section of radiusd.conf Fri Jul 21 11:15:51 2006 : Debug: modcall: entering group authorize for request 0 Fri Jul 21 11:15:51 2006 : Debug: modsingle[authorize]: calling eap (rlm_eap) for request 0 Fri Jul 21 11:15:51 2006 : Debug: rlm_eap: No EAP-Message, not doing EAP Fri Jul 21 11:15:51 2006 : Debug: modsingle[authorize]: returned from eap (rlm_eap) for request 0 Fri Jul 21 11:15:51 2006 : Debug: modcall[authorize]: module "eap" returns noop for request 0 Fri Jul 21 11:15:51 2006 : Debug: modsingle[authorize]: calling ldap (rlm_ldap) for request 0 Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: - authorize Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: performing user authorization for misterc Fri Jul 21 11:15:51 2006 : Debug: radius_xlat: '(uid=misterc)' Fri Jul 21 11:15:51 2006 : Debug: radius_xlat: 'ou=utenti,dc=xxxx,dc=it' Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: ldap_get_conn: Checking Id: 0 Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: ldap_get_conn: Got Id: 0 Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: attempting LDAP reconnection Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: (re)connect to 192.168.1.221:389, authentication 0 Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: bind as cn=Manager,dc=xxxx,dc=it/PASSWORD to 192.168.1.221:389 Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: waiting for bind result ... Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: Bind was successful Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: performing search in ou=utenti,dc=xxxx,dc=it, with filter (uid=misterc) Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: checking if remote access for misterc is allowed by userPassword Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: Added password {SHA}SCMTSYyqZDHw/IxjEBFXwPBqSMs= in check items Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: looking for check items in directory... Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: Adding radiusAuthType as Auth-Type, value LDAP & op=21 Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: Adding userPassword as User-Password, value {SHA}SCMTSYyqZDHw/IxjEBFXwPBqSMs= & op=21 Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: looking for reply items in directory... Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: user misterc authorized to use remote access Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: ldap_release_conn: Release Id: 0 Fri Jul 21 11:15:51 2006 : Debug: modsingle[authorize]: returned from ldap (rlm_ldap) for request 0 Fri Jul 21 11:15:51 2006 : Debug: modcall[authorize]: module "ldap" returns ok for request 0 Fri Jul 21 11:15:51 2006 : Debug: modcall: leaving group authorize (returns ok) for request 0 Fri Jul 21 11:15:51 2006 : Debug: rad_check_password: Found Auth-Type LDAP Fri Jul 21 11:15:51 2006 : Debug: auth: type "LDAP" Fri Jul 21 11:15:51 2006 : Debug: Processing the authenticate section of radiusd.conf Fri Jul 21 11:15:51 2006 : Debug: modcall: entering group LDAP for request 0 Fri Jul 21 11:15:51 2006 : Debug: modsingle[authenticate]: calling pap (rlm_pap) for request 0 Fri Jul 21 11:15:51 2006 : Auth: rlm_pap: Attribute "Password" is required for authentication. Cannot use "CHAP-Password". Fri Jul 21 11:15:51 2006 : Debug: modsingle[authenticate]: returned from pap (rlm_pap) for request 0 Fri Jul 21 11:15:51 2006 : Debug: modcall[authenticate]: module "pap" returns invalid for request 0 Fri Jul 21 11:15:51 2006 : Debug: modsingle[authenticate]: calling ldap (rlm_ldap) for request 0 Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: - authenticate Fri Jul 21 11:15:51 2006 : Auth: rlm_ldap: Attribute "User-Password" is required for authentication. Cannot use "CHAP-Password". Fri Jul 21 11:15:51 2006 : Debug: modsingle[authenticate]: returned from ldap (rlm_ldap) for request 0 Fri Jul 21 11:15:51 2006 : Debug: modcall[authenticate]: module "ldap" returns invalid for request 0 Fri Jul 21 11:15:51 2006 : Debug: modcall: leaving group LDAP (returns invalid) for request 0 Fri Jul 21 11:15:51 2006 : Debug: auth: Failed to validate the user. Config files are the same of above. Best regards. Giusy Venezia
Well, after some changes in OpenLDAP config, this is the result:
So your first issue was openldap related...
Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: bind as cn=Manager,dc=xxxx,dc=it/PASSWORD to 192.168.1.221:389 Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: waiting for bind result ... Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: Bind was successful
Bind as manager is ok...
Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: performing search in ou=utenti,dc=xxxx,dc=it, with filter (uid=misterc) Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: checking if remote access for misterc is allowed by userPassword Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: Added password {SHA}SCMTSYyqZDHw/IxjEBFXwPBqSMs= in check items Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: looking for check items in directory... Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: Adding radiusAuthType as Auth-Type, value LDAP & op=21 Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: Adding userPassword as User-Password, value {SHA}SCMTSYyqZDHw/IxjEBFXwPBqSMs= & op=21 Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: looking for reply items in directory... Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: user misterc authorized to use remote access
Great rlm_ldap has retreived everything needed.
Fri Jul 21 11:15:51 2006 : Debug: modcall: leaving group authorize (returns ok) for request 0
Now it's time to run the authenticate module
Fri Jul 21 11:15:51 2006 : Debug: rad_check_password: Found Auth-Type LDAP Fri Jul 21 11:15:51 2006 : Debug: auth: type "LDAP" Fri Jul 21 11:15:51 2006 : Debug: Processing the authenticate section of radiusd.conf
Ldap module will be used (that is to say a bind with the user's credential will be attempted, provided that the request contains the necessary data.
Fri Jul 21 11:15:51 2006 : Debug: modcall: entering group LDAP for request 0 Fri Jul 21 11:15:51 2006 : Debug: modsingle[authenticate]: calling pap (rlm_pap) for request 0 Fri Jul 21 11:15:51 2006 : Auth: rlm_pap: Attribute "Password" is required for authentication. Cannot use "CHAP-Password".
Well, it seems that your radius client is trying CHAP and not PAP. You wrote in a previous mail that the request was: rad_recv: Access-Request packet from host 127.0.0.1:32801, id=0, length=217 User-Name = "misterc" CHAP-Challenge = 0xa26932d73791f27d1314426f740ab34e CHAP-Password = 0x002e07a2cc1f27e7fbd22e7bb3721a3986 NAS-IP-Address = 0.0.0.0 Service-Type = Login-User Framed-IP-Address = 192.168.182.2 Calling-Station-Id = "XX-XX-XX-XX-XX-XX" Called-Station-Id = "AA-AA-AA-AA-DD-AA" NAS-Identifier = "nas01" Acct-Session-Id = "44bfd15d00000000" NAS-Port-Type = Wireless-802.11 NAS-Port = 0 Message-Authenticator = 0xf61479bee3c987c66cca254dcfa39c0a WISPr-Logoff-URL = "http://192.168.182.1:3990/logoff" That means that your client is trying MS-CHAP, and MS-CHAP can't be used with something else than NT-Hash passwords or cleartext passwords in the authorize backend (in your case LDAP). Thibault
Thibault Le Meur wrote:
rad_recv: Access-Request packet from host 127.0.0.1:32801, id=0, length=217 User-Name = "misterc" CHAP-Challenge = 0xa26932d73791f27d1314426f740ab34e CHAP-Password = 0x002e07a2cc1f27e7fbd22e7bb3721a3986
That means that your client is trying MS-CHAP, and MS-CHAP can't be used with something else than NT-Hash passwords or cleartext passwords in the authorize backend (in your case LDAP).
No, it does NOT. It means his client is trying CHAP. Not MS-CHAP
Thibault Le Meur wrote:
rad_recv: Access-Request packet from host 127.0.0.1:32801, id=0, length=217 User-Name = "misterc" CHAP-Challenge = 0xa26932d73791f27d1314426f740ab34e CHAP-Password = 0x002e07a2cc1f27e7fbd22e7bb3721a3986
That means that your client is trying MS-CHAP, and MS-CHAP can't be used with something else than NT-Hash passwords or cleartext
passwords in the
authorize backend (in your case LDAP).
No, it does NOT.
It means his client is trying CHAP. Not MS-CHAP
You're right... sorry I was too fast in my reply... ;-) but the conclusion was about the same : use a cleartext password (except for the Nt-hash alternative ;-) ). Thibault
All right Now authentication works fine. Many thanks to all ones which have given me these useful advices Have a nice day Thanks Again Giusy Venezia
dn: cn=Vito Cu,ou=utenti,dc=xxxx,dc=it userPassword:: e1NIQX1TQ01UU1l5cVpESHcvSXhqRUJGWHdQQnFTTXM9
This is: userPassword: {SHA}SCMTSYyqZDHw/IxjEBFXwPBqSMs= You MUST have plaintext passwords in your LDAP directory to do CHAP. Fri Jul 21 11:15:51 2006 : Debug: rlm_ldap: Adding userPassword as User-Password, value {SHA}SCMTSYyqZDHw/IxjEBFXwPBqSMs= & op=21 Fri Jul 21 11:15:51 2006 : Debug: auth: type "LDAP" Fri Jul 21 11:15:51 2006 : Debug: Processing the authenticate section of radiusd.conf Fri Jul 21 11:15:51 2006 : Debug: modcall: entering group LDAP for request 0 Fri Jul 21 11:15:51 2006 : Debug: modsingle[authenticate]: calling pap (rlm_pap) for request 0 Fri Jul 21 11:15:51 2006 : Auth: rlm_pap: Attribute "Password" is required for authentication. Cannot use "CHAP-Password". Your NAS submitted a CHAP request. You cannot check CHAP requests by simple bind to LDAP, only PAP. You have three choices: 1. Store plaintext passwords in userPassword in LDAP, and use CHAP, configured like this: authorize { preprocess chap ldap } authenticate { Auth-Type CHAP { chap } } 2. Store whatever you like in LDAP, configure your NAS to use PAP and LDAP simple binds, configured like this: authorize { preprocess ldap } authenticate { Auth-Type LDAP { ldap } } 3. Store crypted passwords in userPassword, configure your NAS to use PAP, and do PAP at the server side. Not recommended.
participants (4)
-
Alan DeKok -
Giuseppina Venezia -
Phil Mayers -
Thibault Le Meur