NFS V4 works. w/o krb5 for now.

I think everything is in place for kerberized nfs4, but it seems I'll need sasl to make openldap and krb5 play nicely together and then go back to nfs.

Cheers

Seriously, you will need to add all the above information to docs.slackware.com
All of this is priceless information for people who need to get their slackware box to play nicely in a AD heavy corporate environment.

+65536

I updated several slackbuilds.

OK, I have a fully kerberized ldap setup here using sasl. A server that runs kerberos, ldap, nfs4 and a client container where I can login as user from the ldap directory and my home folder is mounted: -t nfs4 -o sec=krb5i.

Still can't figure out an acl for slapd.conf that allows me to add/remove entries in the ldap database as admin/admin with "disallow bind_anon".

For those of you willing to test this stuff there are some configs that I am using for my tests in the /host folder.

Cheers

Everything is working now.

I fixed slapd.conf. The kerberos admin/admin principal will manage the LDAP directory. Added ldapscripts.SlackBuild to help with directory management.

The setup is complete.

Cheers

Now that everything is working I wrote a script to automate all this: setup.LDAP

Basically one needs to run it on the server: setup.LDAP server
And on every client: setup.LDAP client

The script is a how-to by itself. It will create the databases and configs and generate a self signed certificate. It provides reasonable defaults but everything can be adjusted in the config section.

Updated the README. Also removed a bunch of *.conf.new from several slackbuilds. setup.LDAP will create them.

Now setting up a central authentication in Slackware is a piece of cake :)

Cheers

This is great work. It should deserve to be a sticky post in the forum.

if it matters anything, i second that

I am glad you appreciate. Sure it'll increase the visibility.

I joked that now the central authentication is a piece of cake, but actually it is not.
It is sort of forking Slackware.
I stumbled upon this yesterday:
http://www.hashbangbash.com/downloads/pam/
It seems someone works on integrating PAM and tries to keep up with current.
It looks like my slackbuilds will be a nice addition to his project.
And if one decides to go this way he'll have more than 20 core packages to care about.

That said my project is not of much practical use. It only shows the advantages of having PAM and Kerberos in Slackware.

Cheers.

Well, I'll be looking at what you did to see if OpenLDAP can provide centralized user management without PAM.

Actually I looked at that option but didn't go with it for my tests.

I might be wrong, but from what I did understand that's how we can do this w/o PAM:

Build nss-pam-ldapd with --disable-pam.
Kerberos is not in Slackware so we'll skip it too.

We put all passwords in the LDAP database.
We can go the easy way and enable anonymous bind.
Didn't test it but it seems that everybody can get the password hash.
Like in NIS.

We can create a user that nslcd will bind with and disable the anonymous bind.
We need to put this user's password into nslcd.conf on every client and make sure it is secure.


My initial goal was to make my Slackware box join the AD.
Kerberos was mandatory and using PAM with Samba was the easiest (may be the only reasonable) way to do that.

Once I had this in place I decided to go the LDAP+KRB+PAM way. It looked more secure.
And it seems that's the way how everybody out there does this.

Cheers

Well, you can bind over ssl and you can use SASL to authenticate your connection by accessing the LDAP database.

I've got a bunch of links somewhere that goes over it on my other machine.

That's exactly what I am doing.
The setup generates a ssl certificate. Only ldaps:// is available.
SASL GSSAPI is required.

PAM's pam_krb5 is used to authenticate against Kerberos.
We can use any Kerberos enabled login in place.
Openssh supports Kerberos directly and there is login.krb5.
Don't know how those will handle local users.
With PAM there is no problem if the local user fails to authenticate against LDAP.
One mandatory local user for example is root. I think it's a bad idea to have a global root principal.

Anyway one can test all this and report the results.
I am not interested in testing all of the available options.

As I said my priority was full AD integration. And I need PAM and Kerberos for this.

Cheers

@Richard Cranium

BTW here is a quote from openldap-client.SlackBuild:
May be Pat has already been there.

Cheers

Oh, I wasn't complaining about what you did or meant to imply that you should have done something else. I was saying that I was going to steal from your work since getting the SSL setup correct is critical in this sort of thing. And that you must have set up the LDAP database correctly to allow you to get your login information. So that's two work items I hope to get from your work. :-)