[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Extension to back-passwd: back-posix

Symas actually has a full implementation of this backend (with secure access and supports writes as well as reads) that we completed back in 1999, as part of our Connexitor EMS product family. I decided it was pointless to use /etc/passwd as a whitepages directory, and restricted our attention to using it as an authentication service only. In Connexitor EMS we distinguish the notion of "people" and "accounts" - a person entry can own multiple accounts; we maintain whitepages info for person entries, but account entries are barebones.

Now that the topic of identity management is getting more attention these days, this type of module is becoming more relevant.
I definitely see the concept being useful; unlike the approach taken by pam_ldap/nss_ldap (which pretty much falls dead whenever your network hiccups) we put a slapd in front of all of the managed systems and expose their security databases via LDAP. Then from a central server we can do all the usual account management functions and push changes out to the rest of the network, all through LDAP (secured by TLS, by default). We also do some "secret" tricks to allow LDAP update operations to be multicast to a network in the same way that X.500 search operations can be chained to a network of DSAs, so that LDAPmodifying one person entry in our central directory causes all of that person's accounts to be updated throughout the network. (This is not quite the same as replication; the target servers are not in any way "mirroring" the central directory. Also, we collect all of the success/failure results from each target and return them to the client. In most replication setups nobody knows how far or how fast the updates propagate, and certainly the original client never sees that kind of feedback. But you really can't run an identity management system without this knowledge in realtime.)

(Our NT-LDAP Gateway product is another piece of the Connexitor EMS family, it actually started as back-passwd plugged in to the NetLogon API and grew from there.)

Anyway, the point of this email was to say - you probably shouldn't spend much time sweating over the whitepages-oriented schema. Unless of course /etc/passwd really is the authoritative source of phone numbers and such in your organization, in which case you should probably allow config items to map GECOS field positions to LDAP attributes.

Dave Horsfall wrote:
As discussed in ITS #3737, I'm going to write a new backend based upon back-passwd (calling it "back-posix" for want of a better name), but before I do so I want to make sure that I won't be wasting my time by having to throw everything out and starting again.

Our objective here is to provide a single search against multiple sources including /etc/passwd, so back-posix would slot underneath back-meta. It would be as general as possible whilst catering for our needs, hence the proposed discussion.

I've browsed the archives noting the points therein, especially the threads openldap-devel/199901/msg00035 and openldap-devel/199903/msg00011, and ITS #40.

Outline:

Returns objectClass inetOrgPerson/posixAccount, with as many attributes as I can find or infer, as uid=pw_name [0]:

	Required attributes:

	cn:		Set from pw_name (configurable? [1])
	gidNumber:	Set from pw_gid
	homeDirectory:	Set from pw_dir
	sn:		Inferred from pw_gecos [2]
	uid:		Set from pw_name
	uidNumber:	Set from pw_uid

	Optional attributes:

	description:	Set from pw_gecos (up to first comma?)
	gecos:		Set from pw_gecos
	givenName:	Set from first token in pw_gecos (or pw_name if "&")
	initials:	Hmmm...
	loginShell:	Set from pw_shell
	userPassword:	Set from pw_passwd [3]

	Other optional attributes (which we don't use):

	host:		It's only in "account" [4]
	l:		Set from getdomainname()
	mail:		Set from pw_name @ domain
	telephone:	Extract from pw_gecos [5]

Other considerations (which definitely won't be in the first cut):

	Remove the serialisation.
	Implement some form of cache.
	Handle setpassent().

Anything else?

Notes:

[0]	Or configurable, as long as it's a required attribute.

[1]	I prefer my configuration options to be set at run time, not
	compile time, wherever possible.  Other options include returning
	pw_gecos instead, or givenName+sn?

[2]	Take everything before first "," and then all but first token,
	perhaps skipping what looks like initials.

[3]	Probably useless in a shadowed environment.

[4]	But could be a configurable option...

[5]	How portable is this field, as Howard noted?  On FreeBSD at
	least, it's full name, office, work phone, home phone.  One
	whacky idea could be "gecos l,telephoneNumber,homePhone" i.e.
	parse the stuff after the first comma into those attributes.



--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support