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
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]
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
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
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
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
