UNIX Machines that don't use /etc/passwd 16
A Nameless Submmitor had this question to bring before you all: "I've heard of and had access to several machines that don't use passwd/shadow files or even wtmp for user logging/authentication, but instead use Oracle databases, or other methods. My question is, what's the story on this approach, what are the pros/cons, and is there anything out there for Linux that is similar?" There are SEVERAL options of this available for Linux, but just what do you all think
about using a database for user authentication?
Are databases secure? (Score:1)
Just curious....
PAM is your friend here (Score:1)
Actually, I just realized another problem with a database and no
Woops, I just realized another possibility - plug it in like NIS or NIS+ plug in. Run a fake ypbind that really talks to your database instead of NIS.
In theory the database should be at least as secure as
I see two potential disadvantages with the database system. One is, of course, the overhead imposed by running queries into it for authentication, but it probably wouldn't be noticable unless on an ancient, slow, loaded system. The other is that if any program is allowed to query things such as passwords, it makes it much easier to brute-force passwords unless the database slows access on password querries. The database dosen't need to allow a user to query any password but the user's own, but even then,
Actually, after typing all this I realized that NIS and NIS+ are really just databases that take the place of
Disclaimer: I'm tired, so this post may contain various sundry weirdness or inaccuracies. Check your manpages before doing anything rash.
Using a database... (Score:1)
1) No
2) No local password files to crack if you can break root on that machine (See point 1).
3) Central management of passwords.
4) Passwords probably don't use the same encryption scheme. Security through obscurity.
Cons:
1) If the password server is down, no one--NO ONE--could get in. (Could get around this, depending on how they have it setup)
2) Non-standard password setups, so new admins must be trained in their security model. (They might consider that an advantage)
3) More complex setup when installing a new box.
With Linux, you can use NIS, LDAP, and several others to do the same thing. For a large system, it might not be too bad of an idea.
Some various forms of non-/etc/passwd logins (Score:1)
Overall, they're nice for some things, but also sometimes a PITA. As a sysadmin, I like being able to add users manually using vi, and I've had some unpleasant experiences with NetInfo (and NIS is insecure compared to
Of course, I'm not too experienced with NetInfo, NIS, or Kerberos. So YMMV, but rest assured that the inconveniences of dealing with a particular database authentication system pay for themselves with the convenience of managing large sites with a database in general.
Speed is the pro (Score:1)
Re:Using a database... (Score:1)
And actually, it is a much simpler setup when installing a box, because you dont have to do passwd/shadow/group mirroring, which can be quite a bitch and can open up security holes...
Re:Speed is the pro (Score:1)
NSS (Score:1)
NSS allows you to specify the source for system databases, such as the passwd database. From info libc: Writing and using self-written NSS modules is easy. Look at www.padl.com [padl.com] who offer a NSS module for LDAP integration.
--
OS lover
PAM and Kerb (Score:1)
kerberos (Score:1)
After authenticating a user logging in, it inserts a placeholder line in /etc/passwd (with the password field as *); this /etc/passwd gets reset when the machine restarts.
alternate passwd databases (Score:1)
Sun's NIS/NIS+ is, essentially, a database being queried for user and network information, queried instead of
1. secure
2. got fine-grain access control on db objects
3. doesn't conflict with dns (as I have heard nis does unless you configure it properly)
4. allows sharing of basic network/user information for a large number of hosts.
5. The client is easy to set up on solaris.
It's bad because:
1. The admintools and db schema can be very difficult to learn.
2. The server is a pain to set up.
3. The server only runs on solaris.
4. The clients can be a bit difficult to set up on linux, because you usually have to rebuild glibc and reconfigure PAM.
I am looking for a better solution to use on my network right now. I'm managing a departmental network of 8 sun/solaris boxen and 6 intel/linux boxen, using a sun as the nis+ domain controller. We are slowly migrating to using only linux machines as the suns get old, and I'd like to find a server that runs under linux. Standard NIS is an option, but this involves taking a big step backwards in security. I've read that you should only use NIS on private LANs or networks behind a firewall, because anybody can request NIS maps from the network. I've also read that standard NIS can conflict with dns resolution unless you configure it carefully. Doesn't really sound like a viable option for me.
I was reading the documentation at www.padl.com and it looks like you don't get much of a security advantage by using their gateway. If it's simply replacing the dbm backend of nis with an ldap backend, you're still inheriting all the problems with nis. I guess the advantage is the scalability and portability of running off of an ldap server. It's a bit excessive for my needs, but probably perfect for an ISP.
This is done all of the time with NIS+ (Score:1)
running against Oracle, that broke when we moved
to NIS+. It parsed
of using getpwent and friends. Fortunately, that
high price tag included source.
UNICOS's UDB? (Score:1)