Trying to strip the Windows Domain name from a login

[Brett Littrell]

Hi All,
 
    I am trying to strip the domain name from a userid in the most efficient way possible, I am using version 2.1.1.  I have tried using the hints file with regular expressions.  
ex.
DEFAULT User-Name =~ "([A-Za-z1-9]+)"
        User-Name := "%{2}"
 
    In regexbuddy it is showing that it shows two matches, I specify the second match and in the debug output it fails and does not show any username.
 
    I then found another reference to strip the domain from the LDAP module as shown below:
       filter = "(cn=%{mschap:User-Name:-%{User-Name}}
#       filter = "(cn=%{Stripped-User-Name:-%{User-Name}})"
 
     I am using MSChapV2 and it seems to pass the correct username to the LDAP server it looks like there is some other place I need to strip the domain besides the ldap lookup, that or the replies are using the stripped name and it is failing that way as well.  Either way it still is not working.  If I un-comment the stripped-user-name and use a supplicant that strips the domain prior to sending it, it does work so Radius is working, just now with standard windows supplicant on XP.
 

Listening on accounting address * port 1813
Listening on proxy address * port 1814
Ready to process requests.
rad_recv: Access-Request packet from host 172.17.17.66port 1645, id=198, length=157
        User-Name = "LPDOT1XTEST\\dotxuser"
        Service-Type = Framed-User
        Framed-MTU = 1500
        Called-Station-Id = "00-1C-B1-5A-8E-05"
        Calling-Station-Id = "64-31-50-6E-DA-7A"
        EAP-Message = 0x0202001a014c50444f543158544553545c626c69747472656c6c
        Message-Authenticator = 0x7041a9eaea23f1896725936e06e3f1dc
        NAS-Port-Type = Ethernet
        NAS-Port = 50005
        NAS-IP-Address = 10.20.90.37
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = "LPDOT1XTEST\dotxuser", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] EAP packet type response id 2 length 26
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
++[unix] returns notfound
++[files] returns noop
[ldap] performing user authorization for LPDOT1XTEST\dotxuser
[ldap]  expand: (cn=%{mschap:User-Name:-%{User-Name}} -> (cn=dotxuser
[ldap]  expand: ou=users,o=musd -> ou=users,o=musd
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 172.17.17.1:636, authentication 0
rlm_ldap: setting TLS mode to 1
rlm_ldap: setting TLS CACert File to /etc/raddb/certs/rootder2.b64
rlm_ldap: bind as cn=ldproxy,ou=somecx,o=cx/password! to 172.17.17.1:636
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind was successful
rlm_ldap: performing search in ou=users,o=musd, with filter (cn=dotxuser
rlm_ldap: ldap_search() failed: Bad search filter: (cn=dotxuser
[ldap] search failed
rlm_ldap: ldap_release_conn: Release Id: 0
++[ldap] returns fail
Using Post-Auth-Type Reject
+- entering group REJECT {...}
[attr_filter.access_reject]     expand: %{User-Name} -> LPDOT1XTEST\dotxuser
 attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 0 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 0
Sending Access-Reject of id 198 to 172.17.17.66port 1645
Waking up in 4.9 seconds.
Cleaning up request 0 ID 198 with timestamp +20
Ready to process requests.
 
    An yes I am pretty new to freeradius.
 
 
Brett Littrell
Network Manager
MUSD
CISSP, CCSP, CCVP, MCNE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20110121/8d179857/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Brett Littrell.vcf
Type: application/octet-stream
Size: 325 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20110121/8d179857/attachment.obj>