Date: Wed, 21 Jul 1999 10:57:24 -0600 From: Oscar Bonilla <obonilla@fisicc-ufm.edu> To: Niall Smart <niall@pobox.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PAM & LDAP in FreeBSD Message-ID: <19990721105724.F1520@fisicc-ufm.edu> In-Reply-To: <37960FEF.E6DBD6C0@pobox.com>; from Niall Smart on Wed, Jul 21, 1999 at 06:22:39PM %2B0000 References: <199907201520.LAA29350@cs.rpi.edu> <Pine.BSF.4.10.9907210141030.41996-100000@morden.rebel.net.au> <19990721094711.C1520@fisicc-ufm.edu> <37960FEF.E6DBD6C0@pobox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 21, 1999 at 06:22:39PM +0000, Niall Smart wrote: > [ CC list nuked ] good! :) >> Ok, here goes my understanding of how things should be, please correct me >> if i'm wrong. >> >> There are three parts to the problem: >> >> 1. Where do we get the databases from? I mean, where do we get passwd, group, >> hosts, ethers, etc from. >> >> This should be handled by a name service switch a la solaris. Basically >> we want to be able to tell the system for each individual database where >> to get the stuff from. We can add entries for each database in the system. > > Not so much as "where do we get the databases from" as "which databases > hold data for this particular service". For example DNS can store > information for the hosts service (i.e. nameserver service) but could > also > store crytographic keys which could be used for as host keys for ssh for > example. The service has a standard API (gethostbyname() for example, > or > getpwnam()) which can search through multiple disparate database types. > > (I may be mixing my terminology up here, it may be more conventional > to say "which services support this database", where the database > might be a load of struct pw for example, but hopefully its clear I > mean) > > Each particular database type might have its own configuration file. > Taking the "hosts" service for example, the configuration file for > the DNS database is /etc/resolv.conf and there is no configuration > for the files database (which uses /etc/hosts) Agreed. How would the sysadmin configure the stuff? I mean, our design should be flexible enough to allow for the kind of stuff you're talking about. I personally would like to be able to configure everything in the system the following way: $ cat /etc/nsswitch.conf passwd= ldap files hosts= dns files group= ldap files traditional service = where db to get it from here passwd means stuff that's in struct passwd hosts meand hostname to IP mapping, and so on. $ cat /etc/ldap.conf host= ldap.fisicc-ufm.edu basedn= ou=staff, dc=fisicc-ufm, dc=edu username= uid passwd= userPassword uid= userId gid= groupId home= userHome shell= defaultShell this would be all the ldap configuration stuff, for instance, how to map the struct passwd entries to the ldap records. $ cat /etc/resolv.conf usual dns configuration stuff so we would end up having a singe configuration file (nsswitch.conf) telling the system where to get the info from and then individual configuration files telling the system how to configure each individual service. now... would we want to be able to pull this individual configuration files from a certain service? could I have /etc/resolv.conf pulled from ldap for example? > >> 2. How to authorize the user? I mean, what sort of authentication should we >> use to decide if the user should be allowed in. >> >> This should be handled by PAM. > > Yes, although login programs would require that a) getpwnam returns > non-NULL and b) pam_authenticate returns PAM_SUCCESS. > this is what started the thread. I installed a pam_ldap module only to find out that login wouldn't let the user in because getpwnam returned NULL (not found on /etc/passwd). I then asked: "what would happen if login were to succeed, but once the user has logged in he/she doesn't have a username to uid mapping?" >> 3. What password hash should we use when we have the username and the >> password hash? >> >> This should be handled by the new modularized crypt. > > This is a function of the pam_unix module, a PAM module can > use smartcards, retina scanners, body odour detectors etc etc, > so it may not use password hashes at all. Each PAM module may > have its own configuration file to tell it which serial port the > smartcard reader is on for example. I don't see where the modularized crypt would fit in then... i totally agree that pam has this capability i was just trying to fit in the crypt stuff people have been working on. do I make sense? Regards, -Oscar -- For PGP Public Key: finger obonilla@fisicc-ufm.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990721105724.F1520>