Slashdot Mirror

Did you try nss_ldap

The enabling software pam_ldap and nss_ldap have been around for years. I worked on a project in Novell implementing similar functionality using NDS six years back.

The enabling software pam_ldap and nss_ldap have been around for years. I worked on a project in Novell implementing similar functionality using NDS six years back.

Yep centralised user management, great, no doubt.
But, what happens when the LDAP service isn't available?
I say service to not distinguish between a physical server, a cluster of servers, a crashed openLDAP process, broken network link, yadda, yadda, yadda.

With AD if a PDC isn't there, you can still login if you've logged on before.
The article really should have mentioned nss_updatedb and pam_ccreds from PADL (I don't know if there are any other alternatives, nor do I know if that actually work, sounds like they do though).

You'll need to get some custom code written for your systems, in order to get them to honor the time constraints you put in your LDAP server. You could do this most simply by modifying pam_ldap, probably, though I don't know whether there are any pre-defined schema/OID values that you could leverage.. you might need to define your own attributes and encoding.

Doing it at the Keberos level would work, but that would require modifications to the ticket granting server, so that it knows what services are to be constrained for which users on whatever schedule.

I'm not sure it does what you need, but you might check out the XAD Identity Server from PADL.com down in Australia. Luke Howard of PADL wrote the RFC 2307 which guides the use of LDAP on Unix systems for NIS-like applications (as well as the nss_ldap and pam_ldap modules that most folks use), and is generally an incredibly expert fellow.

You could also use something like our own Ganymede software to provide management intelligence for your central directory services, but as it's not specifically linked to LDAP or Kerberos (though you can adapt it to manage both, as we have), something like XAD is more likely to provide an appropriate framework for you.

If you were to be especially ambitious about doing the right thing, you'd talk to Luke about getting scheduled access controls into some successor to RFC 2307, and integrating support for those extensions into nss_ldap/pam_ldap.

This is sort of backwards.

The HOWTO discusses allowing authentication to Fedora Directory Server using Kerberos credentials from a Kerberos database. So this works like this: you want to use the LDAP service (Fedora Directory Server) to e.g. search for some users. You connect to it, and supply your Kerberos ticket, that's obtained from a Kerberos KDC (Key Distribution Server), based on authentication based on your Kerberos Server's database (probably some ordinary files). You get authenticated based on Kerberos's authentication databse (which is outside of FDS's LDAP!), then you get access to the LDAP database. It looks completely bottoms-up! You throw away the whole scalable n-way replicated LDAP authentication database that is available in the FDS, and use some simple academic Kerberos implementation to store all your users' keys and password data! You need to keep those 2 databases in sync, and your Kerberos server probably won't scale to such large numbers of users as the Fedora Directory Server, since open source Kerberos implementations (MIT, Heimdal) use their own file-based databases.
Forget 4-way multi master replication, forget scalability to hundreds of thousands of users.

Why use Fedora Directory Server at all then, if you delegate its most useful functionality to some separate agent, separating the authentication database from user database and turning the whole "centralized identity management by LDAP" concept upside down?

What's needed is getting a Kerberos server (KDC etc.) use Fedora Directory Server as its database backend, for efficient and stable storage of users, tickets, keys etc.
The Heimdal Kerberos implementation can do supposedly this, but only through UNIX domain sockets AFAIK (no LDAP over IP network :( ).
See:
http://www.padl.com/Research/Heimdal.html and http://www.pdc.kth.se/heimdal/ .

Since Fedora Directory Server doesn't seem to support LDAP over UNIX domain sockets, putting Heimdal Kerberos authentication layer on top of FDS looks impossible currently :(

Since it's built on top of OpenLDAP, yes, it obviously comes with ldapadd, ldapsearch and ldapmodify, just about all you need to accomplish the tasks you laid out above.

Their syntaxes are a bit confusing, but once you get them down, it's very easy to write cronjobs to populate the LDAP directory. If you're looking to migrate an existing userbase from NIS to LDAP, you should take a look at PADL's MigrationTools. Very useful, once you've hacked their shellscripts to match your environment.

Amusing. It's just part of the Sales Pitch to "the street" and those who have no clue. They're trying to make it sound like this old idea is new so they can generate excitement and multiples of real value for the IPO. And the market's collective amnesia will help them.

You should take a look at XAD: http://www.padl.com/Products/XAD.html

It is basically the cobbled together solution you mention, only nicely integrated into one supported package.

Try XAD from PADL.

To Windows clients, it acts as an Active Directory domain controller, so it supports Kerberos authentication, group policies, etc. It also includes RFC 2307 support for seamless integration of Linux/UNIX clients.

If you wanted to integrate LDAP did you not consider http://www.padl.com/OSS/nss_ldap.html instead of whining about not being able to use PAM ?

It's possible to support Active Directory clients using a Linux directory server, albeit not with NDS at this time. See XAD.

There is XAD.

As others have explained, the prevelance of Windows desktops is one reason why Active Directory is being widely deployed. One alternative that runs on Linux is PADL's XAD.

It's widely known what the contents of that extra packet is these days, actually. Luke Howard's XAD takes advantage of it, and the Samba guys are coding with it as well.

Sure, for the original bits, but Luke Howard of PADL.com has done an incredible amount of work in putting XAD together. Luke is one of the best of the best when it comes to LDAP, as well.. he's the original author of RFC 2307, which standardizes how NIS style directory objects should be mapped onto LDAP. RFC 2307 is the basis of directory service offerings from Apple, Sun, and other UNIX vendors.

Luke also created the best solution for supporting legacy NIS clients in an LDAP network, and he created a lot of the pam_ldap stuff that major vendors ship today.

Now, may I say, if you're looking for programmable metadirectory services for mastering data into NIS, DNS, LDAP, AD, and etc., I can humbly recommend Ganymede.. the current version is pretty spotty in some ways, but wwe are looking to release 2.0 in a few months with a lot of new features that will make it suitable for a lot more uses than it is now. Scalability, localization, SSL encryption, delta-based message queuing channels for change transmission, and much more is on tap.

The XAD identity server from PADL provides single sign-on across Windows, Linux and UNIX. It is based on OpenLDAP and Heimdal Kerberos.

XAD brings together OpenLDAP, Kerberos, and other open source software to provide single sign-on across Linux, UNIX and Windows.

PAM, pam_krb5, pam_ldap. Have Fun, I would recommend picking up Kerberos: The Definitive Guide before even considering going this route. Samba uses kerberos/OpenLDAP to talk to the Active Directory, but the details are hidden. Doing it yourself will quickly lead to the realization that Kerberos is no small subject.

Or using XAD.

See XAD.

Nine times out of ten people want PAM to authenticate to LDAP, and for that there's the FAR less bloated, FAR less convoluted nss_ldap module. It should be able to handle AD integration which should eliminate your needs ffor PAM.

I did a Google search for netinfo and pam and I found this page containing a link to something called pam_loginwindow.

but I recently had to get Solaris interacting with AD. After digging around and finding no real definitive documentation, I found a set of PAM and nsswitch modules from PADL that provide LDAP support for both setups.

After getting these to compile properly on Solaris (which was it's own nightmare, though they work out of the box for Linux), I had to install the AD4UNIX package. This is a program/plugin/schema update maintained at this site that adds the MS Servies for UNIX version 2 schema to the AD. This gives you places to store uids, gids, home directory, etc. It also gives a nice plugin for the AD user manager to let you set that data.

Finally, you edit a few config files (non-trivial, but possible) and suddenly you have AD users appearing in your passwd entries, and they can login with anything that uses PAM.

Like I said, i don't know how much that would apply to OS X (I haven't had a chance to play with it yet), but if you have PAM and NSS, it does work.

Also, I'm gonna put my notes online once i clean them up so that no other poor sysadmin has to dig for it.

A disclaimer first: I haven't tried to do this on MacOS X, but just did the same for Linux; you can do it on any unix that supports PAM for authentication.

It is certainly possible, however I wouldn't call this integration a "seemless" one (I didn't use samba for that).

You can extend AD schema to support unix by using AD4Unix package.
After that you need to install nss_ldap and pam_ldap. A good starting point on how to configure these two can be found at Security Focus. You may want to use Kerberos for authentication, as pam_ldap transmits username and password over the network (although with SSL support this data will be encrypted).

Hope this helps,
AC

A disclaimer first: I haven't tried to do this on MacOS X, but just did the same for Linux; you can do it on any unix that supports PAM for authentication.

It is certainly possible, however I wouldn't call this integration a "seemless" one (I didn't use samba for that).

You can extend AD schema to support unix by using AD4Unix package.
After that you need to install nss_ldap and pam_ldap. A good starting point on how to configure these two can be found at Security Focus. You may want to use Kerberos for authentication, as pam_ldap transmits username and password over the network (although with SSL support this data will be encrypted).

Hope this helps,
AC

I'm not too familiar with VMS, but Linux can and IRIX might (not support is mentioned for it) be able to use the pam_ldap/nss_ldap modules from padl.com to authenticate against Active Directory. IIRC, this requires SFU, but I could be wrong. There is a document about it in the tarball for nss_ldap.

Here's some links to Linux/AD integration from padl.com's doc section:

Active Directory and Linux

Linux-AD Integration

Active Directory and nss_ldap

/pointer

I'm not too familiar with VMS, but Linux can and IRIX might (not support is mentioned for it) be able to use the pam_ldap/nss_ldap modules from padl.com to authenticate against Active Directory. IIRC, this requires SFU, but I could be wrong. There is a document about it in the tarball for nss_ldap.

Here's some links to Linux/AD integration from padl.com's doc section:

Active Directory and Linux

Linux-AD Integration

Active Directory and nss_ldap

/pointer

so from this *BSD nor Linux can NOT use the code

Softerra's LDAP Administrator is pretty good, and they have a freeware version called LDAP Browser. The LDAP Browser/Editor is nice also.

If you are using LDAP as your addressbook, ldap-abook is a nice interface to add/delete/modify entries. Most email clients are LDAP-aware these days and it's convenient to be able to share an address book between my personal and work email accounts.

I've had to roll my own to do system accounts, however. Make ldapmodify your new best friend, or write an interface of your own - there is a lot of support for Perl or PHP LDAP functions out there. Server-side, I've used OpenLDAP and iPlanet's Directory Server, and I prefer iPlanet. iPlanet has a free non-commercial license option, is significantly faster than OpenLDAP, and has hooks to synchronize with an NT or Active Directory domain so you could do all the user administration in Windows and they would propagate over to your LDAP server.

Other fun things you can do with LDAP are:

Handle Unix authentication through pam_ldap
Hook into NIS with the NIS/LDAP gateway
Authenticate through apache with mod_auth_ldap or auth_ldap or Netegrity
Centralize your smtp routing data in LDAP for sendmail

Good luck.

Softerra's LDAP Administrator is pretty good, and they have a freeware version called LDAP Browser. The LDAP Browser/Editor is nice also.

If you are using LDAP as your addressbook, ldap-abook is a nice interface to add/delete/modify entries. Most email clients are LDAP-aware these days and it's convenient to be able to share an address book between my personal and work email accounts.

I've had to roll my own to do system accounts, however. Make ldapmodify your new best friend, or write an interface of your own - there is a lot of support for Perl or PHP LDAP functions out there. Server-side, I've used OpenLDAP and iPlanet's Directory Server, and I prefer iPlanet. iPlanet has a free non-commercial license option, is significantly faster than OpenLDAP, and has hooks to synchronize with an NT or Active Directory domain so you could do all the user administration in Windows and they would propagate over to your LDAP server.

Other fun things you can do with LDAP are:

Handle Unix authentication through pam_ldap
Hook into NIS with the NIS/LDAP gateway
Authenticate through apache with mod_auth_ldap or auth_ldap or Netegrity
Centralize your smtp routing data in LDAP for sendmail

Good luck.

checkout:


directory_administrator which is a GNOME LDAP user admin tool (slick enough for use by a frontline helpdesk).

there are other LDAP GUI's, KDE has one. search freshmeat.

gq a general purpose LDAP GUI tool. quite slick, comes with RH7.x.

Also, note that with RH7, the 'passwd' tool uses pam and will hence automatically work with LDAP authentication. (presuming your LDAP server is configured correctly for write access).

finally, you'll probaby want to develop your own scripts with template LDIF's for things like useradd, or find someone who's already done so. (i noticed there's a post on this thread providing a link to exactly that.) Note that for scripting, PADL's migration scripts are very informative. These are included with the OpenLDAP distribution.

I am with a admin group trying to integrate a couple hundred UNIX and Windows machines into a single login using an Active Directory server, which provides us with Kerberos authentication, and an LDAP directory. (This was mandated to us "from above") The kerberos authentication of course was easy, however there is hardly ANY information about actually using LDAP in a production environment.. we are trying to use the active directory LDAP server to provide the POSIX gecos and home directory information for the UNIX clients... however the default Active Directory schema does not include RFC2307

Probably the most frustrating part is if you go on google and look for help, you see people mentioning that this works, but never any specifics. I assume you are just using pam_ldap to grab a password crypt from an LDAP server (which is a secure as giving everyone read permissions on your shadow file).

I think the best solution is to use an LDAP server to host all the user information that is normally in /etc/passwd. This is possible in Linux and Solaris using the nss_ldap module which lets you add an "ldap" entry to your network switch file, and use ldap instead of /etc/passwd. It seems the best solution is Kerberos for authentication and LDAP for everything else, which Active Directory can provide, in a mixed-OS environment even.. but has anyone been able to successfully run nss_ldap against an AD LDAP server? (without using services for UNIX or other kludges) LDAP seems to be an integration nirvanna.. but without proper documentation I am afraid it will never see broader use..

I'm not very familiar with PAM, but isn't PAM only for authentication (can you get user name, shell, unix uid, home dir, etc. with PAM ?) .
nss_ldap also from the PADL guys, makes this possible, but your whole system becomes LDAP dependant, and you can't have different servers / search methods for every daemon (and this is ofen needed, for instance to separate POP/FTP users and those with shell or admin access, or site-local and remote users, or...) .

Isn't that what you should pam_ldap for?

Granted, of course it makes sense to use it more extensively (sendmail, ...).

There is interesting technology in Active Directory. It is an interesting project to attempt to provide these services without requiring the use of a Windows 2000 server infrastructure. I can't say I'm doing an awful lot to help in this regard presently, but I've made some notes, and you can check them out at http://www.padl.com/~lukeh/XAD/whit e_paper.html. The SAMBA people are probably most active on this front.

To answer some of your questions: I believe W2K can access old SMB-style shares. After all, it wouldn't make sense for it not to work with NT 4 shares. I expect the "new" SMB is wrapped in the Kerberos SSPI (wire-compatible with the Kerberos GSS-API mechanism). Regarding storing RFC 2307 information AD, good luck. Microsoft have made some modifications to the schema in order to support various "features" of Active Directory, such as the lack of support for multi-valued naming attributes, auxiliary classes not being listed as values of the objectClass attribute, some attribute type conflicts with RFC 2307, etc. Microsoft have an "embraced and extended" version that ships with Services for UNIX, but this isn't plug-and-play with existing RFC 2307 clients unless they support on-the-fly attribute mapping.

I'm looking for a distributed password/group file system for a mixed network - we've got Linux, HP-UX, IRIX, and Solaris (some using shadowed password files, some not) systems here, but I need to keep the passwords on the machines synchronized to a "master" machine, without using NIS/NIS+. Rdist is not acceptable either, since obviously a HP-UX machine cant use a password file straight from an IRIX box, etc. Suggestions?

If you are finding that encrypted passwords from one UNIX variant cannot be used on all the other variants you are using, then the first issue would be that of course using the raw password file in any way is out of the question (as you've noted, by dismissing Rdist).

So, some way of keeping a platform-neutral password is required - either in clear-text, or in some standard encryption format.

In terms of distribution, you can use a readily available password distribution scheme (such as NIS/NIS+), or you will have to write your own; this would need to capture passwords at every possible point (for users changing passwords), maintain the remote database, and keep redistributing changes out to each of the platforms.

Why reinvent the wheel?

If it is mainly NIS/NIS+ that concerns you, why not use something similar - LDAP? As long as each of the platforms supports PAM/NSS and/or some equivalent, then LDAP modules can be installed to perform password update and distribution automatically.

Certainly the latest versions of Solaris, HP-UX and Linux distributions support PAM/NSS; not quite sure about IRIX, though the software (see below) does mention IRIX support so it's perhaps through an equivalent interface.

http://www.padl.com/

Various functions in the C Library need to be configured to work
correctly in the local environment. Traditionally, this was done by
using files (e.g., `/etc/passwd'), but other nameservices (like the
Network Information Service (NIS) and the Domain Name Service (DNS))
became popular, and were hacked into the C library, usually with a fixed
search order.

The GNU C Library contains a cleaner solution of this problem. It is
designed after a method used by Sun Microsystems in the C library of
Solaris 2. GNU C Library follows their name and calls this scheme
"Name Service Switch" (NSS).

"If you're trying to implement this, I think that PAM (pluggable authentication modules) is the way to go."

Correct.

"You would need to write a wrapper for getpwent and friends and link all the programs on your system against it..."

Not necessarily - if you are using libc6 (ie., GNU libc 2.0 or 2.1) then you already have Sun Solaris-style NSS (Name Service Switch) which already provides the necessary "wrappers" for getpwent and friends in the standard C library; all you (the admin) needs to provide is a backend lookup library/module that will query against the nominated database.

The "modern" version of NIS/NIS+ is to do all this through LDAP - have a PAM module that performs authenticated binds against an LDAP directory (for authentication) and an NSS module that does all the get*ent lookups against the LDAP directory (for ls and friends).

Works a treat - absolutely no need for any users in /etc/passwd or /etc/shadow.

Check out:

• IETF RFC 2307
• NSS LDAP Module
• PAM LDAP Module

There are some other schema efforts underway (incl. The Open Group and the DMTF), though the above is the only one to so far "deliver" (for want of a better word) for UNIX and UNIX-like (POSIX) environments.

"If you're trying to implement this, I think that PAM (pluggable authentication modules) is the way to go."

Correct.

"You would need to write a wrapper for getpwent and friends and link all the programs on your system against it..."

Not necessarily - if you are using libc6 (ie., GNU libc 2.0 or 2.1) then you already have Sun Solaris-style NSS (Name Service Switch) which already provides the necessary "wrappers" for getpwent and friends in the standard C library; all you (the admin) needs to provide is a backend lookup library/module that will query against the nominated database.

The "modern" version of NIS/NIS+ is to do all this through LDAP - have a PAM module that performs authenticated binds against an LDAP directory (for authentication) and an NSS module that does all the get*ent lookups against the LDAP directory (for ls and friends).

Works a treat - absolutely no need for any users in /etc/passwd or /etc/shadow.

Check out:

• IETF RFC 2307
• NSS LDAP Module
• PAM LDAP Module

There are some other schema efforts underway (incl. The Open Group and the DMTF), though the above is the only one to so far "deliver" (for want of a better word) for UNIX and UNIX-like (POSIX) environments.