Re: NT hashed password in userPassword attribute.
Kostas et al, I tried again and I'm not getting in either. Everyting looks right. freeRadius loads the password in the NT-Password attribute, and I re-write it to '0x'. It looks right but indicates that the failed challenge response. Can you see anything in here that doesn't look right?
rad_recv: Access-Request packet from host 10.160.111.240:21645, id=175, 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 = 0x8b699b80db91eb08896aabf4df10dfca
EAP-Message = 0x02020007017431
NAS-Port-Type = Wireless-802.11
NAS-Port = 355
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: Added password {NT}8846F7EAEE8FB117AD06BDD830B7586C in check items as NT-Password
rlm_ldap: looking for check items in directory...
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 '{NT}8846F7EAEE8FB117AD06BDD830B7586C' to '0x8846F7EAEE8FB117AD06BDD830B7586C'
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 175 to 10.160.111.240:21645
EAP-Message = 0x010300121101000828a3d7b3468414667431
Message-Authenticator = 0x
State = 0x77cfbf13a271f88c14c10a27080c0768
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=176, 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 = 0xd493ede14a0484c78f69c7ff133fb7e7
EAP-Message = 0x02030022110100185b15aa386e51b7356eebcc03c1f4303c077e5777121f324c7431
NAS-Port-Type = Wireless-802.11
NAS-Port = 355
State = 0x77cfbf13a271f88c14c10a27080c0768
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: Added password {NT}8846F7EAEE8FB117AD06BDD830B7586C in check items as NT-Password
rlm_ldap: looking for check items in directory...
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 '{NT}8846F7EAEE8FB117AD06BDD830B7586C' to '0x8846F7EAEE8FB117AD06BDD830B7586C'
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:
Re: NT hashed password in userPassword attribute.
Jason Howk [EMAIL PROTECTED] wrote:
rlm_attr_rewrite: Changed value for attribute NT-Password from
'{NT}8846F7EAEE8FB117AD06BDD830B7586C' to
'0x8846F7EAEE8FB117AD06BDD830B7586C'
You should remove the {NT} header, and nothing more All of the code
in the server which uses NT-Password will accept the hex format.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: NT hashed password in userPassword attribute.
No go. I put in some additional debug statements and recompiled
eap_leap and I'm seeing some interesting results. If I follow what is
described below, the output from the call to
eapleap_ntpwdhash()(eap_leap.c:198) is totally different if I revert
back to using the LDAP ntPassword attribute with a valid octet string
that starts with '0x'. The passwords used in each test are exactly the
same so I would expect that the password to be hashed should be
equivalent regardless of method. This isn't happening...
--Jason.
On Feb 14, 2005, at 10:40 AM, Alan DeKok wrote:
Jason Howk [EMAIL PROTECTED] wrote:
rlm_attr_rewrite: Changed value for attribute NT-Password from
'{NT}8846F7EAEE8FB117AD06BDD830B7586C' to
'0x8846F7EAEE8FB117AD06BDD830B7586C'
You should remove the {NT} header, and nothing more All of the code
in the server which uses NT-Password will accept the hex format.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: NT hashed password in userPassword attribute.
Jason Howk [EMAIL PROTECTED] wrote: No go. I put in some additional debug statements and recompiled eap_leap and I'm seeing some interesting results. If I follow what is described below, the output from the call to eapleap_ntpwdhash()(eap_leap.c:198) is totally different if I revert back to using the LDAP ntPassword attribute with a valid octet string that starts with '0x'. The passwords used in each test are exactly the same so I would expect that the password to be hashed should be equivalent regardless of method. This isn't happening... Ok.. I'm not sure what else to suggest. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: NT hashed password in userPassword attribute.
Maybe this will help: In eap_leap.c:219 there's an if statement looking for the normal password attribute. If that's not found according to the comments must be an NT-Password. The value that's being assigned to the ntpwdhash is coming from password-strvalue. I ran a test an in the normal case (freeRadius pulling the NT-Password from the ntPassword attribute with the '0x'), the strvalue seems to be in bytes and when running the other scenario, the value is in ASCII. I'm going to test to see if I convert that string back into bytes if it works... BTW, I can move this thread to the development list if you want. --J. On Feb 14, 2005, at 1:58 PM, Alan DeKok wrote: Jason Howk [EMAIL PROTECTED] wrote: No go. I put in some additional debug statements and recompiled eap_leap and I'm seeing some interesting results. If I follow what is described below, the output from the call to eapleap_ntpwdhash()(eap_leap.c:198) is totally different if I revert back to using the LDAP ntPassword attribute with a valid octet string that starts with '0x'. The passwords used in each test are exactly the same so I would expect that the password to be hashed should be equivalent regardless of method. This isn't happening... Ok.. I'm not sure what else to suggest. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: NT hashed password in userPassword attribute.
Hi, 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. Just one nosy question (I'm always trying to collect data on that issue): Why are you using NT hash passwords instead of cleartext passwords? TIA, Stefan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: NT hashed password in userPassword attribute.
Sure. The main reason why I am moving down this approach is two fold -- one systematic, one more philosophical. First, in our particular implementation we need to use (i.e are locked into using) EAP-LEAP. LEAP supports two variants for the password, clear text and NT hashed password. The LEAP limitation very quickly narrows down our choices in terms of password storage schemes. Additionally, there are some other related issues that make using a one-way hash such as SHA-1 and SSHA worthless as I will never know the seed used to these algorithms. For us to evolve to a better solution would require more development than can be accomplished in the time frame that I'm working in. The more philosophical aspect is that we believe (again an opinion, not stated as a fact) based on the transmission characteristics and location and data being persisted in LDAP, that a password in any form other than clear text is better than clear text. I'm not necessarily saying that having a password in an NT hash is more secure, per se, but that it presents an additional layer of obscurity. I personally don't agree with the blanket statement that password's in clear text aren't any worse. There is a time and a place for most things, but it's situational in nature, and in our situation it's not something that we're considering. --J. . One, based on the location of our On Feb 9, 2005, at 4:10 AM, [EMAIL PROTECTED] wrote: Hi, 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. Just one nosy question (I'm always trying to collect data on that issue): Why are you using NT hash passwords instead of cleartext passwords? TIA, Stefan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: NT hashed password in userPassword attribute.
On Mon, 7 Feb 2005, Jason Howk wrote:
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.
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...
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.
--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
Re: NT hashed password in userPassword attribute.
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?
Thanks,
J.
On Feb 8, 2005, at 4:11 AM, Kostas Kalevras wrote:
On Mon, 7 Feb 2005, Jason Howk wrote:
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.
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...
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.
--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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: NT hashed password in userPassword attribute.
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.
Thanks,
J.
On Feb 8, 2005, at 4:11 AM, Kostas Kalevras wrote:
On Mon, 7 Feb 2005, Jason Howk wrote:
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.
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...
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.
--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
- 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
Re: NT hashed password in userPassword attribute.
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:
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.
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...
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.
--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
- 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
Re: NT hashed password in userPassword attribute.
Thanks. I Appreciate it.
--Jason.
On Feb 8, 2005, at 2:10 PM, 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.
Thanks,
J.
On Feb 8, 2005, at 4:11 AM, Kostas Kalevras wrote:
On Mon, 7 Feb 2005, Jason Howk wrote:
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.
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...
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.
--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
- 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
Re: NT hashed password in userPassword attribute.
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:
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.
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...
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.
--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
- 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
Re: NT hashed password in userPassword attribute.
I'm not getting it to work. I did just an LDAP rebuild and I didn't see a change, so I did a full checkout and compile with no results there either. Am I missing something?
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 = 0x
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:
Re: NT hashed password in userPassword attribute.
On Tue, 8 Feb 2005, Jason Howk wrote:
I'm not getting it to work. I did just an LDAP rebuild and I didn't see a
change, so I did a full checkout and compile with no results there either.
Am I missing something?
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
Please remove that and only leave the password_* configuration directives.
--
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
Re: NT hashed password in userPassword attribute.
Kostas Kalevras [EMAIL PROTECTED] wrote:
...
On a related note, I've been talking with someone who's been working
on auto-discovery of passwords. This should minimize configuration.
e.g.
{nt}blah - NT-Password = blah
{crypt}blah - Crypt-Password = blah
...
I've updated rlm_pap to have an auto configuration item, where it
automatically discovers what to do, based on the attribute it's been
given.
I've also updated rlm_mschap, so that the hashes it returns are in
hex, and not in binary. The code previously did:
md4_calc(buffer...)
return strlen(buffer)
which meant that any zeros in the buffer would terminate the string.
Please check that it doesn't break anything. I've tested the new
code with some simple tests, but not any complex ones.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: NT hashed password in userPassword attribute.
Removed the checkItem mapping, and re-ran but unfortunately no go. Also tried commenting out the password_header directive and then re-writing to a 0x. Unfortunately nothing there either... Here's the output:
rad_recv: Access-Request packet from host 10.160.111.240:21645, id=157, 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 = 0xa8e1592b181ffb4a0f3a8f64af1e44ce
EAP-Message = 0x02020007017431
NAS-Port-Type = Wireless-802.11
NAS-Port = 346
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 {NT}8846F7EAEE8FB117AD06BDD830B7586C in check items
rlm_ldap: looking for check items in directory...
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 password from '{NT}8846F7EAEE8FB117AD06BDD830B7586C' to '0x8846F7EAEE8FB117AD06BDD830B7586C'
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 157 to 10.160.111.240:21645
EAP-Message = 0x0103001211010008ddaad80eba0fa70f7431
Message-Authenticator = 0x
State = 0x6112db9db93531033550a056e58cc705
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=158, 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 = 0x65b02d0ba40c84e425ec499a85af14ae
EAP-Message = 0x0203002211010018c290a8dee74ac702f400bccd3228c58be7bfa5e957dcd8947431
NAS-Port-Type = Wireless-802.11
NAS-Port = 346
State = 0x6112db9db93531033550a056e58cc705
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 {NT}8846F7EAEE8FB117AD06BDD830B7586C in check items
rlm_ldap: looking for check items in directory...
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 password from '{NT}8846F7EAEE8FB117AD06BDD830B7586C' to '0x8846F7EAEE8FB117AD06BDD830B7586C'
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
