<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
I followed the directions in that link prior to emailing the group. For some reason, it still isn't working as expected.<br><br>If I put this line at the top of the users file, VPN users and Cisco exec users are able to authenticate with their AD account. <br><br>DEFAULT     Auth-Type = ntlm_auth<br><br>This is the debug output from a successful auth:<br><br>rad_recv: Access-Request packet from host w.x.y.z port 1645, id=33, length=86<br>
        User-Name = "mphillips"<br>
        User-Password = "xxxx"<br>
        NAS-Port = 1<br>
        NAS-Port-Id = "tty1"<br>
        NAS-Port-Type = Virtual<br>
        Calling-Station-Id = "w.x.y.z"<br>
        NAS-IP-Address = w.x.y.z<br>
+- entering group authorize {...}<br>
++[preprocess] returns ok<br>
[suffix] No '@' in User-Name = "mphillips", looking up realm NULL<br>
[suffix] No such realm "NULL"<br>
++[suffix] returns noop<br>
[eap] No EAP-Message, not doing EAP<br>
++[eap] returns noop<br>
[files] users: Matched entry DEFAULT at line 1<br>
++[files] returns ok<br>
++[expiration] returns noop<br>
++[logintime] returns noop<br>
Found Auth-Type = ntlm_auth<br>
+- entering group ntlm_auth {...}<br>
[ntlm_auth]     expand: --username=%{mschap:User-Name} -> --username=mphillips<br>
[ntlm_auth]     expand: --password=%{User-Password} -> --password=xxxx<br>
Exec-Program output: NT_STATUS_OK: Success (0x0)<br>
Exec-Program-Wait: plaintext: NT_STATUS_OK: Success (0x0)<br>
Exec-Program: returned: 0<br>
++[ntlm_auth] returns ok<br>
Login OK: [mphillips] (from client Access-Layer-Switch1 port 1 cli w.x.y.z)<br>
+- entering group post-auth {...}<br>
++[exec] returns noop<br>
Sending Access-Accept of id 33 to w.x.y.z port 1645<br>
Finished request 0.<br>
Going to the next request<br>
Waking up in 4.9 seconds.<br>
Cleaning up request 0 ID 33 with timestamp +16<br>
Ready to process requests.<br><br><br>Technically, this is all I need; this seems like a hacked way of doing things, though and I want to understand the operations of the server better. I commented out the pap and unix modules in ../sites-enabled/inner-tunnel and default and I also removed the DEFAULT line from the top of the users file. Now I get this debug output:<br><br><br>rad_recv: Access-Request packet from host w.x.y.z port 1645, id=34, length=86<br>        User-Name = "mphillips"<br>        User-Password = "xxxx"<br>        NAS-Port = 1<br>        NAS-Port-Id = "tty1"<br>        NAS-Port-Type = Virtual<br>        Calling-Station-Id = "w.x.y.z"<br>        NAS-IP-Address = w.x.y.z<br>+- entering group authorize {...}<br>++[preprocess] returns ok<br>[suffix] No '@' in User-Name = "mphillips", looking up realm NULL<br>[suffix] No such realm "NULL"<br>++[suffix] returns noop<br>[eap] No EAP-Message, not doing EAP<br>++[eap] returns noop<br>++[files] returns noop<br>++[expiration] returns noop<br>++[logintime] returns noop<br>No authenticate method (Auth-Type) configuration found for the request: Rejecting the user<br>Failed to authenticate the user.<br>Login incorrect: [mphillips/xxxx] (from client Access-Layer-Switch1 port 1 cli w.x.y.z)<br>Using Post-Auth-Type Reject<br>+- entering group REJECT {...}<br>[attr_filter.access_reject]     expand: %{User-Name} -> mphillips<br> attr_filter: Matched entry DEFAULT at line 11<br>++[attr_filter.access_reject] returns updated<br>Delaying reject of request 0 for 1 seconds<br>Going to the next request<br>Waking up in 0.9 seconds.<br>Sending delayed reject for request 0<br>Sending Access-Reject of id 34 to 10.200.1.4 port 1645<br>Waking up in 4.6 seconds.<br>Cleaning up request 0 ID 34 with timestamp +12<br>Ready to process requests.<br><br>Thanks for any assistance.<br><br>-Mike<br><br>> Date: Thu, 19 Nov 2009 22:30:50 +0000<br>> Subject: Re: need help authenticating against AD<br>> From: tnt@kalik.net<br>> To: freeradius-users@lists.freeradius.org<br>> <br>> > I need some help authenticating against AD. I have followed directions<br>> > online as best as I can, but things still aren't working as expected.<br>> <br>> These:<br>> <br>> http://deployingradius.com/documents/configuration/active_directory.html<br>> <br>> > I'm<br>> > ultimately hoping to have our VPN users and admins logging into Cisco<br>> > network equipment authenticate against AD through our FreeRADIUS 2<br>> > installation. Today, I have been testing authentication from one of Cisco<br>> > switches, and I continually receive this basic output:<br>> <br>> You are not authenticating against AD. You are authenticating against<br>> local system file:<br>> ...<br>> > Thu Nov 19 16:17:34 2009 : Info: ++[unix] returns updated<br>> ...<br>> > Thu Nov 19 16:17:34 2009 : Info: [pap] login attempt with password "xxxx"<br>> > Thu Nov 19 16:17:34 2009 : Info: [pap] Using CRYPT encryption.<br>> > Thu Nov 19 16:17:34 2009 : Info: [pap] Passwords don't match<br>> <br>> ... and the password isn't correct.<br>> <br>> > I can't tell from this output if the RADIUS server is ever even attempting<br>> > to reach AD.<br>> <br>> It isn't.<br>> <br>> > Obviously, if I enter the correct password for my username on<br>> > the RADIUS server itself, authentication will succeed, but this is not the<br>> > desired behavior at this time.<br>> <br>> Comment out unix in authorize then. If you follow the guide this will work<br>> with Auth-Type := ntlm_auth in users file.<br>> <br>> Ivan Kalik<br>> <br>> -<br>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html<br>                                      <br /><hr />Hotmail: Trusted email with Microsoft's powerful SPAM protection. <a href='http://clk.atdmt.com/GBL/go/177141664/direct/01/
http://clk.atdmt.com/GBL/go/177141664/direct/01/
' target='_new'>Sign up now.</a></body>
</html>