samba - Nov 2005 - Can Winbind go directly to LDAP/Kerberos? Or is it PDC NTLM only?

Hi.

I am tinkering with PADL and Kerberos PAM, so that I can have account
authentication and directory directly to AD KDC/LDAP.

I always thought that windbind provided support for NT-style PDC for
authentication and referencing account-directory, and thus only work in
AD mixed-mode where PDC emulator is used for backwards compatibility.
However, I was reading a book that seemed to indicate that winbind will
talk directly to Active Directory (authenticate through KDC, reference
account info from LDAP).  Is this true? 

What I would like to do is:
  (1) direct authentication to AD KDC
  (2) referencing AD LDAP for account info
  (3) writing any mapped SID to UID/GID in SFU extended Active Directory
LDAP, instead of local database.

I've been digging through published and online documents, but most
documentation is oriented to old-school PDC.  I want to avoid NTLM and
PDCs of the past for security and performance reasons (NTLM single DES
vs. Kerberos triple DES for instance)

  -- Joaquin

On Mon, 2005-11-21 at 15:19 -0800, SAMBA wrote:
> Hi.
> I've been digging through published and online documents, but most
> documentation is oriented to old-school PDC.  I want to avoid NTLM and
> PDCs of the past for security and performance reasons (NTLM single DES
> vs. Kerberos triple DES for instance)
The issue of what authentication types are supported is not really
related to which user information modal is adopted.  That is, I suggest
you chose the use winbind as per the standard documentation, then set
your DC to only accept NTLMv2 and Kerberos (and triple-des kerberos
etc).

The biggest real threat with network security is the LM half of NTLM
authentication, which should be disabled (possibly by group policy) on
the clients.  (Modern clients will negotiate NTLM2, which removes the
problematic LM authentication, but this can be modified by an active
attacker.)

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.samba.org/archive/samba/attachments/20051126/75d0469a/attachment.bin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SAMBA wrote:

| What I would like to do is:
|   (1) direct authentication to AD KDC

Winbindd provides NTLM authenticationonly at the moment.
One of the developers is working on extending that
in pam_winbind.  For now you would use pam_krb5 if you
need to enable kerberos auth for Unix services.

Note that smbd supports ticket based authentication for
file and print services when joined to an AD domain.

|   (2) referencing AD LDAP for account info

Sure.  try 3.0.21rc1 for the latest set of improvements.

|   (3) writing any mapped SID to UID/GID in SFU extended Active Directory
| LDAP, instead of local database.

Winbindd won't write to an SFU enabled AD but it will use
the info if you use the ad idmap backend.

| I've been digging through published and online documents,
| but most documentation is oriented to old-school PDC.  I
| want to avoid NTLM and PDCs of the past for security and
| performance reasons (NTLM single DES vs. Kerberos triple
| DES for instance)

Windows 2000 and 2003 prefer RC4-HMAC and don't support 3des for
kerberos encryption types.




cheers, jerry
====================================================================Alleviating
the pain of Windows(tm)      ------- http://www.samba.org
GnuPG Key                ----- http://www.plainjoe.org/gpg_public.asc
"There's an anonymous coward in all of us."              
--anonymous
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDhhpXIR7qMdg1EfYRAqEkAKDKoqVJsFH8SFcxtMhYba16rr/lPQCePC7O
jZtvgblmoAgw8aNsyXPFB+g=uhBB
-----END PGP SIGNATURE-----