Writing a LDAP-backed hesiod server has a twisted appeal to me.
Hesiod is already well integrated into the get*() routines.

Need the pwent?  It can be derived from the LDAP user info.
There are schemae for services and about everything else.

NIS+ was never a good tool.  Ever.  We told them that at the
start and we told them that recently.  but the fact that they
own netscapes servers mean that the NIS schemae are well distributed.

Quoting Sporleder, Matthew (CCI-Atlanta) (Matthew.Sporleder@cox.com):
> I, for one, would like to see any type of LDAP nsswitch options.
> Sun is pushing to replace NIS+ and I think it's a good idea.
> 
> -----Original Message-----
> From: Simon J. Gerraty [mailto:sjg@crufty.net]
> Sent: Wednesday, January 22, 2003 3:05 AM
> To: Greg A. Woods
> Cc: current-users@netbsd.org
> Subject: Re: integrating PAM
> 
> 
> >Note BSD Auth can use PAM modules, but as I understand it, not the other
> 
> Some PAM modules perhaps but not those that want/need to tweak the 
> state of the original process.
> 
> Here's a real world example for you...  template users authenticated
> via radius (or tacplus).  Along with the auth ok message radius can
> provide the name of a "real" account (the template) on the box.
> Thus the user gets say logname=hoopie but pw_name=remote.
> 
> Now - how exactly would you do that with BSD Auth?
> Note; the answer "I have no need of that functionality" isn't an option.
> 
> >way around (and of course it doesn't make even the remotest bit of sense
> 
> What exactly would make it impossible for a PAM module to invoke a 
> sub-process?  That is about all that's needed for BSD Auth right?
> 
> And why would it make zero sense to have a pam_bsdauth.so ?
> if nothing else it would provide a simple hook for folk to implement
> simple authentication scripts such as those Peter Seebach mentioned.
> Folk that fear/loath shared libs need not of course install it of course. 
> 
> Note I have no objection to BSD Auth, and making it an option (via PAM
> perhaps) sounds like a good idea.  But it is far from a "standard"
> (further than PAM anyway) and does not address all the issues PAM does.
> 
> Regardless, there is no need to see the two as mutually exclusive.
> 
> Thanks
> --sjg