Re: Re: NIS with shadow passwords
Ciao Richard Cobbe, department's NIS server on a Solaris box upstairs. This works just fine with RH 6.2, so I'm guessing it'll be fine with potato, but confirmation before the install would be nice. Will that work? I don't know if this may be usefull, but here there is the following situation: SERVER RH with NIS+ CLIENT Debian 2.2 with NIS and it works. sure it would be mutch better if NIS+ could be found under Debian too. I'm not an expert, but outside the local network none can access in (I hope ;-) and inside none can sniff the net As soon as possible I will upgrade RH Server to Debian :-))) -- Paolo Pedaletti, Como, ITALYa www.fastflow.it/~paolop [EMAIL PROTECTED] ICQ: 4755831
NIS with shadow passwords
Hi. I have NIS installed and working good on my LAN. But I'd like to install shadow passwords as well. I've tried it, but as I compile the NIS maps, the users aren't no longer able to login :( Could somebody please help me? Thanks. -- Pedro Pereira [EMAIL PROTECTED] Linux do DEEC - FEUP
Re: NIS with shadow passwords
Pedro Pereira wrote: Hi. I have NIS installed and working good on my LAN. But I'd like to install shadow passwords as well. I've tried it, but as I compile the NIS maps, the users aren't no longer able to login :( Could somebody please help me? Thanks. use NIS+ ..i believe the NIS with linux does not support shadow. although i am not aware of a NIS+ solution that is debianized in stable. you can search the www for how to do NIS+ in linux but the process seems quite involved if your not using a supported distro like SuSE (since i think most of the NIS+ development is done by SuSE employees ..) i tried doing it with debian 2.0 ..and..ended up reinstalling because i hosed my libc bad. when i wanted a NIS server with shadow i decided on solaris 7(sparc) on an ultra 10 .. nate -- ::: ICQ: 75132336 http://www.aphroland.org/ http://www.linuxpowered.net/ [EMAIL PROTECTED]
Re: NIS with shadow passwords
Lo, on Thursday, January 25, Nate Amsden did write: Pedro Pereira wrote: Hi. I have NIS installed and working good on my LAN. But I'd like to install shadow passwords as well. I've tried it, but as I compile the NIS maps, the users aren't no longer able to login :( Could somebody please help me? Thanks. use NIS+ ..i believe the NIS with linux does not support shadow. although i am not aware of a NIS+ solution that is debianized in stable. Is this the NIS server, or the NIS client? I'm about to try installing potato on a machine at work, and I need to be able to work off our MIS department's NIS server on a Solaris box upstairs. This works just fine with RH 6.2, so I'm guessing it'll be fine with potato, but confirmation before the install would be nice. Will that work? Richard
Re: NIS with shadow passwords
Nate Amsden wrote: you can search the www for how to do NIS+ in linux but the process seems quite involved if your not using a supported distro like SuSE (since i think most of the NIS+ development is done by SuSE employees ..) i tried doing it with debian 2.0 ..and..ended up reinstalling because i hosed my libc bad. NIS+ support in general can be found at http://www.suse.de/~kukuk/nisplus/, but it's not an easy task to install (at least on RedHat it's not). You'll have to fiddle with the PAM entries a bit, to get thinks working properly. There is also a debianized version available at deb http://www.realbodo.de/ debian/ deb-src http://www.realbodo.de/ debian/ but I haven't played with that. Chances are, it works quite well out of the box. Good luck, Viktor -- Viktor Rosenfeld WWW: http://www.informatik.hu-berlin.de/~rosenfel/ Geek Code (3.1): GCS/SS d-@ s+: a20 C++@ UL++$ P+ L+++ E--- W++ N++ o? K? !W O? M? V? PS++@ PE+(-) Y+ P?(+++) t+ 5+ X- R? !tv b+ DI+ D- G e+++ h-- r- !y+
Re: NIS with shadow passwords
Richard Cobbe wrote: Lo, on Thursday, January 25, Nate Amsden did write: Pedro Pereira wrote: Hi. I have NIS installed and working good on my LAN. But I'd like to install shadow passwords as well. I've tried it, but as I compile the NIS maps, the users aren't no longer able to login :( Could somebody please help me? Thanks. use NIS+ ..i believe the NIS with linux does not support shadow. although i am not aware of a NIS+ solution that is debianized in stable. Is this the NIS server, or the NIS client? I'm about to try installing potato on a machine at work, and I need to be able to work off our MIS department's NIS server on a Solaris box upstairs. This works just fine with RH 6.2, so I'm guessing it'll be fine with potato, but confirmation before the install would be nice. Will that work? Richard I got this problem a moth ago, the error began when I tried to make the NIS maps. But I edited a Makefile turnig on some think about merging shadown files (I don't remember more and I don't have the system more). []'s -- _ Rodrigo Morais Araujo [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] _ Be Free! Use Linux.
Re: Linux nis and shadow passwords, non Linux clients
Next problem: The net nis master runs slink. A slink client works after shadow has been configured and + added to /etc/shadow. A client runs partly potato, and does not work, i.e. it won't accept nis passwords. NIS itself appears to work, i.e. I can see the right owners of directories, the homedirs are right, etc. Any known incompatibilities between glibc2.1 and shadow nis? glibc2.0 and nis: at least the expire field is not copied into the right structure. so you always get -1 when reading the shadow password fields. this happends only when you are useing the compat mode. if you are useing shadow: files nis it works ok. if you don't need the extra features of shadow (expiry, password age etc.), don't use it. many programs do not honor these fileds anyway (e.g. login.app). andreas
Linux nis and shadow passwords, non Linux clients
I recently switched our nis master server from AIX to linux. There are still a number of AIX hosts that should be run as nis clients or nis slaves. How do non shadow password clients get the password entries? How do I make it on AIX which doesn't have shadow passwords but a similar mechanism using /etc/security/passwd with a syntax linke this: root: password = mYfasd/89ßsx # this is not the right one of course lastupdate = 829567557 flag = nextuser: Next problem: The net nis master runs slink. A slink client works after shadow has been configured and + added to /etc/shadow. A client runs partly potato, and does not work, i.e. it won't accept nis passwords. NIS itself appears to work, i.e. I can see the right owners of directories, the homedirs are right, etc. Any known incompatibilities between glibc2.1 and shadow nis? Nils -- Plug-and-Play is really nice, unfortunately it only works 50% of the time. To be specific the Plug almost always works.--unknown source pgpXEJnRtee2r.pgp Description: PGP signature
Re: Linux nis and shadow passwords, non Linux clients
Again following up on my own posts, sigh: On Thu, Apr 22, 1999 at 03:22:58PM +0200, Nils Rennebarth wrote: Next problem: The net nis master runs slink. A slink client works after shadow has been configured and + added to /etc/shadow. A client runs partly potato, and does not work, i.e. it won't accept nis passwords. NIS itself appears to work, i.e. I can see the right owners of directories, the homedirs are right, etc. Any known incompatibilities between glibc2.1 and shadow nis? Hrmm, deinstalling nis and installing it again worked. This is getting Windows like, except that reboots are not necessary. What should I do however for clients that do not have shadow passwords? Is there a way to give them a made up password file with entries from real passwd and shadow mixed? (security reasons aside) Nils -- Plug-and-Play is really nice, unfortunately it only works 50% of the time. To be specific the Plug almost always works.--unknown source pgp46YKJiRKiD.pgp Description: PGP signature
Re: Linux nis and shadow passwords, non Linux clients
Hmmm, perhaps you'll have to generate your own intermediate passwd file to generate the NIS maps. However, I would perhaps reconsider using shadow. Unless you're only serving up some (not root, etc.) passwords from NIS and have set up NIS to work this way there's no benefit to running shadow locally since NIS is 100% insecure (ie. it'll give up password entries to anyone on your network who asks). Nils Rennebarth wrote: Again following up on my own posts, sigh: On Thu, Apr 22, 1999 at 03:22:58PM +0200, Nils Rennebarth wrote: Next problem: The net nis master runs slink. A slink client works after shadow has been configured and + added to /etc/shadow. A client runs partly potato, and does not work, i.e. it won't accept nis passwords. NIS itself appears to work, i.e. I can see the right owners of directories, the homedirs are right, etc. Any known incompatibilities between glibc2.1 and shadow nis? Hrmm, deinstalling nis and installing it again worked. This is getting Windows like, except that reboots are not necessary. What should I do however for clients that do not have shadow passwords? Is there a way to give them a made up password file with entries from real passwd and shadow mixed? (security reasons aside) Nils -- Plug-and-Play is really nice, unfortunately it only works 50% of the time. To be specific the Plug almost always works.--unknown source Part 1.2Type: application/pgp-signature -- Jens B. Jorgensen [EMAIL PROTECTED]
Re: Linux nis and shadow passwords, non Linux clients
In article [EMAIL PROTECTED], Jens B. Jorgensen [EMAIL PROTECTED] wrote: Hmmm, perhaps you'll have to generate your own intermediate passwd file to generate the NIS maps. Ah yes, a possibility is to include the password in /etc/password, and then filter that out again for shadow-capable hosts using /etc/ypserv.conf However, I would perhaps reconsider using shadow. Unless you're only serving up some (not root, etc.) passwords from NIS and have set up NIS to work this way there's no benefit to running shadow locally since NIS is 100% insecure (ie. it'll give up password entries to anyone on your network who asks). Not true. If set up correctly, it will only serve shadow maps to requests originating from secure ports (eg 1023), which means a root process. Ofcourse that means you do have to trust all root users on your network. But turning off shadow is certainly the easiest solution (shadowconfig off). You can still have shadow-like security using /etc/ypserv.conf, a feature unique to to the Linux NIS server. Mike. -- Indifference will certainly be the downfall of mankind, but who cares?
Re: Linux nis and shadow passwords, non Linux clients
Nils Rennebarth wrote:
On Thu, Apr 22, 1999 at 10:01:53AM -0500, Jens B. Jorgensen wrote:
Hmmm, perhaps you'll have to generate your own intermediate passwd file to
generate the NIS maps. However, I would perhaps reconsider using shadow.
Unless
you're only serving up some (not root, etc.) passwords from NIS and have
set up
NIS to work this way there's no benefit to running shadow locally since NIS
is
100% insecure (ie. it'll give up password entries to anyone on your network
who
asks).
What I'm worrying about is that a remote cracker guesses a local password
then logs in on our server and snatches the passwd file to crack the root
account (not that root has a password that I expect someone to crack, but
who knows..)
The way it runs currenty, a remote user has to crack a local root account,
to ask for the encrypted passwords.
And yes, I do only serve user passwords id 100 by NIS.
Understood. Actually, I do something similar: we use NIS behind the firewall
but the
firewall machine itself is an NIS client. In our situation things were a little
backwards though because we had a Sun serving up the NIS maps and linux boxen as
clients. The sun supports shadow but shadow maps are only served through NIS+.
Unfortunately, NIS+ support is just now coming together in Linux. This is all
academic though...
So, whatcha need to do is customize your /var/yp/Makefile which builds the
actual db
files. If you open up your /var/yp/Makefile you'll find something like (snipped
from
my own file):
passwd.byname: $(PASSWD) $(YPDIR)/Makefile
@echo Updating [EMAIL PROTECTED]
@$(UMASK); \
$(AWK) -F: '!/^[-+#]/ { if ($$1 != $$3 = $(MINUID) ) \
print $$1\t$$0 }' $(PASSWD) | $(DBLOAD) -i $(PASSWD) \
-o $(YPMAPDIR)/$@ - $@
[EMAIL PROTECTED](NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
passwd.byuid: $(PASSWD) $(YPDIR)/Makefile
@echo Updating [EMAIL PROTECTED]
@$(UMASK); \
$(AWK) -F: '!/^[-+#]/ { if ($$1 != $$3 = $(MINUID) ) \
print $$3\t$$0 }' $(PASSWD) | $(DBLOAD) -i $(PASSWD) \
-o $(YPMAPDIR)/$@ - $@
[EMAIL PROTECTED](NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
All we need to do is to pull the password field out of /etc/shadow and join it
together with the rest of the data in /etc/passwd before putting it into the db
file.
We can easily do this using the join command so we modify the the above to:
passwd.byname: $(PASSWD) $(SHADOW) $(YPDIR)/Makefile
@echo Updating [EMAIL PROTECTED]
@$(UMASK); \
/usr/bin/join -t : -j 1 -o 1.1 2.2 1.3 1.4 1.5 1.6 1.7 $(PASSWD)
$(SHADOW) |
\
$(AWK) -F: '!/^[-+#]/ { if ($$1 != $$3 = $(MINUID) ) \
print $$1\t$$0 }' | $(DBLOAD) -i $(PASSWD) \
-o $(YPMAPDIR)/$@ - $@
[EMAIL PROTECTED](NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
passwd.byuid: $(PASSWD) $(SHADOW) $(YPDIR)/Makefile
@echo Updating [EMAIL PROTECTED]
@$(UMASK); \
/usr/bin/join -t : -j 1 -o 1.1 2.2 1.3 1.4 1.5 1.6 1.7 $(PASSWD)
$(SHADOW) |
\
$(AWK) -F: '!/^[-+#]/ { if ($$1 != $$3 = $(MINUID) ) \
print $$3\t$$0 }' | $(DBLOAD) -i $(PASSWD) \
-o $(YPMAPDIR)/$@ - $@
[EMAIL PROTECTED](NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
I haven't tested the above (except for the join command itself) but I believe
it'll
do just exactly right.
--
Jens B. Jorgensen
[EMAIL PROTECTED]
