Question: What is causing the password to be encrypted? It is not the password entered. radtest bradbrookc putz041277! localhost 0 xxxxxxx rad_recv: Access-Request packet from host 127.0.0.1:32806, id=152, length=62 User-Name = "bradbrookc" User-Password = "\t\354B\252\355\345BI\237\034\217\316\315\363\351\271" NAS-IP-Address = 255.255.255.255 NAS-Port = 0 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 rlm_realm: No '@' in User-Name = "bradbrookc", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 users: Matched entry DEFAULT at line 152 users: Matched entry bradbrookc at line 218 modcall[authorize]: module "files" returns ok for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for bradbrookc radius_xlat: '(&(SamAccountName=bradbrookc))' radius_xlat: 'ou=xxxxx,dc=xxx,dc=xxx,dc=xxx' 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 cnsxxxxxxxxx:389, authentication 0 rlm_ldap: bind as xxxxxx/xxxxxx to cnsxxxxx:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in ou=xxxx,dc=xx,dc=xxxx,dc=xxx, with filter (&(SamAccountName=bradbrookc)) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user bradbrookc authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type LDAP auth: type "LDAP" Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 0 rlm_ldap: - authenticate rlm_ldap: login attempt by "bradbrookc" with password "?ìBªíåBI???ÎÍóé¹" rlm_ldap: user DN: CN=xxxxxx\, xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx,DC=xxx rlm_ldap: (re)connect to cnsad.ads.nint.org:389, authentication 1 rlm_ldap: bind as CN=xxxx\, xxxx,OU=xxx,OU=xxx,DC=xxxx,DC=xxx,DC=org/ ?ìBªíåBI???ÎÍóé¹ to cnsxxxxx:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind failed with invalid credentials modcall[authenticate]: module "ldap" returns reject for request 0 modcall: group Auth-Type returns reject for request 0 auth: Failed to validate the user. Login incorrect (rlm_ldap: Bind as user failed): [bradbrookc] (from client localhost port 0) WARNING: Unprintable characters in the password. ? Double-check the shared secret on the server and the NAS! Delaying request 0 for 1 seconds Finished request 0 Going to the next request --- Walking the entire request list --- OS:Fedora Core 5 FreeRadius 1.0.5-1.2 Help would be great, I have been attempting different combination with no luck. thx
"Charlie B" <cbwonderboy@gmail.com> wrote:
Question: What is causing the password to be encrypted? It is not the password entered.
Read the debug output:
WARNING: Unprintable characters in the password. ? Double-check the shared secret on the server and the NAS!
Alan DeKok.
Thanks for the reply, I have checked the shared secret, and earlier in the debug you can see that it binds successfully. After which it attempt to authenticate the user with the credientials provided and fails, the only thing I can see is that it is changing the password provided into garbage and sending this to Active directory which is turing around and saying incorrect password. In all the examples I can find on the password sent is in clear test, so then why in my example is it encrypted? How do I undo this? On 7/20/06, Alan DeKok <aland@nitros9.org> wrote:
"Charlie B" <cbwonderboy@gmail.com> wrote:
Question: What is causing the password to be encrypted? It is not the password entered.
Read the debug output:
WARNING: Unprintable characters in the password. ? Double-check the shared secret on the server and the NAS!
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
"Charlie B" <cbwonderboy@gmail.com> wrote:
I have checked the shared secret, and earlier in the debug you can see that it binds successfully.
To LDAP? That doesn't matter. The shared secret isn't used there.
After which it attempt to authenticate the user with the credientials provided and fails, the only thing I can see is that it is changing the password provided into garbage
Because, as the message says, the shared secret is wrong.
In all the examples I can find on the password sent is in clear test, so then why in my example is it encrypted?
Because the shared secret is wrong.
How do I undo this?
Use the correct shared secret. I fail to understand why you're arguing when you could just go fix the shared secret, and prove to yourself that fixing it solves the problem. Alan DeKok.
Sorry Alan, didn't mean to be antagonistic. Your were dead on about the solution. thx
participants (2)
-
Alan DeKok -
Charlie B