My goal is to use squid with ntlm_auth aginst samba4. i did this w/ samba 3.x and everything worked more than fine. Unfortunately I cannot make it work w/ samba 4. In my setup I have Samba4 running AD and is the only server in the network. It runs on a Fedora 11 box. AD seems to be ok - all windows machines in the domain are properly autheticating on the server (all user have no problems logining), but when i use squid all auths fail. Here is what I tried to debug the problem: wbinfo -p --- works - able to ping the winbindd wbinfo -u --- works and reports all users in the domain wbinfo -g --- works and reports all groups ntlm_auth --username=Administartor --- exits immediately w/ no message. I even tried to use a wrong password expecting an error message, but nothing was printed. As far as I know, in order to be able to authenticate, the ntlm_auth should return NT_STATUS_OK: Success (0x0). Anything elst will be treated as error and authentication will fail. BTW, the expected error when a wronf password is provided is: NT_STATUS_WRONG_PASSWORD: Wrong Password (0xc000006a)
Noboby willing to help???
Samba4's ntlm_auth needs to be glued into the auth subsystem. It is currently not connected to it, so does not talk to winbindd http://samba.sernet.de/irclog/2009/08/20090829-Sat.log has some clues as to what needs to be added.
Thansk Andrew, So not working yet. Any idea when it is supposed to be done? Even just a rough estimation?
There is no plan or timeframe for the completion of this feature. Volunteers are more than welcome to take on this task.
Question: Isn't it possible that you use s3's "ntlm_auth" against s4? I cannot guarantee that this works exactly now, but there is the wish to have s3 utilities also support the s4 server. Since we on the s4 side are a smaller project and focus more on the server, especially AD, we actually haven't the ressources to maintain those external tools. Therefore more and more we are trying to replace the s4 ones with those of s3 if they fit our needs ("smbclient" is an example). The big advantage of this is that we have afterwards only one up-to-date tool left to maintain on which both s3 and s4 people can work on.
(In reply to comment #5) > Question: Isn't it possible that you use s3's "ntlm_auth" against s4? I cannot > guarantee that this works exactly now, but there is the wish to have s3 > utilities also support the s4 server. Well, IF someone converted s3 ntlm_auth to use libwbclient calls instead of deep internal knowledge of s3 code to do it's job and IF libwbclient would work against the s4 winbind, then it could be possible to do parts of what ntlm_auth does against a s4 server. > Since we on the s4 side are a smaller project and focus more on the server, > especially AD, we actually haven't the ressources to maintain those external > tools. Therefore more and more we are trying to replace the s4 ones with those > of s3 if they fit our needs ("smbclient" is an example). The big advantage of > this is that we have afterwards only one up-to-date tool left to maintain on > which both s3 and s4 people can work on. I'm not sure if I particularly like this "let's go to the s3 scrapyard and see what we can use" attitude. I've seen this used against s3 development reusing technology from s4, interesting to see that this goes both ways. However, in the spirit of getting a Samba that will do both AD and file/print services, I think we should work on merging the utility programs as well. wbinfo was an easy first step, I think it makes sense to work on ntlm_auth next. Part of this is on my todo list, see bug #6677. However, ntlm_auth supports quite a number of modes of operation, some of them are easy to break and hard to test, bug #6563 comes to mind. So this is a significant amount of work, nothing you can hack together in 15 minutes to save ressources you'd rather spend on shiny features.
(In reply to comment #5 and #6) >> Question: Isn't it possible that you use s3's "ntlm_auth" against s4? I >>cannot >> guarantee that this works exactly now, but there is the wish to have s3 >> utilities also support the s4 server. >Well, IF someone converted s3 ntlm_auth to use libwbclient calls instead of >deep internal knowledge of s3 code to do it's job and IF libwbclient would work >against the s4 winbind, then it could be possible to do parts of what ntlm_auth >does against a s4 server. I tried ntlm_auth on a server with s3 installed in a s4 domain and it worked. I'm not 100% sure but it seems that is use libwbclient (at least it's linked against it). So it would mean that libwbclient is able to talk to s4 winbind. >> Since we on the s4 side are a smaller project and focus more on the server, >> especially AD, we actually haven't the ressources to maintain those external >> tools. Therefore more and more we are trying to replace the s4 ones with those >> of s3 if they fit our needs ("smbclient" is an example). The big advantage of >> this is that we have afterwards only one up-to-date tool left to maintain on >> which both s3 and s4 people can work on. >I'm not sure if I particularly like this "let's go to the s3 scrapyard and see >what we can use" attitude. I've seen this used against s3 development reusing >technology from s4, interesting to see that this goes both ways. Yeah you have to think that maybe on the host running samba 4 the user wants to use another program (ie. squid) that would need s4's ntlm_auth to do the NTLM verifications. >However, in the spirit of getting a Samba that will do both AD and file/print >services, I think we should work on merging the utility programs as well. >wbinfo was an easy first step, I think it makes sense to work on ntlm_auth >next. >Part of this is on my todo list, see bug #6677. However, ntlm_auth supports >quite a number of modes of operation, some of them are easy to break and hard >to test, bug #6563 comes to mind. So this is a significant amount of work, >nothing you can hack together in 15 minutes to save ressources you'd rather I pretty much agree with Kai on this we should try to merge the code when possible and it's maybe easier on small utilities (ie. ntlm_auth). I made a few tests with ntlm_auth, and it seems that just compiling s3's ntlm_auth in s4 (to use the other path for winbind's pipes) is working. I talked about this with Andrew B. and he was OK with the idea that s4's ntlm_auth should use almost the same code as in s3 but with the difference that it must also used gensec. So the result would be to mix the code of s3's ntlm_auth s4 to make ntlm_auth work and use gensec while sharing the code (or something similar).
(In reply to comment #7) > I tried ntlm_auth on a server with s3 installed in a s4 domain and it worked. > I'm not 100% sure but it seems that is use libwbclient (at least it's linked > against it). So it would mean that libwbclient is able to talk to s4 winbind. Not quite. If I understand you tried ntlm_auth from s3 on an s3 member server running an s3 winbindd, right? libwbclient never talks to a remore winbind server, it only ever talks to the local one. Parts of libwbclient already work against the s4 winbind, but not all of them. See bug #6652 for the current showstopper. > I made a few tests with ntlm_auth, and it seems that just compiling s3's > ntlm_auth in s4 (to use the other path for winbind's pipes) is working. I thought we're using the same pipe paths these days? I don't see how the wbinfo binary would work otherwise. > I talked about this with Andrew B. and he was OK with the idea that s4's > ntlm_auth should use almost the same code as in s3 but with the difference that > it must also used gensec. > So the result would be to mix the code of s3's ntlm_auth s4 to make ntlm_auth > work and use gensec while sharing the code (or something similar). Might be worth a look. :)
>> I tried ntlm_auth on a server with s3 installed in a s4 domain and it worked. >> I'm not 100% sure but it seems that is use libwbclient (at least it's linked >> against it). So it would mean that libwbclient is able to talk to s4 winbind. >Not quite. If I understand you tried ntlm_auth from s3 on an s3 member server >running an s3 winbindd, right? libwbclient never talks to a remore winbind >server, it only ever talks to the local one. Parts of libwbclient already work >against the s4 winbind, but not all of them. See bug #6652 for the current >showstopper. Right in fact I mixed 2 things, so yes a full S3 stuff in a s4 domain it's ok and also s3 ntlm_auth talk (at least partially) with a s4 winbind. >> I made a few tests with ntlm_auth, and it seems that just compiling s3's >> ntlm_auth in s4 (to use the other path for winbind's pipes) is working. >I thought we're using the same pipe paths these days? I don't see how the >wbinfo binary would work otherwise. No there was a bug about this that I fixed so winfo in s3 use /tmp/.winbind/pipe when s4 use PREFIX/var/run/winbindd/pipe (tunnable with ./configure ) ie an strace on wbinfo -u yield: fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 connect(3, {sa_family=AF_FILE, path="/usr/local/samba/var/run/winbindd/pipe"}, 110) = -1 ECONNREFUSED (Connection refused)
And how far evolved this one?
Didn't work on this, basically the ntlm_auth of s4 is more a stub to me than a really working program.
The ntlm_auth implementations are merging. The primary difference between then at this point is which gensec GSSAPI module is used by default, and the client-side code For NTLM and NTLMSSP authentication, the ntlm_auth3 version should work quite well.
Metze, abartlet, has there been any change here?