Feeding an LDAP replyItem to an MS-CHAPv2 ntlm_auth request
Since this is my first post to this list, hello everyone. I do apologize if this question has been asked before; unfortunately I've been unable to find this information in the list archives. I have a working setup with Windows XP clients, MSAD, FreeRADIUS 1.1.0 running on SLES 10, and Enterasys switches. Authentication via PEAP and MS-CHAPv2. Everything works perfectly fine when a Windows user logs on; ldap module looks up the user, mschap authenticates, client is dropped into the right VLAN... beautiful. However, what I am also trying to achieve is to force the client into a specific VLAN when no user is logged on (this corresponds to the "Authenticate as computer when computer information is available" option in the "Authentication" tab of the Windows connection properties dialog). The tricky part is that XP's supplicant, which supplies the username as "DOMAIN\\Username" while a user is logged on, supplies a username in the form of "host/computername.my.domain" otherwise -- this corresponds to the servicePrincipalName attribute on the machine's object in MSAD. This is of course a format that ntlm_auth can't deal with. So, my approach is this: 1. When authorizing, look up the LDAP DN using a filter that checks both sAMAccountName and servicePrincipalName: radiusd.conf: modules { # [...] ldap { # [...] filter = "(|(sAMAccountName=%{Stripped-User-Name:-%{User-Name}})(servicePrincipalName=%{S tripped-User-Name:-%{User-Name}}))" # [...] } } } 2. While authorizing, retrieve the value of the sAMAccountName from LDAP. For this purpose, I have the following entry in the LDAP Attribute map: replyItem MSAD-SAM-Account-Name sAMAccountName 3. When authenticating, feed mschap's ntlm_auth the MSAD-SAM-Account-Name if it is available: modules { # [...] mschap { # [...] ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{MSAD-SAM-Account-Name:-%{Stripped-User-Name:-%{User-Name:-None}}} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}" # [...] } } }
From the debug logs, it appears such that the computer's LDAP object is looked up successfully (using the servicePrincipalName host/testpc.demo.com), and that the MSAD-SAM-Account-Name replyItem is set correctly (to "TESTPC$"). However, ntlm_auth is invoked with the username None instead, so it appears that the LDAP replyItems are not made available to the mschap authentication module.
rlm_ldap: performing search in dc=demo,dc=com, with filter (|(sAMAccountName=host/testpc.demo.com)(userPrincipalName=host/testpc.demo.com)( servicePrincipalName=host/testpc.demo.com)) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: Adding sAMAccountName as MSAD-SAM-Account-Name, value TESTPC$ & op=11 rlm_ldap: user host/testpc.demo.com authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 5 modcall: leaving group authorize (returns updated) for request 5 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 5 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 Processing the authenticate section of radiusd.conf modcall: entering group MS-CHAP for request 5 rlm_mschap: No User-Password configured. Cannot create LM-Password. rlm_mschap: No User-Password configured. Cannot create NT-Password. rlm_mschap: Told to do MS-CHAPv2 for host/testpc.demo.com with NT-Password radius_xlat: Running registered xlat function of module mschap for string 'Challenge' mschap2: e8 radius_xlat: Running registered xlat function of module mschap for string 'NT-Response' radius_xlat: '/usr/bin/ntlm_auth --request-nt-key --username=None --challenge=30585713439262e1 --nt-response=bbef10b2df1d9a084db75e86b02df137e7166eb6ce3e4d30' Exec-Program: /usr/bin/ntlm_auth --request-nt-key --username=None --challenge=30585713439262e1 --nt-response=bbef10b2df1d9a084db75e86b02df137e7166eb6ce3e4d30 Exec-Program output: Logon failure (0xc000006d) Exec-Program-Wait: plaintext: Logon failure (0xc000006d) ... and then subsequently, the whole request of course fails. I'm almost certain that I am missing something very obvious. Would someone be kind enough to enlighten me? Thanks very much. Florian -- Mag.(FH) Florian G. Haas | Systemingenieur Kapsch BusinessCom AG | Wienerbergstraße 53 | A-1120 Wien www.kapschbusiness.com | www.kapsch.net Firmenbuch HG Wien FN 178368g | Firmensitz Wien The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof.
Haas Florian wrote:
The tricky part is that XP's supplicant, which supplies the username as "DOMAIN\\Username" while a user is logged on, supplies a username in the form of "host/computername.my.domain" otherwise -- this corresponds to the servicePrincipalName attribute on the machine's object in MSAD. This is of course a format that ntlm_auth can't deal with.
Why not? There's a reason that the ntlm_auth configuration is editable in the mschap module. Just edit it to do whatever you want. If all else fails, replace ntlm_auth with a Perl script that looks at the environment variables, and determines the proper arguments to use. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hello.
Why not? There's a reason that the ntlm_auth configuration is editable in the mschap module. Just edit it to do whatever you want. If all else fails, replace ntlm_auth with a Perl script that looks at the environment variables, and determines the proper arguments to use.
Ahem. From my original message you may have read that your suggestion describes precisely what I am trying to implement, and that modifying the parameters passed to ntlm_auth is exactly my intention. I also understand that I could use a wrapper script or possibly do all sorts of things with %{exec:} and/or %{expr:}. I could also do some simple text mangling with the User-Name attribute as passed by the XP supplicant. However, the most elegant way of working around the servicePrincipalName that XP seems to provide when no user is logged on[1], would be to query MSAD for the corresponding sAMAccountName, and use that for NTLM authentication. I could write some Perl or Python or shell script that retrieves that information from MSAD, invoke that script via %{exec:}, and put its output in the ntlm_auth command arguments (or invoke it instead of ntlm_auth, for that matter). However, it seems sort of ridiculous to run an additional LDAP query for just that purpose, considering all the relevant information should already be available to FreeRADIUS at that point. So, to clarify my original question. What I want is this: 1. Put the value of an LDAP attribute (sAMAccountName) into a variable when the user is authorized in LDAP. 2. Access that variable when the user is being authenticated via MS-CHAPv2, and put it into the --username argument of ntlm_auth. I do understand that this would require registering said variable in dictionary and ldap.attrmap. I also understand that I need to set up a proper filter in the configuration of the ldap module, for correct authorization of the "user" that's being identified by it servicePrincipalName in this case. I have done all that. What else would I need, if what I'm trying to do is at all possible? Cheers, Florian [1] Yes, a rant about the XP supplicant providing "wrong" data in this case is in order, however that's not going to persuade my customer to switch to Ubuntu. :-) The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof.
Haas Florian wrote:
So, to clarify my original question. What I want is this:
1. Put the value of an LDAP attribute (sAMAccountName) into a variable when the user is authorized in LDAP. 2. Access that variable when the user is being authenticated via MS-CHAPv2, and put it into the --username argument of ntlm_auth.
I do understand that this would require registering said variable in dictionary and ldap.attrmap. I also understand that I need to set up a proper filter in the configuration of the ldap module, for correct authorization of the "user" that's being identified by it servicePrincipalName in this case. I have done all that. What else would I need, if what I'm trying to do is at all possible?
It sounds like that should work. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (2)
-
Alan DeKok -
Haas Florian