Thanks,
J.
Relevant parts of the radiusd.conf:
ldap {
...
password_header = "{NT}"
password_radius_attribute = NT-Password
password_attribute = userPassword
...
}
in ldap.attrmap I've got:
checkItem NT-Password userPassword
Output from radiusd -X:
rad_recv: Access-Request packet from host 10.160.111.240:21645, id=135, length=124
User-Name = "t1"
Framed-MTU = 1400
Called-Station-Id = "0012.4335.2790"
Calling-Station-Id = "000a.95f4.a02a"
Service-Type = Login-User
Message-Authenticator = 0xc5e5ca34d3a7256d115ff5a4d6eb137e
EAP-Message = 0x02020007017431
NAS-Port-Type = Wireless-802.11
NAS-Port = 335
NAS-IP-Address = 10.160.111.240
NAS-Identifier = "D_C1200"
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
modcall[authorize]: module "preprocess" returns ok for request 0
rlm_ldap: - authorize
rlm_ldap: performing user authorization for t1
radius_xlat: '(uid=t1)'
radius_xlat: 'ou=People,dc=d,dc=com'
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 localhost:389, authentication 0
rlm_ldap: bind as uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot/password to localhost:389
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind was successful
rlm_ldap: performing search in ou=People,dc=d,dc=com, with filter (uid=t1)
rlm_ldap: checking if remote access for t1 is allowed by vpnaccess
rlm_ldap: Added password 8846F7EAEE8FB117AD06BDD830B7586C in check items
rlm_ldap: looking for check items in directory...
rlm_ldap: Adding userPassword as NT-Password, value { & op=21
rlm_ldap: looking for reply items in directory...
rlm_ldap: user t1 authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
modcall[authorize]: module "ldap" returns ok for request 0
radius_xlat: '[{NT}]'
radius_xlat: '0x'
rlm_attr_rewrite: Changed value for attribute NT-Password from '{' to '0x'
modcall[authorize]: module "attr_rewrite" returns ok for request 0
rlm_eap: EAP packet type response id 2 length 7
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 0
modcall: group authorize returns updated for request 0
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 0
rlm_eap: EAP Identity
rlm_eap: processing type leap
rlm_eap_leap: Stage 2
rlm_eap_leap: Issuing AP Challenge
rlm_eap_leap: Successfully initiated
modcall[authenticate]: module "eap" returns handled for request 0
modcall: group authenticate returns handled for request 0
Sending Access-Challenge of id 135 to 10.160.111.240:21645
EAP-Message = 0x01030012110100084435b895bbcec9917431
Message-Authenticator = 0x00000000000000000000000000000000
State = 0xdb96ab9778649ff3e02b55cbeac401f8
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
rad_recv: Access-Request packet from host 10.160.111.240:21645, id=136, length=169
User-Name = "t1"
Framed-MTU = 1400
Called-Station-Id = "0012.4335.2790"
Calling-Station-Id = "000a.95f4.a02a"
Service-Type = Login-User
Message-Authenticator = 0xb70e23edab02093920e0bfe045513bc0
EAP-Message = 0x0203002211010018a21eae4e3a12932215f05e53749090212cf7c44501f967f17431
NAS-Port-Type = Wireless-802.11
NAS-Port = 335
State = 0xdb96ab9778649ff3e02b55cbeac401f8
NAS-IP-Address = 10.160.111.240
NAS-Identifier = "D_C1200"
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 1
modcall[authorize]: module "preprocess" returns ok for request 1
rlm_ldap: - authorize
rlm_ldap: performing user authorization for t1
radius_xlat: '(uid=t1)'
radius_xlat: 'ou=People,dc=d,dc=com'
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: performing search in ou=People,dc=d,dc=com, with filter (uid=t1)
rlm_ldap: checking if remote access for t1 is allowed by vpnaccess
rlm_ldap: Added password 8846F7EAEE8FB117AD06BDD830B7586C in check items
rlm_ldap: looking for check items in directory...
rlm_ldap: Adding userPassword as NT-Password, value { & op=21
rlm_ldap: looking for reply items in directory...
rlm_ldap: user t1 authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
modcall[authorize]: module "ldap" returns ok for request 1
radius_xlat: '[{NT}]'
radius_xlat: '0x'
rlm_attr_rewrite: Changed value for attribute NT-Password from '{' to '0x'
modcall[authorize]: module "attr_rewrite" returns ok for request 1
rlm_eap: EAP packet type response id 3 length 34
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 1
modcall: group authorize returns updated for request 1
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 1
rlm_eap: Request found, released from the list
rlm_eap: EAP/leap
rlm_eap: processing type leap
rlm_eap_leap: Stage 4
rlm_eap_leap: FAILED incorrect NtChallengeResponse from AP
rlm_eap: Handler failed in EAP/leap
rlm_eap: Failed in EAP select
modcall[authenticate]: module "eap" returns invalid for request 1
modcall: group authenticate returns invalid for request 1
auth: Failed to validate the user.
Sending Access-Reject of id 136 to 10.160.111.240:21645
EAP-Message = 0x04030004
Message-Authenticator = 0x00000000000000000000000000000000
Finished request 1
Going to the next request
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 135 with timestamp 42093c92
Cleaning up request 1 ID 136 with timestamp 42093c92
Nothing to do. Sleeping until we see a request.
On Feb 8, 2005, at 2:44 PM, Jason Howk wrote:
Great, I'll give it a shot. Thanks a bunch.
--Jason.
On Feb 8, 2005, at 2:40 PM, Kostas Kalevras wrote:
On Tue, 8 Feb 2005, Kostas Kalevras wrote:
On Tue, 8 Feb 2005, Jason Howk wrote:
OK. I think I found my issue...
When mapping the NT-Password to the userPassword, freeRadius is not reading beyond the first character of the attribute when it's a "{". Subsequently all that I see is, "Adding userPassword as NT-Password, value { & op=21". To see if it was just this attribute or others, I tried the same thing with the ntPassword attribute. The same result happened. It seems that regardless of attribute being mapped, if there's a "{" in the attribute, freeRadius won't read any further -- or that's what it seems like it's doing.
My attr_rewrite module is active but obviously doesn't see the whole string, and so isn't re-writing anything meaningful. Is there something that I need to be doing for it to read or is it a limitation?
It's a limitation. Please wait till tomorrow, i 'll work out a solution in the meantime.
Do a cvs update on the rlm_ldap module, make;make install the new version.
Add a password_radius_attribute = "NT-Password" in your rlm_ldap configuration, configure password_attribute = "userPassword", password_header = "{NT}" and everything should work ok.
Thanks,
J.
On Feb 8, 2005, at 4:11 AM, Kostas Kalevras wrote:
On Mon, 7 Feb 2005, Jason Howk wrote:- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I'm wondering if anyone has ever tried to put an NT hash password directly into the LDAP userPassword field, and have it authenticated through free radius.I think your best choise would be to continue mapping the userpassword attribute to NT-Password and use the attr_rewrite module after the ldap module in the authorize section to remove the {NT} part and addd a '0x' at the start of NT-Password.
Here's the situation:
We have a working configuration that is setup as EAP-LEAP and LDAP where the NT hash is stored in the ntPassword attribute (as is a typical implementation). It works great, but causes some issues on our side (more process that technical), so I wrote a SunOne passwd storage plugin that creates an NT hash and uses that vs. the standard CLEAR,SHA-1,SSHA, etc. schemes. My plugin that creates an NT hash instead works as expected with users who are being added, binding to the repository. Essentially all things LDAP are fine. My questions focus around how freeRadius authenticates against LDAP.
My main question is can I modify the LDAP attribute mapping to point the NT-Password to userPassword, and have it work? I'm concerned that freeRadius isn't going to understand my {NT} prefix that's prepended to the password. Even if I declare it in the LDAP module, is my only way to indicate that it's a NT hash by pointing the NT-Password attribute at it? Also, I have an additional concern that since it's not currently being written as "0x" and the password, that freeRadius won't see it either. Should I then create such that the password is seen as "{NT}0x" followed by the password?
I'm in the process of testing now, but I was wondering if anyone has gone down this road before. If not, I'll update if anyone want to know what I did...
--J.--
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Kostas Kalevras Network Operations Center
[EMAIL PROTECTED] National Technical University of Athens, Greece
Work Phone: +30 210 7721861
'Go back to the shadow' Gandalf
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
Kostas Kalevras Network Operations Center
[EMAIL PROTECTED] National Technical University of Athens, Greece
Work Phone: +30 210 7721861
'Go back to the shadow' Gandalf
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
Kostas Kalevras Network Operations Center
[EMAIL PROTECTED] National Technical University of Athens, Greece
Work Phone: +30 210 7721861
'Go back to the shadow' Gandalf
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
