Krisztián,
It depends on the hash you store in LDAP. If the hash is MD5, you can use it directly in
the digest algorithm. If its SSHA1 or something, you are basically stuck. Either store
clear-text in LDAP, or forget about it. Of course, what you can do is to implement a
conversion of SSHA when users are logging in. But this is only possible if you at one
point actually has the clear-text password...
g-)
---- Original Message ----
From: Gyebnár Krisztián
To: serusers(a)lists.iptel.org
Sent: Sunday, July 03, 2005 06:09 AM
Subject: [Serusers] SER+RADIUS+LDAP with encrypted passwords
Dear all,
I'm new in SER and i have a serius problem about implementing the
authentication system from LDAP;
SER<->freeRADIUS<->LDAP(user/pass(encrypted));
We have installed SER + Freeradius + LDAP system, the SER parts of
configuration works fine.
if any SIP client coming into the SER the auth_radius modul forward
the request correctly to the freeradius:
the problem is the following:
rad_recv: Access-Request packet from host 127.0.0.1:50272, id=36,
length=197
User-Name = "test(a)test.hu"
Digest-Attributes = 0x0a076779656269
Digest-Attributes = 0x010d667265656d61696c2e6875
Digest-Attributes =
0x022a34326337353933653330366534626363613836343837343332646635383363366139636364383038
Digest-Attributes = 0x04117369703a667265656d61696c2e6875
Digest-Attributes = 0x030a5245474953544552
Digest-Response = "204aea65f72efb70b809ed425bec099c"
Service-Type = Sip-Session
Sip-Uri-User = "test"
NAS-IP-Address = 127.0.0.1
NAS-Port = 5060
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 4
modcall[authorize]: module "preprocess" returns ok for request 4
modcall[authorize]: module "chap" returns noop for request 4
rlm_eap: No EAP-Message, not doing EAP
modcall[authorize]: module "eap" returns noop for request 4
rlm_digest: Converting Digest-Attributes to something sane...
Digest-User-Name = "test"
Digest-Realm = "test.hu"
Digest-Nonce = "42c7593e306e4bcca86487432df583c6a9ccd808"
Digest-URI = "sip:test.hu"
Digest-Method = "REGISTER"
rlm_digest: Adding Auth-Type = DIGEST
modcall[authorize]: module "digest" returns ok for request 4
rlm_realm: Looking up realm "test.hu" for User-Name = test(a)test.hu
rlm_realm: No such realm "test.hu"
modcall[authorize]: module "suffix" returns noop for request 4
users: Matched entry DEFAULT at line 160
modcall[authorize]: module "files" returns ok for request 4
modcall[authorize]: module "mschap" returns noop for request 4
modcall: group authorize returns ok for request 4
rad_check_password: Found Auth-Type LDAP
auth: type "LDAP"
Processing the authenticate section of radiusd.conf
modcall: entering group Auth-Type for request 4
rlm_ldap: - authenticate
rlm_ldap: Attribute "User-Password" is required for authentication.
modcall[authenticate]: module "ldap" returns invalid for request 4
modcall: group Auth-Type returns invalid for request 4
auth: Failed to validate the user.
Login incorrect: [test(a)test.hu/<no User-Password attribute>] (from
client localhost port 5060)
Delaying request 4 for 1 seconds
so the ldap modul expect the "User-Password" attribute from radius
client, but because of DIGEST authentication only get
"DIGEST-ATTRIBUTES" from the SIP router,
Anyway, how to possible to authenticate the users with DIGEST
authentication, if the RADIUS can not see cleartext passwords in LDAP
?.
I'm not expert in password math and calculations, and also read the
sterman draft to explain this to me.
So i suppose the following method:
Radius get the RADIUS request.-->Convert the DIGEST-ATTRIBUTES to
readable format.-->to calculate the DIGEST AUTH. values the RADIUS
have to do LDAP lookup for the PASSWORD-> Calculate the DIGEST AUTH.
value and comapare it with the recieved one, if match the user
authenticated.
It's right ?
The radius authentication system works fine with DIGEST
authentication, if I store the user/pass on local file system (in
users file) and also works authenticate from LDAP without DIGEST auth
(try with radtest).
Has anybody experience with this problem, DIGEST auth with LDAP ?
THX
Krisztián
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers