Meyers, Dan wrote:
This worked fine, right up until we upgraded our domain controllers to Windows Server 2008 R2. Suddenly, ntlm_auth stopped talking to the DC. The message we were getting back when we tried to auth (either via radius or on the command line with a simple ntlm_auth --username=<username> and then specifying the password at the prompt) was NT_STATUS_PIPE_DISCONNECTED: Named pipe dicconnected (0xc00000b0). wbinfo -u successfully gets a list of every user the DCs know about, so we can still talk to them (This is on Samba 3.4.0, the latest on Ubuntu Server 9.10).
This is an issue for the Samba list. If Samba can't talk to AD, there's very little you can do to FreeRADIUS to fix it.
The problem now, is that our authorize section in our inner-tunnel (used when there is a PEAP connection) used the sql module to extract group information from the user group table of the radius postgres database. Thus we could return a radius key:value pair that would dump a user into a group based on the returned result of the group_membership_query. As we are now proxying the request instead of doing authorize ourselves, this query is not getting run and every single user is ending up in the default group. 'sql' as a module can't go into post-proxy, so i'm unsure how to get this query to be run once the Windows server has returned OK for a request. The Windows RADIUS server does not seem to have enough functionality to get the group information we require.
Yup. It's a pretty bad product.
So, I either need to work out what to do to ntlm_auth to make it play nicely with Server 2008 R2 domain controllers for user verification, or I need to work out how to get FreeRADIUS to do the group sql query and add the relevant pairs before returning the result to the client after it has got an Access-Accept from the Windows RADIUS server for the request it proxied there. Has anyone got any experience of either of these things?
Why not just do group checking via LDAP? Active Directory implements that part of LDAP correctly. Alan DeKok.