Inline. On Tue, Apr 10, 2001 at 09:10:42AM -0700, Alexander G. Paoli wrote: > Nico, > > I will begin traces, and post to the group. Thanks for at least reading > the long drawn out e-mail. > > OS: Linux 2.4.2, Gcc 2.95.2, glibc - 2.1.3, pam 0.74 and pam_krb5 > (1.1.1.1-1.2.2.2 or whatever) Cool. I had no idea that this pam_krb5 would compile and run on Linux at this point. BTW, did you see the warning in the man page about this pam_krb5 and Linux-PAM? You *must* specify the 'one_prompt_at_a_time' option to the pam_krb5 auth and password modules when using Linux-PAM; eventually this will be fixed. The problem has to do with an incompatibility between Linux-PAM and Solaris PAM. > Pentium III, 500 Dual Processor. > > Its a slackware 7.1 build, but, I rebuild the fundamental packages by > scratch for optimization and security (i.e. Named in /chroot jail). > > > ---- > BTW: I am not a programmer, although I do code in C, I just would never > claim to be anymore than amateur when it comes to coding. I am however, > working on a "draft" to present to coders like yourself and others to > consider to create a PAM-WIN2K module. I would like to know if you might > be interested in reading it. Frank Crusack will get a copy as well. (I > want to form it as an ID - Internet Draft for the IETF, where we can > really get interest in PAM and extend the already released draft, I > would submit it under either an individual release or under the security > WG) Hmmmm. Well, I was thinking of adapting the MS kpasswd code into a krb5_change_password() replacement function so that this PAM_KRB5 could be fully used with ActiveDirectory KDCs. I don't think a separate module will be needed, provided we can deal with the password changing protocol incompatibilities. > Basically in short, Use pam_krb5 to get the tgt, (read the MS PAC) get > info on user, query LDAP of AD via PAM_LDAP (We will extend the schema > on win2k to allow for CN=Unix-Home-Dir, CN=Unix-Shell etc), then from > there "like account" set up or add a /etc/passwd entry for the user, add > groups, adjust the ACL of the Linux Kernel, and finally utilize > pam_smbpass to get shares and other things. Hmmm, welllll.... I think the best way to deal with this is to have an NSS module that can use Kerberos authentication / PAC authorization data to do what you want, then PAM_KRB5 is merely responsible for initializing a ccache that the NSS module can use. With an NSS module you wouldn't have to dynamically modify /etc/passwd either... Of course, one of the biggest problems here is that the Kerberos principal namespace and the Windows SID namespace ARE NOT FLAT, whereas the Unix username/groupname/UID/GID namespaces ARE FLAT. Unix accounts are always "local" so Unix never really works well in multi-domain or multi-realm environments and you have to setup Kerberos/Windows <-> Unix mappings. But that's another story. > Ultimately this will allow a single-sign-on for a win2k user into Unix > (Solaris, Linux etc) to work on an Active Dir environment. I would go > farther and add a LDAP API to read AD (That would not be Pam as it would > be a separate part of the package). I want to draft the idea in general > then coding can be done any way that the community chooses. I would love > to see an ID on say "PAM With UNIX to Win2K" or even better yet > "PAM/UNIX to Directory Services", set the guidelines and set the > standard or procedure (policy) we use to accomplish it. See above. I think an NSS module can take care of this, with PAM_KRB5 merely providing the necessary credentials. One issue here is that the application using PAM must refrain from using getpwnam() on the PAM_USER until AFTER PAM_KRB5 has obtained the necessary credentials and that may not happen until after calling pam_chauthtok() is password aging situations. And other PAM modules like to call getpwnam(), so PAM_KRB5 would have to be first in the stack. > Well, Thanks for your time. Thanks for yours. > Alexander G. Paoli > VP Technology, Chief Network Architect > NetConstruct, Inc. > alex.paoli@netconstruct.net > > > > I think you might want to take this to the pam-list@redhat.com PAM > > list. And you should turn on PAM debugging and post logs. > > I agree. > Nico --
