Oops.. I was probably thinking of a different forum.. here's the link to the overview of NIS I put together:
http://www.ntlug.org/~ccox/ntlug_nis/index.htm

If you are not seeing encrypted paswords, it is likely you may be trying to push a shadow map (not standard and not recognized by most NIS implementations). You can see the maps you are pushing with "ypwhich -m".

Usually a join is done between the source /etc/passwd (assuming /etc is your source base) and /etc/shadow to put the encrypted passwords into the resulting passwd map db file. That joining program might be called many differnent things... on Linux it is called yphelper and sits in /usr/lib/yp. It is possibly to write one pretty easily in shell if you have to. Alternatively, some Linux dists include pwunconv which will join the encrypted passwords from /etc/shadow into an old-style passwd file (which in turn could be used as the source for the NIS password map).

I'd take a look at your /var/yp/Makefile and see what it is doing to generate the passwd maps... it might show you what needs to be set to prevent the pushing of the shadow map and use the portable (and less secure) format.

Hope this helps,
Chris

Wow, I really liked that tutorial. Nice job. Unfortunately, I couldn't use it to solve my situation. Just to reiterate: The Client (FC3) can ypbind to the domain fine, and I can even see the passwd from the NIS Server (BSD) with no problem. So to me, I've got pretty much everything set up correctly. I've installed the basic telnet server on the client (FC3), but when I go to log in, it only accecpts the accounts that are local to the client (FC3). I have looked at my /var/log/messages and when I go to log in with my test NIS account (yptest), it just comes back and says "Login Incorrect"

Output for /var/log/messages
----------------------------------------------------
Feb 25 10:07:53 kitty remote(pam_unix)[16949]: authentication failure; logname= uid=0 euid=0 tty=pts/4 ruser= rhost=kitty user=yptest
Feb 25 10:07:55 kitty login[16949]: FAILED LOGIN 1 FROM kitty FOR yptest, Authentication failure



I hate this... cause it makes no sense and because I'm a at NIS stuff

A SUSE due wrote the NIS stuff.. so I'll admit, it does seem to work better there. But I haven't tried to set it all up with FC3... so maybe I'm talking without knowledge. The /var/yp/Makefile, ideally, will just do the right thing with regards to merging... but you do have to somehow let it know (edit it) about what maps you are pushing and not pushing... and that might get a bit beyond a newbie.

I know it's not a consolation... but I can assure you that the commercial Unix boys make this mess even worse... SUSE (and presumably other dists) have put a lot more thought into making this easier to do... though not completely newbie compliant.

Do you have a local LUG? I know our LUG will allow you to get live troubleshooting. Often needed.... hard to communicate EVERYTHING via mail/forums.

To all,

I had originally typed a reply to this thread, but by pressing the wrong button I had lost everything. So here it is a second time around.

I ran into the same situation with FC2 client and a FreeBSD 4.10-release server running NIS, and I am pleased to report that I have a working solution - albeit an interesting one:

If you do a "man 5 login.conf" on the FreeBSD box, you will read about a field called "passwd_format". The directions for that field suggest that you configure this field to "des" if you want to serve non-FreeBSD clients. I had previously set it on "blf", then realized that FC2 probably can't see Blowfish hash; then set it on MD5 thinking that FC2 *should* be able to see it, and yet it still didn't.

So what I did was to set the field to "des", and then did a "cap_mkdb /etc/login.conf" on the BSD box. I then manually reset all the passwords that I will need to serve over NIS (not really changing them, just typing them in again using the "passwd" command), copied the master.passwd to /var/yp, then re-did "ypinit" on the BSD box (because I was really paranoid and frankly tired of dealing with this problem ;-)) to push out the new passwd file. I went over to my FC2 box and verified that it was seeing the new hash by doing a "ypcat passwd", and sure enough, I am now seeing the new hash without the "$2$" prefix (the Blowfish label) or the "$1$" prefix (the MD5 label). The DES hash is 13 characters long with upper- and lower-case and numbers.

I then went through what you guys had talked about throughout the thread:

* +::::: for passwd file (FC2)
* nis option set in nsswitch.conf for passwd, shadow, group (FC2)
* +::: for /etc/group (FC2)
* verified correct information in /etc/yp.conf (FC2)
* used authconfig to remove MD5 support on client (FC2)
* used the "UNSECURE=TRUE" option in /var/yp/Makefile; the directions suggest using this option when serving NIS to non-FreeBSD clients (BSD)
* verified running BIND 9 DNS server (BSD)
* verified running NIS server (BSD)

After reboots, I was able to log in using my NIS credentials with no problems at all. I had also set up /home on the client to connect to the BSD box via NFS, and I found that simply copying pre-existing config files from the FC2 /home to the BSD /home won't work for some reason. DCOP on FC2 kept screaming something about the DCOP server not running or having failed (I am not as fluent on FC2 or Linux as I am on BSD), so I wiped everything away on the /home share, created a brand-new directory for the credential, and logged in again. This time FC2 was able to create everything from scratch, and I have not had a problem since. KDE is also up and running beautifully.

Bottom line: Apparently the common denominator between FC2 and BSD is DES, when speaking of encryption algorithms. By changing the BSD box to hash its passwords using DES, the FC2 is able to read that information through NIS and allow authentication with no problems.

I wrote all this during the early hours of the day (i.e. 4-5 AM), so if I am missing anything (or if you have any question) please let me know.

gr1d

I'll give this a shot, this sounds like it might be the key. Thank for the details, I'll keep you posted!