On Thu, 2007-07-26 at 14:56 +0200, inverse wrote:
> Hi,
>
> this problem is simple (everything not shown here is v1.1.6
> out-f-the-box radiusd configuration):
>
> users file line:
> [EMAIL PROTECTED] Auth-Type := EAP, User-Password == "a", Ldap-Group ==
> "wifi"
Totally wrong. You want:
[EMAIL PROTECTED] Cleartext-Password := "a", Ldap-Group == "wifi"
Don't set auth type
Don't compare the password; set the server-side one
>
> this is a test line, [EMAIL PROTECTED] uses EAP-MD5 , but I want to
> check if he's in the Ldap-Group named 'wifi'.
>
> radiusd.conf lines, ldap section:
>
> filter ="(uid=%{User-Name})"
> edir_account_policy_check=no
> password_attribute = userPassword
> groupmembership_filter =
> "(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))"
>
> This is where I actually suck. I think this is correct, but it won't
> work as expected because:
>
>
> rad_recv: Access-Request packet from host 149.132.5.108:35285, id=0,
> length=160
> User-Name = "[EMAIL PROTECTED]"
> NAS-IP-Address = 127.0.0.1
> Calling-Station-Id = "02-00-00-00-00-01"
> Framed-MTU = 1400
> NAS-Port-Type = Wireless-802.11
> Connect-Info = "CONNECT 11Mbps 802.11b"
> EAP-Message =
> 0x0200001f0170616f6c6f2e676169617264656c6c6940756e696d69622e6974
> Message-Authenticator = 0x14b3675352d738629cc1bb21695f3122
> Processing the authorize section of radiusd.conf
> modcall: entering group authorize for request 0
> modcall[authorize]: module "preprocess" returns ok for request 0
> radius_xlat: '/var/log/radius/radacct/127.0.0.1/auth-detail-20070726'
> rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d
> expands to /var/log/radius/radacct/127.0.0.1/auth-detail-20070726
> modcall[authorize]: module "auth_log" returns ok for request 0
> modcall[authorize]: module "chap" returns noop for request 0
> modcall[authorize]: module "mschap" returns noop for request 0
> rlm_realm: Looking up realm "test.com" for User-Name = "[EMAIL PROTECTED]"
> rlm_realm: Found realm "test.com"
> rlm_realm: Proxying request from user john.doe to realm test.com
> rlm_realm: Adding Realm = "test.com"
> rlm_realm: Authentication realm is LOCAL.
> modcall[authorize]: module "suffix" returns noop for request 0
> rlm_eap: EAP packet type response id 0 length 31
> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
> modcall[authorize]: module "eap" returns updated for request 0
> rlm_ldap: Entering ldap_groupcmp()
> radius_xlat: 'dc=test,dc=com
> radius_xlat: '([EMAIL PROTECTED])'
> rlm_ldap: ldap_get_conn: Checking Id: 0
> rlm_ldap: ldap_get_conn: Got Id: 0
> rlm_ldap: attempting LDAP reconnection
> rlm_ldap: (re)connect to ldap.test.com:636, authentication 0
> rlm_ldap: setting TLS mode to 1
> rlm_ldap: setting TLS CACert File to /usr/local/etc/raddb/certs/crl/root.pem
> rlm_ldap: bind as cn=ldapreader,ou=servizi,dc=test,dc=com/blargh to
> ldap.test.com:636
> rlm_ldap: waiting for bind result ...
> rlm_ldap: Bind was successful
> rlm_ldap: performing search in dc=test,dc=com, with filter
> ([EMAIL PROTECTED])
> rlm_ldap: ldap_release_conn: Release Id: 0
> radius_xlat: '(&(objectClass=GroupOfNames)([EMAIL PROTECTED]))'
>
> This is where the problem arises. I don't want to check if
> [EMAIL PROTECTED] esists.
> rlm_ldap wants to, but that's not what I told him to do. I never told
> rlm_ldap to verify if [EMAIL PROTECTED] is an LDAP user. Now he is,
> but only because I created him.
You've got the "ldap" module in "authorize". Remove it.
You will need to put it in "instantiate" so that it gets initialised,
but you don't want to check it during authorize.
>
>
> rlm_ldap: ldap_get_conn: Checking Id: 0
> rlm_ldap: ldap_get_conn: Got Id: 0
> rlm_ldap: performing search in dc=test,dc=com, with filter
> (&(cn=wifi)(&(objectClass=GroupOfNames)([EMAIL PROTECTED])))
> rlm_ldap::ldap_groupcmp: User found in group wifi
>
> and THIS is what I want rlm_ldap to do.
> I want to check this and only this, since [EMAIL PROTECTED] is a
> member of wifi and doesn't exist anywhere else in the LDAP tree. He
> isn't a user. He's just an object in group wifi.
> That's what happens in my production environment. john'doe's login
> fails because the first useless search fails.
> I know I'm doing something horribly wrong, and I can't find out what's
> my major malfunction.
Remove "ldap" from the "authorize" section and put it in the
"instantiate" section
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
