The kerberos libraries are linked in for kerberos authentication to a MS AD server not for other third party kerberos databases.
On Wed, 2005-05-04 at 19:45 +0200, Jos� M. Fandi�o wrote: > "Jos� M. Fandi�o" wrote: > > > > Ti Leggett wrote: > > > > > > That may be true, but there is another win in this type of environment. > > > Separation of your authentication database from your identity management > > > database. Regardless of how you authenticate in this scenario, you will > > > > also there is the opposite school of thought, if you have disconnected > > databases it makes management more difficult, i.e. keep passwords > > synchronized > > for different applications. > > > > > be sending passwords (even encrypted) over the wire. If the passwords > > > are in a KDC then at least it's not easy to gain those passwords. If you > > > keep your passwords in LDAP, then you need to be very careful about who > > > has access to them. > > > > that is true in an environment with native kerberos authentication, but > > > in the samba case it isn't applicable because the password is sent to > > PAM and this check the password against ldap send it over the wire. > > well, I'm a bit confused here. For Kerberos auth samba is using > native kerberos or pam_krb5? > > In my test machine smbd is linked with libpam, libkrb5 and libgssapi. > > # ldd /usr/sbin/smbd > libldap.so.2 => /usr/lib/libldap.so.2 (0x4001a000) > liblber.so.2 => /usr/lib/liblber.so.2 (0x40048000) > libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x40055000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0x40129000) > libresolv.so.2 => /lib/libresolv.so.2 (0x4015a000) > libcups.so.2 => /usr/lib/libcups.so.2 (0x4016b000) > libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40185000) > libnsl.so.1 => /lib/libnsl.so.1 (0x401b4000) > libpam.so.0 => /lib/libpam.so.0 (0x401c9000) > libattr.so.1 => /lib/libattr.so.1 (0x401d1000) > libacl.so.1 => /lib/libacl.so.1 (0x401d6000) > libdl.so.2 => /lib/libdl.so.2 (0x401dc000) > libpopt.so.0 => /usr/lib/libpopt.so.0 (0x401df000) > libc.so.6 => /lib/i686/libc.so.6 (0x401e5000) > libsasl.so.7 => /usr/lib/libsasl.so.7 (0x40303000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40316000) > libgssapi.so.1 => /usr/lib/libgssapi.so.1 (0x403bc000) > libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0x403c8000) > libasn1.so.5 => /usr/lib/libasn1.so.5 (0x40400000) > libroken.so.9 => /usr/lib/libroken.so.9 (0x40422000) > libcom_err.so.1 => /usr/lib/libcom_err.so.1 (0x40434000) > libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40437000) > > > > > On Wed, 2005-05-04 at 13:26 +0200, Jos� M. Fandi�o wrote: > > > > Hello Ti, > > > > > > > > Ti Leggett wrote: > > > > > > > > > > There are two main benefits to Kerberos authentication. The first is > > > > > that in a true Kerberos environment, no password is never sent across > > > > > the wire. The second, is that you get the holy grail of single sign > > > > > on. > > > > > > > > > > Your LDAP PDC should be able to make use of Kerberos though not in the > > > > > true sense. There is Kerberos support in Samba, but as I understand > > > > > it, > > > > > it's only for interacting with a Microsoft AD server and not others. > > > > > What will happen is authentication requests will come to the PDC which > > > > > will then use the underlying mechanism (a.k.a. PAM) to authenticate a > > > > > user. This is how I understand it and I'll defer to those more > > > > > knowledgeable on the list if I'm wrong. > > > > > > > > then..., there isn't any benefit associated with kerberos in a pure > > > > samba environment with a ldap(+tsl) backend? > > > > > > > > I was thinking about SSO and native kerberos logins but from this > > > > comment I must understand that it ins't possible? > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/listinfo/samba -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
