I read that you need to setup ntlm_auth to get Machine Authentication to work with Active Directory. How do I properly set up ntlm_auth to do this? Thanks, Scott Gilmour Software Engineer ENET, & ENSRT Enterasys Networks Phone: 978-684-1236 Email:sgilmour@enterasys.com <mailto:sgilmour@enterasys.com> www: http://www.enterasys.com <http://www.enterasys.com>
Gilmour, Scott wrote:
I read that you need to setup ntlm_auth to get Machine Authentication to work with Active Directory.
How do I properly set up ntlm_auth to do this?
Download Samba, ensuring it is 3.0.21rc1 or later which includes the patch Alan talks about. Compile and install samba. Read the samba documentation. Configure your Samba server. Ensure winbindd and nmbd are running. Join the AD domain. Ensure samba is working ("wbinfo -D DOMAIN", "wbinfo -a username%pass" are good basic tests) Install FreeRadius, make sure it is 1.1.0 which will strip the machine name "host/name.domain.com" to "name". Make the following changes to the default config: 1. radiusd.conf: uncomment the "ntlm_auth" line in the "mschap" module, adjusting the "/path/to/ntlm_auth" to a real value, and setting the --username argument to "%{mschap:User-Name}" 2. eap.conf: set "default_eap_type" to "peap", uncomment the "peap" section lower down, That's it.
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Download Samba, ensuring it is 3.0.21rc1 or later which includes the patch Alan talks about. Compile and install samba. Read the samba documentation. Configure your Samba server. Ensure winbindd and nmbd are running. Join the AD domain. Ensure samba is working ("wbinfo -D DOMAIN", "wbinfo -a username%pass" are good basic tests)
Install FreeRadius, make sure it is 1.1.0 which will strip the machine name "host/name.domain.com" to "name". Make the following changes to the default config:
Isn't that a whole heck of a lot of work? I took a look at the packet traces going to the domain controller. It turns out that about 4 packets are necessary. There's a libntlm that does the NTLM oddities, so all that needs to happen is for someone to write a minimal SMB client. The result would be a module like rlm_smb (which I can't make work anymore), but that replaces ntlm_auth, winbindd, and Samba. It would be small, fast, and a lot easier to use. It requires time/energy to do the work, but there is demand for it in a number of places. Alan DeKok.
Alan DeKok wrote:
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Download Samba, ensuring it is 3.0.21rc1 or later which includes the patch Alan talks about. Compile and install samba. Read the samba documentation. Configure your Samba server. Ensure winbindd and nmbd are running. Join the AD domain. Ensure samba is working ("wbinfo -D DOMAIN", "wbinfo -a username%pass" are good basic tests)
Install FreeRadius, make sure it is 1.1.0 which will strip the machine name "host/name.domain.com" to "name". Make the following changes to the default config:
Isn't that a whole heck of a lot of work?
Indeed
I took a look at the packet traces going to the domain controller. It turns out that about 4 packets are necessary. There's a libntlm that does the NTLM oddities, so all that needs to happen is for someone to write a minimal SMB client.
Isn't libntlm client-side NTLM? As far as I know, to execute the required RPCs you need a machine account and thus at minimum must have a local secret store and support for the RPCs to join a domain (can be in a binary helper app), change the machine password (ditto executed from cron) and execute the basic netlogon stuff. Sadly, Microsoft being Microsoft, there's a surprisingly large amount to do for this to work reliably. With latter versions of windows, 2k3 in particular, the amount of support required for even basic netlogon RPCs is large, as they've upped the security ante. rlm_smb seems to be just for validating plaintext passwords. With the older MS-CHAPv1 you could do something to just proxy the challenge and response to any SMB server, but that server (and the supporting domain) would have to have a lot of options that are turned off by default for security reasons these days. NTLMv2 and MS-CHAPv2 were designed as you know to eliminate that MITM potential. But I can see what you're saying and agree - it's awfully heavyweight for basic users. Perhaps we could invert the problem - a small, easily auditable binary compiled for win32 that listens on a TCP port, uses some lightweight method to secure connections (maybe SRP?) and acts as an ultra-lightweight proxy for the required RPCs? Sites that want to can just run it as a service on the PDC or any member server. Sites large enough to forbid this are likely large enough to put the effort into running Samba. (I could actually see this being preferable to rlm_ldap for some cases if you permit a few other RPCs on the wire)
The result would be a module like rlm_smb (which I can't make work anymore), but that replaces ntlm_auth, winbindd, and Samba. It would be small, fast, and a lot easier to use.
It requires time/energy to do the work, but there is demand for it in a number of places.
Indeed. Sadly my own experience of SMB protocols leads me to believe that anything less than Samba is likely to cause even more problems. It at least has the advantage of lots of expertise interoperating with years of diverse protocol options, the more modern of which can be arcane to say the lease. It may be worth asking the guys on the samba-technical list if they have any suggestions.
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Isn't libntlm client-side NTLM?
It validates NTLM requests, and uses username/passwd to generate NTLM requests to send to a server.
As far as I know, to execute the required RPCs you need a machine account
Which Samba doesn't do. Remember, Samba still only does NT4-style authentication for NTLM. As I've said, I've watched it with tcpdump. 4 packets isn't a lot.
With latter versions of windows, 2k3 in particular, the amount of support required for even basic netlogon RPCs is large, as they've upped the security ante.
So you avoid it by doing NT4 authentications.
Perhaps we could invert the problem - a small, easily auditable binary compiled for win32 that listens on a TCP port, uses some lightweight method to secure connections (maybe SRP?) and acts as an ultra-lightweight proxy for the required RPCs? Sites that want to can just run it as a service on the PDC or any member server. Sites large enough to forbid this are likely large enough to put the effort into running Samba.
Sure. But why do all that when you can just run a RADIUS server on the box? If FreeRADIUS had a "native" windows authentication module, then most of these issues could be avoided by running a full RADIUS remotely, and a small radius on the Windows box. Alan DeKok.
Alan DeKok wrote:
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Isn't libntlm client-side NTLM?
It validates NTLM requests, and uses username/passwd to generate NTLM requests to send to a server.
Ok, different libntlm then. Have you got the URL handy?
As far as I know, to execute the required RPCs you need a machine account
Which Samba doesn't do. Remember, Samba still only does NT4-style
I don't know what you mean by this. Samba can act as both a client and (member) server for win2k/win2k3 authentication methods (GSS-SPNEGO primarily) using machine account credentials acquired using that domains native protocols (kerberos+LDAP). It can't be a domain controller for those protocols, but that does not seem to be relevant to the discussion? I'm sure we're talking about different things. The point I am (badly) trying to communicate is that, with a microsoft domain controller (NT4, win2k, win2k3), to execute the RPC call required to validate an MS-CHAPv2 request and return the NT key you MUST have a machine account in the domain and you MUST be able to generate an appropriately formatted, secured and encrypted netlogon sam_network_logon call. The code for this is non-trivial, and since the user would have to configure and join the domain, and maintain the machine account credentials anyway, I'm not sure in reality it's much easier than installing samba.
authentication for NTLM. As I've said, I've watched it with tcpdump. 4 packets isn't a lot.
It's 4 packets for me too, but TCP segments on an already-open MSRPC pipe to a domain controller. The SMB packets are SMB-signed/sealed, the contents are a Netlogon SCHANNEL RPC which is itself further signed and sealed, and the variety and number of versions of a call and versions of structures passed as arguments are truly, truly bewildering. Don't get me wrong, I'm not saying it's not doable or not a good idea, I just have a feeling it would be a lot of work having lurked around the samba-technical mailing list for a few years and spent more than a few hours debugging various issues.
With latter versions of windows, 2k3 in particular, the amount of support required for even basic netlogon RPCs is large, as they've upped the security ante.
So you avoid it by doing NT4 authentications.
I'm not sure what you mean by "NT4" authentications. There are many dialects of the various RPC protocols and channels, none particularly simple (by my measure at any rate). I'm not sure there are any non-MSRPC ways to check an MS-CHAPv2 request -
Perhaps we could invert the problem - a small, easily auditable binary compiled for win32 that listens on a TCP port, uses some lightweight method to secure connections (maybe SRP?) and acts as an ultra-lightweight proxy for the required RPCs? Sites that want to can just run it as a service on the PDC or any member server. Sites large enough to forbid this are likely large enough to put the effort into running Samba.
Sure. But why do all that when you can just run a RADIUS server on the box?
If FreeRADIUS had a "native" windows authentication module, then most of these issues could be avoided by running a full RADIUS remotely, and a small radius on the Windows box.
Interesting - I didn't realise FR compiled there (I guess it does under cygwin but TBH you've not got great access to the relevant APIs there).
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Ok, different libntlm then. Have you got the URL handy?
I don't know what you mean by this. Samba can act as both a client and (member) server for win2k/win2k3 authentication methods (GSS-SPNEGO primarily) using machine account credentials acquired using that domains native protocols (kerberos+LDAP).
You keep saying "machine authentication". I'm talking about authenticating users. I did this using Samba & smbclient. There were 4 packets. Most of the packet content was NTLM stuff. There was no extra RPC nonsense, like is done with a normal XP login to a DC.
The point I am (badly) trying to communicate is that, with a microsoft domain controller (NT4, win2k, win2k3), to execute the RPC call required to validate an MS-CHAPv2 request and return the NT key you MUST have a machine account in the domain
For user authentication? I don't think so.
It's 4 packets for me too, but TCP segments on an already-open MSRPC pipe to a domain controller.
Uh, no. Try using smbclient to grab a list of shares from a domain controller. It's 4 packets to authenticate the user, start to finish. The rest of the traffic is the "get list of shares" stuff. And those packets happen after the authentication.
The SMB packets are SMB-signed/sealed, the contents are a Netlogon SCHANNEL RPC which is itself further signed and sealed, and the variety and number of versions of a call and versions of structures passed as arguments are truly, truly bewildering.
Yes. I've spent time looking at those RPC's, they're truly horrid. But... I can't argue with success. smbclient does NTLM authentication in 4 packets. Why can't we? I understand the whole complexity and RPC nonsense, but forgive me if I'm stuck on a working example. Try it. Start tcpdump listening on packets from your machine to a domain controller. Verify that there are no packets going to the DC. Run smbclient to get the list of shares. Look at how many packets go back and forth. Then, tell me it's a huge amount of work to replicate that traffic, because there are endless other RPC's that have to be done. I just don't believe it. And I don't understand why you think it's so complicated to reproduce that traffic. I *think* you're talking about reproducing an entirely different kind of traffic, with a lot more packets. I've spent time looking at the Windows AD RPC's. In order to do a full XP-style login, there are nearly billions of packets you have to send back and forth. There are CLDAP packets, RPC packets, and multiple kinds of crap inside of the RPC's. But smbclient doesn't do any of that. And it's very successful doing NTLM against a domain controller, where that domain controller refuses to allow rlm_smb to work. The point here is that smbclient is *not* doing a full XP-style login. That would be truly a large amount of work. Instead, smbclient is doing something much simpler. Again, try it. Then, explain why we need to do more to get the same result of authenticating the user. Alan DeKok.
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
You seem convinced I'm operating from a state of ignorance. I'm quite willing to believe I'm wrong. Best of luck.
Let me retry. Machine authentication is something "new" in post NT4 domain controllers. As such, to do it properly, the client is required to implement massive amounts of RPC nonsense. User authentication is another story. The smbclient program can be used to demonstrate that users can be authenticated to a DC using NTLM, with a minimum number of packets, because it uses an older version of the protocol. It's not that I think you're operating from a state of ignorance. It's that I think you're focussing on the wrong thing. The huge XP-style RPC stuff cannot be implemented in a small client, so I ignore it. The much smaller older protocol used by smbclient is demonstratably implemented in a small client: smbclient. There's no winbindd, smbd, or any other daemons required. Alan DeKok.
--- Alan DeKok <aland@ox.org> wrote:
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Ok, different libntlm then. Have you got the URL handy?
I don't know what you mean by this. Samba can act as both a client and (member) server for win2k/win2k3 authentication methods (GSS-SPNEGO primarily) using machine account credentials acquired using that domains native protocols (kerberos+LDAP).
You keep saying "machine authentication". I'm talking about authenticating users.
I did this using Samba & smbclient. There were 4 packets. Most of the packet content was NTLM stuff. There was no extra RPC nonsense, like is done with a normal XP login to a DC.
The point I am (badly) trying to communicate is that, with a microsoft domain controller (NT4, win2k, win2k3), to execute the RPC call required to validate an MS-CHAPv2 request and return the NT key you MUST have a machine account in the domain
For user authentication? I don't think so.
It's 4 packets for me too, but TCP segments on an already-open MSRPC pipe to a domain controller.
Uh, no. Try using smbclient to grab a list of shares from a domain controller. It's 4 packets to authenticate the user, start to finish. The rest of the traffic is the "get list of shares" stuff. And those packets happen after the authentication.
The SMB packets are SMB-signed/sealed, the contents are a Netlogon SCHANNEL RPC which is itself further signed and sealed, and the variety and number of versions of a call and versions of structures passed as arguments are truly, truly bewildering.
Yes. I've spent time looking at those RPC's, they're truly horrid.
But... I can't argue with success. smbclient does NTLM authentication in 4 packets. Why can't we?
I understand the whole complexity and RPC nonsense, but forgive me if I'm stuck on a working example.
Try it. Start tcpdump listening on packets from your machine to a domain controller. Verify that there are no packets going to the DC. Run smbclient to get the list of shares. Look at how many packets go back and forth. Then, tell me it's a huge amount of work to replicate that traffic, because there are endless other RPC's that have to be done.
I just don't believe it. And I don't understand why you think it's so complicated to reproduce that traffic. I *think* you're talking about reproducing an entirely different kind of traffic, with a lot more packets.
I've spent time looking at the Windows AD RPC's. In order to do a full XP-style login, there are nearly billions of packets you have to send back and forth. There are CLDAP packets, RPC packets, and multiple kinds of crap inside of the RPC's. But smbclient doesn't do any of that. And it's very successful doing NTLM against a domain controller, where that domain controller refuses to allow rlm_smb to work.
The point here is that smbclient is *not* doing a full XP-style login. That would be truly a large amount of work. Instead, smbclient is doing something much simpler.
Again, try it. Then, explain why we need to do more to get the same result of authenticating the user.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
NTLM is sufficient to gain access to resources on Windows domain, "machine account" or no, in ANY windows domain flavor. To wit: I access shares and printers on work systems from home, via vpn, by mapping a drive and specifying a different username/password than my home system login in the process. To let our work DC (mixed-mode W2K3 AD) know who I am (from its perspecitve) I qualify my credentials with my work domain. Thus, user: WORKDOMAIN\username password: <domain_password> My home PCs are not "work" domain members. In fact, I run my own "home" domain. So these home systems actually have different native security (machine account) credentials than my work PC. A machine account is required (and only available to NT-branch OSes, i.e., not 95, 98, ME) to allow the domain controller to administer the security of the "workstation". Things like group policy, (workstation-level) registry and share management, etc necessitate a machine account. Laker __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Laker Netman <laker_netman@yahoo.com> wrote:
NTLM is sufficient to gain access to resources on Windows domain, "machine account" or no, in ANY windows domain flavor.
Yes, but the issue is the protocol that encapsulates NTLM. There are multiple versions of Windows "connect to DC" protocols. Some require massive amounts of code to obtain a working implementation. Others (e.g. rlm_smb) do not.
My home PCs are not "work" domain members. In fact, I run my own "home" domain. So these home systems actually have different native security (machine account) credentials than my work PC.
And until you look at the packet traces, you have no idea which version of what protocols they're using. Odds are they're using the Win2K or XP-style "infinite number of packets" method to log into the DC. Alan DeKok.
participants (5)
-
Alan DeKok -
André Lemos -
Gilmour, Scott -
Laker Netman -
Phil Mayers