Hi all, I'm a little confused over what exactly the NISPLUS and NISPLUS_HOME support options actually mean. I'm hoping somebody can shed a little light on this. Our main samba server is a Solaris 2.7 machine (using NIS+ for passwords, etc, etc.) running samba 2.0.5a. I have recently been investigating a problem where, after a reboot of the server, various 3rd party products (POP, IMAP, CAP, SAMBA) are unable to authenticate a user until that user has telnetted in to the server. Anyway, that is just a little background. I wanted to find out exactly what decisions the configure script had made when I installed samba, so thought the easiest way to find this out was to run it again (this information doesn't seem to be easily found in the files that configure leaves behind.) Doing this, I discovered: checking whether to use NISPLUS password database... no checking whether to use NISPLUS_HOME... no ...which has confused me a little bit. Surely samba must be using the NIS+ password database otherwise it wouldn't be able to authenticate any users? So, I'd be most grateful if anyone could shed some light on these compilation options. Thanks Toby Blake Division of Informatics University of Edinburgh
Hi Toby,> I'm a little confused over what exactly the NISPLUS and NISPLUS_HOME > support options actually mean. I'm hoping somebody can shed a little > light on this. > > Our main samba server is a Solaris 2.7 machine (using NIS+ for > passwords, etc, etc.) running samba 2.0.5a. I have recently been > investigating a problem where, after a reboot of the server, various > 3rd party products (POP, IMAP, CAP, SAMBA) are unable to authenticate > a user until that user has telnetted in to the server.We also run in this problem. The application does not a 'keylogin' (getpublickey, getsecretkey, key_setsecret, ...) Solaris telnet does it, latest version wuftd also. For the qulacomm pop server, recompile with the SECURENISPLUS option. (this is also an exemple of what sould be changed in the code) I've not run in this problem with SAMBA, but our samba production server does not run Solaris 2.7 yet.> > Anyway, that is just a little background. I wanted to find out > exactly what decisions the configure script had made when I installed > samba, so thought the easiest way to find this out was to run it again > (this information doesn't seem to be easily found in the files that > configure leaves behind.) Doing this, I discovered: > > checking whether to use NISPLUS password database... no > checking whether to use NISPLUS_HOME... noMy understanding is that NISPLUS password database is using a nisplus table for the NT/LANMan ENCRYPTED passwd instead of the samba/private/smbpasswd file. This table is created/populated with the scripts samba-2.0.5a/source/script/mknissmbpasswd.sh samba-2.0.5a/source/script/mknissmbpwdtbl.sh> > ..which has confused me a little bit. Surely samba must be using the > NIS+ password database otherwise it wouldn't be able to authenticate > any users? > > So, I'd be most grateful if anyone could shed some light on these > compilation options. >Regards. Daniel. _ Daniel Grandjean, Swiss Federal Institute of Technology __ __ Address: EPFL SI-DGR, CH-1015 Lausanne, Switzerland | \/ | E-mail: Daniel.Grandjean@epfl.ch |o ()o _ Phone: +41 21 693 27 24 (Central European Time) |__/\__/ Fax: +41 21 693 27 27 WWW: http://dgrwww.epfl.ch \__/
Hi Daniel.> We also run in this problem. The application does not a 'keylogin' > (getpublickey, getsecretkey, key_setsecret, ...) > > Solaris telnet does it, latest version wuftd also. > > For the qulacomm pop server, recompile with the SECURENISPLUS > option. (this is also an exemple of what sould be changed in the > code) > > I've not run in this problem with SAMBA, but our samba production > server does not run Solaris 2.7 yet.Yes, this is what we've assumed. We've started investigating with Sun's own pop and imap daemons to see how they behave. Is anyone else running SAMBA under Solaris 2.7 and also seeing this problem? It would be nice to be able to compile keylogin support into samba.> My understanding is that > NISPLUS password database is using a nisplus table for > the NT/LANMan ENCRYPTED passwd instead of the samba/private/smbpasswd > file.OK, great. That does explain things - we're still using plain text passwords. The only reason for not moving to encrypted ones is the niggly problems with having two password tables. Cheers Toby