http://www.bisdesign.ca/ivandi/slackware/PAM/

I was able to join my employer's ADS and login with my ADS credentials.

Obviously more testing is needed.

My next step is to setup LDAP for central authentication.

Please don't turn this thread into pro/anti PAM discussion.

Cheers

Sometimes work environments dictate that we need to use A/D. I think you've made a great effort here. I haven't tested anything yet - in fact it will take me a chunk of time and even setting up a VM in order to try this out, but your efforts will be appreciated. Sure, there are PAM detractors, and I am most certainly one of them. I wouldn't run this on my own personal kit - but at work I support some linux VM's, and it could be useful for those to be able to integrate into the A/D system a bit better. Thanks.

Well done!
I would be very much interested in the outcome of this.
Please keep us informed.

-Stathis

Nice work, ivandi!

Some updates:

Fixed the samba.Slackbuild to put nsswich.conf.ads and system-auth.ads in the right place.
Put some default shares in smb.conf.ads.
Notice: It is really important to keep the clock in sync.
WinXP and Win7 fail to connect to samba shares if the clock is not in sync.
Odd enough smbclient has no problems connecting to windows shares even if the clock is out of sync.

Built openssh with PAM support.
Works fine. PAM can be turned off with "UsePAM no" in /etc/ssh/sshd_config. (at the end of file)

I read somewhere in this forum that PAM will always try to authenticate you remotely an if it fails you will be locked out. It's basically not true. Look at my system-auth.ads. The local user account takes precedence. If the ADS is down or winbindd isn't running there is no problem to login as a local user. I can login as root via ssh, stop samba and logout/login again. However PAM wont stop you from shooting yourself in the foot by putting in place some stupid config.

That's for now. Have fun!

Syncing the clocks on a local network is one of the first things I do when setting up a LAN. Otherwise you're in for some odd bugs.

The LDAP server is working. We have a basic directory: root,People,Groups.
And also a single user: volkerdi

Have to look at the options for the client side. And the security too.

Fixed the samba.Slackbuild. Yes again. For some odd reason Pat removes rc.samba.new in his doinst.sh so we may never get the new rc.samba that starts winbindd.

Cheers

1 members found this post helpful.

I am almost there. LDAP authentication is working. Have to look at the sasl/tls options.

Right now I am at the same time on:
tty1: root(w/o password)
tty2: local user
tty3: ADS user
tty4: LDAP user (volkerdi)

I have also three ssh logins (local,ads,ldap) and I am connected to my home share from win7 box.

PAM is not that evil after all

Cheers.

I think you need a dedicated website for this :-) With a change log so we can try to keep up with you !

Good work.

One note, I notice the pam_krb5 build, is it actually used anywhere or planned to be? Just wondering as if you stick to pam_winbind I would think you don't necessarily need it

@ivandi. In an ideal world, you put up a dedicated website for your packages. And then you write a detailed documentation about using them on http://docs.slackware.com.

Huge pat on the shoulder,

Niki

No, pam_krb5 is not used for now. May be I'll play with it later.

The things needed for the exercise are:

REQ: Linux-PAM
REQ: shadow
REQ: krb5
REQ: samba
REQ: openldap
REQ: nss-pam-ldapd
OPT: sudo
OPT: openssh

it that order.

Libcap has a PAM module that can enable capabilities for non suid binaries, but I didn't play with it either.

The goal of the exercise for me is almost achieved. I play with this during my lunch breaks or while waiting after some test bench. I have no time/intention to maintain an extra PAM repository (recompiling every package that has been upgraded by Pat). The README is quite clear I think. The stuff is working out of the box (at least for me, if you have some problems I'll be happy to fix them). A seasoned slacker shouldn't have problems with this.

In summary. It was fun to recall some old skills after more then 10 years. It wasn't that hard. PAM is not evil. It provides a great level of flexibility. I don't think it is too intrusive. Not for me at least. The average user shouldn't make a difference. I think in the future it will be harder for Slackware to avoid PAM then to adopt it.

Anyway, I'll continue to play with this stuff adding more packages when I have the time.

Cheers.

2 members found this post helpful.

The LDAP setup is now complete.
rc.ldap will generate a self signed SSL certificate.
slapd.conf ldap.conf nslcd.conf have been modified accordingly.

Happy LDAPing.

Now that we have Kerberos and LDAP working we can combine them with the help of pam_krb5. I updated the krb5 and pam_krb5 slackbuilds with some default configs for easy starting and testing. The user information uid gid etc. is kept in the LDAP database. The authentication is done by krb5. Actually the M$ ADS works the same AFAIK. I don't know what are exactly the advantages (if any) of this scheme, but I want to play with kerberised nfsv4 and think this is the right way to go.

Cheers