ntlm_auth and Server 2008 R2 (or, how to select a group for a proxied request)

[Alan DeKok]

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.