[Samba] Re: idmap_ad: sid to uid conversion fails
The story so far goes like this:
Without the line
idmap backend = ad:ldap://PDC's FQDN/ in smb.conf,
I can successfully do all of:
# wbinfo -S $(wbinfo -n some_user | awk '{print
$1}')
# getent passwd | grep some_user
# net ads search '(objectCategory=user)' \
sAMAccountName msSFU30GidNumber msSFU30UidNumber | \
grep -A2 some_user
idmap_ad expects RFC 2307 schema (gidNumber and uidNumber).
If you are using the MS SFU schema you'll need to change the
code, should be a simple search and replace.
-- Luke
--
--
To unsubscribe from this list go to the following URL and read the
instructions: http://lists.samba.org/mailman/listinfo/samba
[Samba] Re: [Solved] Re: idmap_ad: sid to uid conversion fails
It's probably worth noting that for users who are adding idmap_ad over an existing winbind setup, the old mapping has to be deleted as above. Thanks, I'll put this in the README for the next version. regards, -- Luke -- -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Plugin API questions
First, I can't seem to build HEAD lately:
Compiling smbd/vfs.c
smbd/vfs.c: In function `vfs_init_custom':
smbd/vfs.c:263: `static_init_vfs' undeclared (first use in this function)
smbd/vfs.c:263: (Each undeclared identifier is reported only once
smbd/vfs.c:263: for each function it appears in.)
make: *** [smbd/vfs.o] Error 1
Secondly, is the following function all that is necessary to upgrade an
authentication plugin to use the new plugin API? Has the configuration
directives changed for loading authentication plugins?
/* old plugin API initialization prototype */
NTSTATUS auth_init(struct auth_context *auth_context, const char *param, auth_methods
**auth_method);
int auth_paula_init(void)
{
return smb_register_auth(paula, auth_init, AUTH_INTERFACE_VERSION);
}
cheers,
-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
I really don't think that putting keytab code in to Samba is the right answer. Do you really want to be in charge of modifying keytabs? This could get quite complicate -- especially when you multiply the effort by the number of possible encryption types... I don't think it's that complicated. It is not difficult to enumerate the supported encryption types. Moreover, there's no requirement that SAMBA use the same keytab as other applications, or that keytab support completely replace the secret store. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
I agree that if Samba is changing the password for a particular kerberos principal, then it should store the hashes in the keytab. The idea of *finally* getting kerberos useful on real sites is just too appealing :-) Naturally, the original plaintext password should stay basically where it is. In that case, perhaps it *is* better just to provide a get/set command line tool for the secret store rather than trying to hook the keytab into SAMBA per se. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
Yes. This is a problem. In the past I have favored a 'krb5 keytab write' option that would write our password out into the standard keytab, but there were good reasons not to. The problem is, I can't remember what they were. Mostly 'if somebody changed our password under us' stuff. Hmm, why would this be a problem? (I mean, I can understand it would be a problem if it happened while SAMBA was running, but keytabs tend to be fairly static...) -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: The new modules system
Will this break compatability with auth plugins? -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: The new modules system
Will the migration to the new format be difficult and/or documented? -- Luke From: Jelmer Vernooij [EMAIL PROTECTED] Subject: Re: The new modules system To: Luke Howard [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Thu, 20 Mar 2003 13:12:39 +0100 On Thu, Mar 20, 2003 at 10:45:04PM +1100, Luke Howard wrote about 'Re: The new modules system': Will this break compatability with auth plugins? Currently not as auth and vfs don't use the new modules system yet (only pdb and rpc). I will have to break auth plugin compatibility when I'm converting the auth subsystem to the new modules system. Configuration(i.e. smb.conf) won't need to be changed, though. Jelmer -- Jelmer Vernooij [EMAIL PROTECTED] - http://nl.linux.org/~jelmer/ 13:10:16 up 2 days, 19:24, 17 users, load average: 0.11, 0.14, 0.37 [Attachment: a2, application/pgp-signature] -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: HEAD pdb_ldap
Ah, and another point: This is certainly not race-free. But that is difficult to do with LDAP. This is true. In our code we ended up implementing lazy set accessors that took both a snapshot of the entry and a set of changes as inputs. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: winbind vs. pam/nss alternatives
3) Could winbind easily handle some of the nss lookups via ldap ala rfc 2307 schema (if it matters anymore - it is just an experimental RFC) as a While there are probably more domain controllers than RFC 2307-compliant LDAP servers, it is the de facto LDAP nameservice schema for the UNIX platform, and is thus unlikely to disappear overnight. Many large organisations have deployed this schema (they are our customers). -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: winbind vs. pam/nss alternatives
I agree, but was thinking about ease of use, and longer term whether we could have the logon/caching/performance intensive UID/GID caching leveraged by the four and five main alternatives (winbind already supports two) and whether the caching code for a particular pam/nss daemon was already significantly better than winbind. We have always argued that caching of nameservice information should be performed by a provider-agnostic mechanism, such as nscd. We agree that the existing implementation of nscd is flawed in that it does not cache enumerations, and to that end we suggest that one may run a caching LDAP proxy on each client machine and have nss_ldap communicate with it via domain sockets (ldapi://). Seems like extending one or the other pam/nss pair could be done in theory so the client logon daemon could autodetect RFC 2307 vs. AD vs. DCE/RPC and take away some of the configuration headache of moving a machine around to different security domains in heterogeneous environments. As I see it, daemon architecture notwithstanding, winbindd and nss_ldap cater to different problem spaces. That could change if winbindd supported RFC 2307, admiteddly. The other thing that seems a little unusual is the idea of using pam_ldap for authentication (on the other hand nss_ldap makes more sense to me) because intuitively it seems like I need Kerberos tickets anyway (for nfs v4 client and eventually cifs client) so why don't I just get my TGT in the pam module (ala pam_winbind or pam_kerberos) and only use nss_ldap or nss_winbind (or a convergence of the two that autosenses the server schema). The ldap client presumably prefers binding via Kerberos anyway so seems like Kerberos authentication is going to occur in any case. Not everyone uses Kerberos; particularly on UNIX, the deployment cost for a long time has been quite high (no integrated directory and authentication server, perceived complexity, etc), and many organisations have chosen to deploy LDAP-based authentication solutions. I for a long time argued that LDAP was not an authentication protocol, and that a pam_ldap module should not exist, but in the end there was a demonstrable need for such a module. Today Linux (and a few other Unix platforms) can require manual reconfiguration to switch to a different type of logon server, e.g. if an RFC 2307 server is ever replaced by Samba or Windows or vice versa even though PAM/NSS has quite a bit of flexibility. What are the implications if different users from different security domains (one Kerberized RFC 2307 and one Samba or AD) on the same physical client As long as you can avoid namespace collision, there is no problem with this. Of course, avoiding namespace collision is difficult without a hierchical namespace, and thus requires some administrative collusion. I don't know how easily RFC 2307 could be reconciled with ActiveDirectory on the OpenLDAP side to make the issue on the client almost moot, but in the meantime. There are schema conflicts between RFC 2307 and Active Directory. Microsoft chose to resolve this in their Services for UNIX product by renaming some attributes and object classes (moreso in subsequent versions). We have had to address similar issues in our domain controller implementation, albeit less aggressively. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: New approach for winbind to match Windows to UNIX users and back
I hadn't realized that an SID is actually 256 bits and we at best only have 32 bits to work with I I was only thinking about the RIDs). A SID is variable length, really. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: HEAD: PDC or BDC?
I think there is something wrong here .. I think the 'server' or 'domain' security + lp_domain_logons() should make a BDC, and that 'ads' + lp_domain_logons() should simply give an error until we are able to make up a compatible AD DC. Maybe this could remain enabled in HEAD but cause an error in release branches. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: samba + w2k + kerberos + trusted realm
What is it that limit samba to root ? When I use samba with afs beeing root will certenly not help samba access files, what else do samba need. SAMBA does need to bind to privileged ports. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: [PATCH] Mutual authentication, keytabs, and SMB session keys
You may want to omit the USE_KEYTAB patch to passdb/secrets.c: we don't actually use that, and without support for updating the secret, it may be of limited use. Actually, there are a couple of memory leaks in secrets_fetch_keytab_password(), too so if you intend to include it -- let me send you the revised patch. :-) -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
[PATCH] Check for ENCTYPE_ARCFOUR_HMAC_MD5 (Heimdal) in libads
This patch (includes portion of the previous patch) checks for
ENCTYPE_ARCFOUR_HMAC_MD5 in libads/sasl.c (named differently to
MIT).
-- Luke
Index: configure.in
===
RCS file: /cvsroot/samba/source/configure.in,v
retrieving revision 1.409
diff -u -r1.409 configure.in
--- configure.in22 Feb 2003 12:19:18 - 1.409
+++ configure.in24 Feb 2003 10:15:52 -
@@ -2248,6 +2257,22 @@
samba_cv_HAVE_KRB5_TKT_ENC_PART2=yes,samba_cv_HAVE_KRB5_TKT_ENC_PART2=no)])
if test x$samba_cv_HAVE_KRB5_TKT_ENC_PART2 = xyes; then
AC_DEFINE(HAVE_KRB5_TKT_ENC_PART2,1,[Whether the krb5_ticket struct has a
enc_part2 property])
+fi
+
+AC_CACHE_CHECK([for ENCTYPE_ARCFOUR_HMAC_MD5],samba_cv_HAVE_ENCTYPE_ARCFOUR_HMAC_MD5,[
+AC_TRY_COMPILE([#include krb5.h],
+[krb5_enctype enctype; enctype = ENCTYPE_ARCFOUR_HMAC_MD5;],
+samba_cv_HAVE_ENCTYPE_ARCFOUR_HMAC_MD5=yes,samba_cv_HAVE_ENCTYPE_ARCFOUR_HMAC_MD5=no)])
+if test x$samba_cv_HAVE_ENCTYPE_ARCFOUR_HMAC_MD5 = xyes; then
+AC_DEFINE(HAVE_ENCTYPE_ARCFOUR_HMAC_MD5,1,[Whether the ENCTYPE_ARCFOUR_HMAC_MD5
key type is available])
fi
Index: libads/ldap.c
===
RCS file: /cvsroot/samba/source/libads/ldap.c,v
retrieving revision 1.102
diff -u -r1.102 ldap.c
--- libads/ldap.c 24 Feb 2003 03:45:02 - 1.102
+++ libads/ldap.c 24 Feb 2003 10:15:52 -
@@ -1074,7 +1074,7 @@
goto done;
acct_control = UF_WORKSTATION_TRUST_ACCOUNT | UF_DONT_EXPIRE_PASSWD;
-#ifndef ENCTYPE_ARCFOUR_HMAC
+#if !defined(ENCTYPE_ARCFOUR_HMAC) !defined(HAVE_ENCTYPE_ARCFOUR_HMAC_MD5)
acct_control |= UF_USE_DES_KEY_ONLY;
#endif
if (!(controlstr = talloc_asprintf(ctx, %u, acct_control)))
Index: libads/sasl.c
===
RCS file: /cvsroot/samba/source/libads/sasl.c,v
retrieving revision 1.14
diff -u -r1.14 sasl.c
--- libads/sasl.c 15 Feb 2003 00:29:21 - 1.14
+++ libads/sasl.c 24 Feb 2003 10:15:52 -
@@ -244,6 +244,8 @@
krb5_enctype enc_types[] = {
#ifdef ENCTYPE_ARCFOUR_HMAC
ENCTYPE_ARCFOUR_HMAC,
+#elif defined(HAVE_ENCTYPE_ARCFOUR_HMAC_MD5)
+ ENCTYPE_ARCFOUR_HMAC_MD5,
#endif
ENCTYPE_DES_CBC_MD5,
ENCTYPE_NULL};
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: [PATCH] Mutual authentication, keytabs, and SMB session keys
Hi Andrew, Given the non-invasive nature of this patch, I'll add it without the #ifdef. Would it be possible for you to add 'write' support to this? (Changing the password and storing it into that keytab). Shouldn't be too hard: note, though, we don't store the cleartext password in the keytab (although that would be possible by defining a new enctype) so it may only be useful in a limited set of circumstances. Any chance we can implement this in our client code? This would certainly help in testing. Do you mean any chance I can implement this in our client code? :-) I could certainly take a look; in the mean time, I would expect that it would ignore the AP_REP (given that Windows 2000 appears to always do mutual authentication on SMB). Have you looked at SMB signing with this key? Or how SMB signing is done on a kerberos connection? No. I expect SMB signing uses GSS_Wrap() and GSS_Unwrap(). This need not necessarily use an RC4 key, but the SMB session key (for want of a better phrase) must be an RC4 key. Caveats: I haven't tested for MIT compat (although I have tried to avoid any obvious breakage), and because ENCTYPE_ARCFOUR_HMAC_MD5 is an enum in Heimdal, it should really be tested for in configure... Yes - can you knock up such a test? OK. +#ifdef KV5M_ALT_METHOD case KRB5_KPASSWD_INITIAL_FLAG_NEEDED: return KRB5KDC_ERR_BADOPTION; /* return KV5M_ALT_METHOD; MIT-only define */ break; +#endif I'm not quite sure what you are doing here... KV5M_ALT_METHOD was not defined for Heimdal but, I see, you've noticed that too, I hadn't updated the patch :-) Firstly - can we have a configure test for the Heimdal name. Secondly - why is this restricted to the type 23 key? If we do a login without a type 23 key, why can't we use some other session key? Or will the client indicate what session key to use? The ticket includes a session key. The ticket session key may be used as the SMB session key for encrypting passwords in SamrSetInformationUser(), for example. Secondly, I'm not quite sure why this isn't in kerberos_verify.c? Or if we can also use this client-side, can you add that? It would greatly assist in testing... I put it in clikrb5.c for portability; didn't want to put tests for MIT or Heimdal specific functionality in kerberos_verify.c This needs to be 'False', as FALSE isn't a portable define. Ouch, I always forget that. Doesn't the kerberos deal with the byte order? Or shouldn't we create a asn1_write function to do this? The token ID is not ASN.1. Read RFC 1964. Can we have a name for this magic number? A define in asn_1.h or similar? Again, see RFC 1964. Actually, they probably shouldn't be little- endian shorts; my bad (but they certainly weren't ASN.1 booleans! :-)) Better to do: #define TOK_ID_KRB_AP_REQ \x01\x00 #define TOK_ID_KRB_AP_REP \x02\x00 I'll knock up another patch later today... cheers, -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: [PATCH] Mutual authentication, keytabs, and SMB session keys
Here's a revised patch that cleans up a few of the issues you mentioned.
You may want to omit the USE_KEYTAB patch to passdb/secrets.c: we don't
actually use that, and without support for updating the secret, it may
be of limited use.
-- Luke
Index: configure.in
===
RCS file: /cvsroot/samba/source/configure.in,v
retrieving revision 1.409
diff -u -r1.409 configure.in
--- configure.in22 Feb 2003 12:19:18 - 1.409
+++ configure.in24 Feb 2003 06:04:25 -
@@ -627,6 +627,15 @@
fi
+# support for using Kerberos keytab instead of secrets database
+
+AC_ARG_ENABLE(keytab,
+[ --enable-keytab Turn on support for Kerberos keytabs in lieu of secrets DB
(default=no)],
+[if eval test x$enable_keytab = xyes; then
+ AC_DEFINE(USE_KEYTAB,1,[Use Kerberos keytab])
+fi])
+
+
# we need dlopen/dlclose/dlsym/dlerror for PAM, the password database plugins and the
plugin loading code
AC_SEARCH_LIBS(dlopen, [dl])
# dlopen/dlclose/dlsym/dlerror will be checked again later and defines will be set
then
@@ -2248,6 +2257,22 @@
samba_cv_HAVE_KRB5_TKT_ENC_PART2=yes,samba_cv_HAVE_KRB5_TKT_ENC_PART2=no)])
if test x$samba_cv_HAVE_KRB5_TKT_ENC_PART2 = xyes; then
AC_DEFINE(HAVE_KRB5_TKT_ENC_PART2,1,[Whether the krb5_ticket struct has a
enc_part2 property])
+fi
+
+AC_CACHE_CHECK([for keyvalue in krb5_keyblock],samba_cv_HAVE_KRB5_KEYBLOCK_KEYVALUE,[
+AC_TRY_COMPILE([#include krb5.h],
+[krb5_keyblock key; key.keyvalue.data = NULL;],
+samba_cv_HAVE_KRB5_KEYBLOCK_KEYVALUE=yes,samba_cv_HAVE_KRB5_KEYBLOCK_KEYVALUE=no)])
+if test x$samba_cv_HAVE_KRB5_KEYBLOCK_KEYVALUE = xyes; then
+AC_DEFINE(HAVE_KRB5_KEYBLOCK_KEYVALUE,1,[Whether the krb5_keyblock struct has a
keyvalue property])
+fi
+
+AC_CACHE_CHECK([for ENCTYPE_ARCFOUR_HMAC_MD5],samba_cv_HAVE_ENCTYPE_ARCFOUR_HMAC_MD5,[
+AC_TRY_COMPILE([#include krb5.h],
+[krb5_enctype enctype; enctype = ENCTYPE_ARCFOUR_HMAC_MD5;],
+samba_cv_HAVE_ENCTYPE_ARCFOUR_HMAC_MD5=yes,samba_cv_HAVE_ENCTYPE_ARCFOUR_HMAC_MD5=no)])
+if test x$samba_cv_HAVE_ENCTYPE_ARCFOUR_HMAC_MD5 = xyes; then
+AC_DEFINE(HAVE_ENCTYPE_ARCFOUR_HMAC_MD5,1,[Whether the ENCTYPE_ARCFOUR_HMAC_MD5
key type is available])
fi
Index: include/asn_1.h
===
RCS file: /cvsroot/samba/source/include/asn_1.h,v
retrieving revision 1.6
diff -u -r1.6 asn_1.h
--- include/asn_1.h 13 Feb 2003 21:40:35 - 1.6
+++ include/asn_1.h 24 Feb 2003 06:04:26 -
@@ -59,4 +59,11 @@
#define SPNEGO_NEG_RESULT_INCOMPLETE 1
#define SPNEGO_NEG_RESULT_REJECT 2
+/* not really ASN.1, but RFC 1964 */
+#define TOK_ID_KRB_AP_REQ \x01\x00
+#define TOK_ID_KRB_AP_REP \x02\x00
+#define TOK_ID_KRB_ERROR \x03\x00
+#define TOK_ID_GSS_GETMIC \x01\x01
+#define TOK_ID_GSS_WRAP\x02\x01
+
#endif /* _ASN_1_H */
Index: libads/kerberos_verify.c
===
RCS file: /cvsroot/samba/source/libads/kerberos_verify.c,v
retrieving revision 1.6
diff -u -r1.6 kerberos_verify.c
--- libads/kerberos_verify.c19 Feb 2003 01:16:40 - 1.6
+++ libads/kerberos_verify.c24 Feb 2003 06:04:26 -
@@ -3,7 +3,7 @@
kerberos utility library
Copyright (C) Andrew Tridgell 2001
Copyright (C) Remus Koos 2001
-
+ Copyright (C) Luke Howard 2003
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -29,14 +29,18 @@
authorization_data if available
*/
NTSTATUS ads_verify_ticket(ADS_STRUCT *ads, const DATA_BLOB *ticket,
- char **principal, DATA_BLOB *auth_data)
+ char **principal, DATA_BLOB *auth_data,
+ DATA_BLOB *ap_rep,
+ uint8 session_key[16])
{
krb5_context context;
krb5_auth_context auth_context = NULL;
krb5_keytab keytab = NULL;
krb5_data packet;
krb5_ticket *tkt = NULL;
- int ret, i;
+ int ret;
+#ifndef USE_KEYTAB
+ int i;
krb5_keyblock * key;
krb5_principal host_princ;
char *host_princ_s;
@@ -44,8 +48,10 @@
char *password_s;
krb5_data password;
krb5_enctype *enctypes = NULL;
+#endif /* USE_KEYTAB */
BOOL auth_ok = False;
+#ifndef USE_KEYTAB
if (!secrets_init()) {
DEBUG(1,(secrets_init failed\n));
return NT_STATUS_LOGON_FAILURE;
@@ -59,6 +65,7 @@
password.data = password_s;
password.length = strlen(password_s);
+#endif /* USE_KEYTAB */
ret = krb5_init_context(context);
if (ret) {
@@ -81,6 +88,16 @@
return
[PATCH] Mutual authentication, keytabs, and SMB session keys
The attach patch contains the following enhancements to HEAD:
1. Support for using Kerberos keytabs (configure with --enable-keytab)
instead of the secrets database, for the local machine password.
2. Mutual Kerberos GSS-API SPNEGO authentication.
3. Support for extracting the SMB session key from ticket session keys
(useful for named pipe services that might need access to the session
key)
Caveats: I haven't tested for MIT compat (although I have tried to avoid
any obvious breakage), and because ENCTYPE_ARCFOUR_HMAC_MD5 is an enum
in Heimdal, it should really be tested for in configure...
I have tested this patch with Windows 2000 and Windows XP clients. One
thing I didn't test is NTLMSSP over SPNEGO: hopefully I haven't broken
anything.
cheers,
-- Luke
Index: configure.in
===
RCS file: /cvsroot/samba/source/configure.in,v
retrieving revision 1.408
diff -u -r1.408 configure.in
--- configure.in19 Feb 2003 13:24:06 - 1.408
+++ configure.in23 Feb 2003 01:51:11 -
-624,6 +624,15
fi
+# support for using Kerberos keytab instead of secrets database
+
+AC_ARG_ENABLE(keytab,
+[ --enable-keytab Turn on support for Kerberos keytabs in lieu of secrets DB
(default=no)],
+[if eval test x$enable_keytab = xyes; then
+ AC_DEFINE(USE_KEYTAB,1,[Use Kerberos keytab])
+fi])
+
+
# we need dlopen/dlclose/dlsym/dlerror for PAM, the password database plugins and the
plugin loading code
AC_SEARCH_LIBS(dlopen, [dl])
# dlopen/dlclose/dlsym/dlerror will be checked again later and defines will be set
then
Index: libads/kerberos_verify.c
===
RCS file: /cvsroot/samba/source/libads/kerberos_verify.c,v
retrieving revision 1.6
diff -u -r1.6 kerberos_verify.c
--- libads/kerberos_verify.c19 Feb 2003 01:16:40 - 1.6
+++ libads/kerberos_verify.c23 Feb 2003 01:51:12 -
-3,7 +3,7
kerberos utility library
Copyright (C) Andrew Tridgell 2001
Copyright (C) Remus Koos 2001
-
+ Copyright (C) Luke Howard 2003
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
-29,14 +29,18
authorization_data if available
*/
NTSTATUS ads_verify_ticket(ADS_STRUCT *ads, const DATA_BLOB *ticket,
- char **principal, DATA_BLOB *auth_data)
+ char **principal, DATA_BLOB *auth_data,
+ DATA_BLOB *ap_rep,
+ uint8 session_key[16])
{
krb5_context context;
krb5_auth_context auth_context = NULL;
krb5_keytab keytab = NULL;
krb5_data packet;
krb5_ticket *tkt = NULL;
- int ret, i;
+ int ret;
+#ifndef USE_KEYTAB
+ int i;
krb5_keyblock * key;
krb5_principal host_princ;
char *host_princ_s;
-44,8 +48,10
char *password_s;
krb5_data password;
krb5_enctype *enctypes = NULL;
+#endif /* USE_KEYTAB */
BOOL auth_ok = False;
+#ifndef USE_KEYTAB
if (!secrets_init()) {
DEBUG(1,(secrets_init failed\n));
return NT_STATUS_LOGON_FAILURE;
-59,6 +65,7
password.data = password_s;
password.length = strlen(password_s);
+#endif /* USE_KEYTAB */
ret = krb5_init_context(context);
if (ret) {
-81,6 +88,16
return NT_STATUS_LOGON_FAILURE;
}
+#ifdef USE_KEYTAB
+ packet.length = ticket-length;
+ packet.data = (krb5_pointer)ticket-data;
+
+ if (!(ret = krb5_rd_req(context, auth_context, packet,
+ NULL, keytab, NULL, tkt))) {
+ auth_ok = True;
+ }
+
+#else
fstrcpy(myname, global_myname());
strlower(myname);
asprintf(host_princ_s, HOST/[EMAIL PROTECTED], myname, lp_realm());
-119,13 +136,30
}
}
+ SAFE_FREE(key);
+#endif /* USE_KEYTAB */
+
if (!auth_ok) {
DEBUG(3,(krb5_rd_req with auth failed (%s)\n,
error_message(ret)));
- SAFE_FREE(key);
return NT_STATUS_LOGON_FAILURE;
}
+ ret = krb5_mk_rep(context, auth_context, packet);
+ if (ret) {
+ DEBUG(3,(Failed to generate mutual authentication reply (%s)\n,
+ error_message(ret)));
+ krb5_auth_con_free(context, auth_context);
+ return NT_STATUS_LOGON_FAILURE;
+ }
+
+ *ap_rep = data_blob(packet.data, packet.length);
+ free(packet.data);
+
+ krb5_get_smb_session_key(context, auth_context, session_key);
+ DEBUG(0,(SMB session key (from ticket) follows:\n));
+ dump_data(0, session_key, 16);
+
#if 0
Re: Samba 3.0alpha21, Windows XP SP1 and Kerberos authentication
Check the sPNMappings attribute: looks like the Windows 2000 KDC maps a number of things to HOST: dn: cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=xad-0,d c=padl,dc=com sPNMappings: host=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicat or,eventlog,eventsystem,policyagent,oakley,dmserver,dns,mcsvc,fax,msiserver,i as,messenger,netlogon,netman,netdde,netddedsm,nmagent,plugplay,protectedstora ge,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclog on,scm,dcom,cifs,spooler,snmp,schedule,tapisrv,trksvr,trkwks,ups,time,wins,ww w,http,w3svc,iisadmin -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
RE: Samba 3.0alpha21, Windows XP SP1 and Kerberos authentication
I have been having this problem for a long time now. I have a few questions on how you have configured it. 1) How did you create the service principal host/machine.domain.com@REALM in Windows 2000 KDC? I created it with OpenLDAP's ldapmodify after I joined the machine to the domain. An LDIF like this should work: Interesting. According to Microsoft documentation, the servicePrincipalName can never be modified over LDAP, only over RPC. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
RE: Samba 3.0alpha21, Windows XP SP1 and Kerberos authentication
On Tue, 4 Feb 2003, Luke Howard wrote: I created it with OpenLDAP's ldapmodify after I joined the machine to the domain. An LDIF like this should work: Interesting. According to Microsoft documentation, the servicePrincipalName can never be modified over LDAP, only over RPC. Well, what can I say :) I did not actually modify an existing servicePrincipalName, I just added a new one. Does that make a difference? All the principal names Samba created are still there. Well, I have never tried it :-) I was going by the documentation at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netdir/ad/how_a_service_registers_its_spns.asp -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: heimdal didn't have AP_OPTS_USE_SUBKEY
Also, if you are going to support specific enctypes, note that Heimdal defines ENCTYPE_ARCFOUR_HMAC_MD5 rather than ENCTYPE_ARCFOUR_HMAC. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: heimdal didn't have AP_OPTS_USE_SUBKEY
Sorry, the previously posted patch was needlessly complicated.
The attached patch just contains the Kerberos-related stuff.
-- Luke
Index: configure.in
===
RCS file: /cvsroot/samba/source/configure.in,v
retrieving revision 1.397
diff -u -r1.397 configure.in
--- configure.in1 Feb 2003 11:00:39 - 1.397
+++ configure.in2 Feb 2003 12:12:47 -
@@ -2198,6 +2198,8 @@
# now see if we can find the gssapi libs in standard paths
+ AC_CHECK_LIB(gssapi, gss_display_status, [LIBS=$LIBS -lgssapi;
+ AC_DEFINE(HAVE_GSSAPI,1,[Whether GSSAPI is available])])
AC_CHECK_LIB(gssapi_krb5, gss_display_status, [LIBS=$LIBS -lgssapi_krb5;
AC_DEFINE(HAVE_GSSAPI,1,[Whether GSSAPI is available])])
Index: libads/kerberos_verify.c
===
RCS file: /cvsroot/samba/source/libads/kerberos_verify.c,v
retrieving revision 1.5
diff -u -r1.5 kerberos_verify.c
--- libads/kerberos_verify.c11 Jan 2003 03:29:31 - 1.5
+++ libads/kerberos_verify.c2 Feb 2003 12:12:48 -
@@ -3,7 +3,7 @@
kerberos utility library
Copyright (C) Andrew Tridgell 2001
Copyright (C) Remus Koos 2001
-
+ Copyright (C) Luke Howard 2003
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -29,25 +29,28 @@
authorization_data if available
*/
NTSTATUS ads_verify_ticket(ADS_STRUCT *ads, const DATA_BLOB *ticket,
- char **principal, DATA_BLOB *auth_data)
+ char **principal, DATA_BLOB *auth_data,
+ uint8 session_key[16])
{
krb5_context context;
krb5_auth_context auth_context = NULL;
krb5_keytab keytab = NULL;
krb5_data packet;
krb5_ticket *tkt = NULL;
- krb5_data salt;
- krb5_encrypt_block eblock;
int ret, i;
+#ifndef XAD
krb5_keyblock * key;
krb5_principal host_princ;
char *host_princ_s;
fstring myname;
char *password_s;
+#endif
krb5_data password;
- krb5_enctype *enctypes = NULL;
- BOOL auth_ok = False;
+ krb5_keyblock *skey;
+#ifdef XAD
+ /* We would rather use the keytab. */
+#else
if (!secrets_init()) {
DEBUG(1,(secrets_init failed\n));
return NT_STATUS_LOGON_FAILURE;
@@ -61,6 +64,7 @@
password.data = password_s;
password.length = strlen(password_s);
+#endif /* XAD */
ret = krb5_init_context(context);
if (ret) {
@@ -83,6 +87,7 @@
return NT_STATUS_LOGON_FAILURE;
}
+#ifndef XAD
fstrcpy(myname, global_myname());
strlower(myname);
asprintf(host_princ_s, HOST/%s@%s, myname, lp_realm());
@@ -92,69 +97,58 @@
return NT_STATUS_LOGON_FAILURE;
}
- ret = krb5_principal2salt(context, host_princ, salt);
- if (ret) {
- DEBUG(1,(krb5_principal2salt failed (%s)\n, error_message(ret)));
- return NT_STATUS_LOGON_FAILURE;
- }
-
if (!(key = (krb5_keyblock *)malloc(sizeof(*key {
return NT_STATUS_NO_MEMORY;
}
- if ((ret = krb5_get_permitted_enctypes(context, enctypes))) {
- DEBUG(1,(krb5_get_permitted_enctypes failed (%s)\n,
-error_message(ret)));
- return NT_STATUS_LOGON_FAILURE;
+ ret = create_kerberos_key_from_string(context, host_princ, password, key);
+ if (ret) {
+ continue;
}
- /* we need to setup a auth context with each possible encoding type in turn */
- for (i=0;enctypes[i];i++) {
- krb5_use_enctype(context, eblock, enctypes[i]);
-
- ret = krb5_string_to_key(context, eblock, key, password, salt);
- if (ret) {
- continue;
- }
+ krb5_auth_con_setuseruserkey(context, auth_context, key);
+#endif /* XAD */
- krb5_auth_con_setuseruserkey(context, auth_context, key);
+ packet.length = ticket-length;
+ packet.data = (krb5_pointer)ticket-data;
- packet.length = ticket-length;
- packet.data = (krb5_pointer)ticket-data;
-
- if (!(ret = krb5_rd_req(context, auth_context, packet,
- NULL, keytab, NULL, tkt))) {
- krb5_free_ktypes(context, enctypes);
- auth_ok = True;
- break;
- }
- }
-
- if (!auth_ok) {
+ if ((ret = krb5_rd_req(context, auth_context, packet,
+ NULL, keytab, NULL, tkt))) {
DEBUG(3,(krb5_rd_req with auth failed (%s)\n
Re: heimdal didn't have AP_OPTS_USE_SUBKEY
Please try the following patch (attached).
This patch also includes a few other things, so edit as
appropriate:
- support for the DCE NP funnel (available from
http://www.padl.com/~lukeh/XAD/dce_funnel.tar.gz)
- support for using the keytab instead of the secrets
database
- support for using RC4 Kerberos session keys as named pipe
session keys (have not tested with MIT)
You probably won't want any of these things except perhaps for
the latter, but I'm including them to meet our obligations under
the GPL.
cheers,
-- Luke
Index: Makefile.in
===
RCS file: /cvsroot/samba/source/Makefile.in,v
retrieving revision 1.606
diff -u -r1.606 Makefile.in
--- Makefile.in 1 Feb 2003 06:26:16 - 1.606
+++ Makefile.in 2 Feb 2003 00:00:36 -
@@ -228,7 +228,7 @@
RPC_SPOOLSS_OBJ = rpc_server/srv_spoolss.o rpc_server/srv_spoolss_nt.o
RPC_PIPE_OBJ = rpc_server/srv_pipe_hnd.o rpc_server/srv_util.o \
- rpc_server/srv_pipe.o rpc_server/srv_lsa_hnd.o
+ rpc_server/srv_pipe.o rpc_server/srv_lsa_hnd.o
+rpc_server/srv_dce_funnel.o
# These are like they are to avoid a dependency on GNU MAKE
@LSA_DYNAMIC_YES@RPC_MODULES1 = bin/librpc_lsarpc.@SHLIBEXT@
Index: configure.in
===
RCS file: /cvsroot/samba/source/configure.in,v
retrieving revision 1.397
diff -u -r1.397 configure.in
--- configure.in1 Feb 2003 11:00:39 - 1.397
+++ configure.in2 Feb 2003 00:00:40 -
@@ -2165,6 +2165,9 @@
AC_CHECK_LIB(krb5, krb5_auth_con_setkey,
[AC_DEFINE(HAVE_KRB5_AUTH_CON_SETKEY,1,[Whether krb5_auth_con_setkey is available])])
AC_CHECK_LIB(krb5, krb5_auth_con_setuseruserkey,
[AC_DEFINE(HAVE_KRB5_AUTH_CON_SETUSERUSERKEY,1,[Whether krb5_auth_con_setuseruserkey
is available])])
AC_CHECK_LIB(krb5, krb5_locate_kdc, [AC_DEFINE(HAVE_KRB5_LOCATE_KDC,1,[Whether
krb5_locate_kdc is available])])
+ AC_CHECK_LIB(krb5, krb5_get_permitted_enctypes,
+[AC_DEFINE(HAVE_KRB5_GET_PERMITTED_ENCTYPES,1,[Whether krb5_get_permitted_enctypes is
+available])])
+ AC_CHECK_LIB(krb5, krb5_free_ktypes, [AC_DEFINE(HAVE_KRB5_FREE_KTYPES,1,[Whether
+krb5_free_ktypes is available])])
+ AC_CHECK_LIB(krb5, krb5_get_default_in_tkt_etypes,
+[AC_DEFINE(HAVE_KRB5_GET_DEFAULT_IN_TKT_ETYPES,1,[Whether
+krb5_get_default_in_tkt_etypes is available])])
AC_CACHE_CHECK([for addrtype in krb5_address],samba_cv_HAVE_ADDRTYPE_IN_KRB5_ADDRESS,[
AC_TRY_COMPILE([#include krb5.h],
@@ -2198,6 +2201,8 @@
# now see if we can find the gssapi libs in standard paths
+ AC_CHECK_LIB(gssapi, gss_display_status, [LIBS=$LIBS -lgssapi;
+ AC_DEFINE(HAVE_GSSAPI,1,[Whether GSSAPI is available])])
AC_CHECK_LIB(gssapi_krb5, gss_display_status, [LIBS=$LIBS -lgssapi_krb5;
AC_DEFINE(HAVE_GSSAPI,1,[Whether GSSAPI is available])])
Index: include/includes.h
===
RCS file: /cvsroot/samba/source/include/includes.h,v
retrieving revision 1.295
diff -u -r1.295 includes.h
--- include/includes.h 30 Jan 2003 20:36:59 - 1.295
+++ include/includes.h 2 Feb 2003 00:00:41 -
void get_auth_data_from_tkt(DATA_BLOB *auth_data, krb5_ticket *tkt);
krb5_const_principal get_principal_from_tkt(krb5_ticket *tkt);
krb5_error_code krb5_locate_kdc(krb5_context ctx, const krb5_data *realm, struct
sockaddr **addr_pp, int *naddrs, int get_masters);
+krb5_error_code krb5_get_permitted_enctypes(krb5_context context, krb5_enctype
+**enctypes);
+void krb5_free_ktypes(krb5_context context, krb5_enctype *enctypes);
#endif /* HAVE_KRB5 */
Index: libads/kerberos_verify.c
===
RCS file: /cvsroot/samba/source/libads/kerberos_verify.c,v
retrieving revision 1.5
diff -u -r1.5 kerberos_verify.c
--- libads/kerberos_verify.c11 Jan 2003 03:29:31 - 1.5
+++ libads/kerberos_verify.c2 Feb 2003 00:00:41 -
@@ -3,7 +3,7 @@
kerberos utility library
Copyright (C) Andrew Tridgell 2001
Copyright (C) Remus Koos 2001
-
+ Copyright (C) Luke Howard 2003
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -29,15 +29,14 @@
authorization_data if available
*/
NTSTATUS ads_verify_ticket(ADS_STRUCT *ads, const DATA_BLOB *ticket,
- char **principal, DATA_BLOB *auth_data)
+ char **principal, DATA_BLOB *auth_data,
+ uint8 session_key[16])
{
krb5_context context;
krb5_auth_context auth_context = NULL;
krb5_keytab keytab = NULL;
krb5_data packet;
krb5_ticket *tkt = NULL;
- krb5_data salt;
- krb5_encrypt_block eblock;
int ret, i;
krb5_keyblock
Re: More Kerberos-related questions
My ultimate goal is to get access to a DFS (an IBM DCE application) filesystem on a Linux machine. I am dreaming of the following solution : (1) Samba server which understands Kerberos credentials and which serves up the DFS filesystem as a share(2) a Linux mount of the smbfs share and with the Linux server set up to understand Kerberos credentials. The question here would be if the smbfs client side would understand the kerberos credentials of the user? I think you could do this using delegation. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: More Kerberos-related questions
Well, FWIW, the OSF are looking into releasing the complete DCE 1.2 sources under the LGPL. Some work would be needed to get the DFS client integrated but I believe it has already been done for Linux; google for Jim Doyle's work on Linux-DCE. Doing a CIFS to DFS gateway would be cool, though. I think you could either have SAMBA forward an addressless ticket to the DFS server or have the client acquire a ticket for DFS which is included in the CIFS AP_REQ. I must confess that although I understand the concepts I don't really understand the protocols involved in ticket forwarding and delegation. -- Luke From: Steve Langasek [EMAIL PROTECTED] Subject: Re: More Kerberos-related questions To: Andrew Bartlett [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Luke Howard [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Wed, 8 Jan 2003 16:08:06 -0600 On Thu, Jan 09, 2003 at 09:03:03AM +1100, Andrew Bartlett wrote: I'm not sure why you would want to do this however, when you could just mount the DFS stuff onto Linux (I assume there is a client...). A quick web search shows me that there are DFS clients available for Linux; but perhaps there's a licensing issue? -- Steve Langasek postmodern programmer [Attachment: a2, application/pgp-signature] -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: CIFS and Kerberos question
By default, Kerberos is used for SMB authentication only. I thought I had seen some of the new Windows 2000 DCERPC pipes (FRS for example) use Kerberos encryption. Yes (and LDAP too). I meant to refer only to SMB, though. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: dynamically loadable named pipe providers
This way you would have a lot less GPL problems :-) Well, we're not doing it to get around the GPL per se; we just want to use use SMB as one of many transports for RPC. As it happens, most of the requests serviced by our RPC server come in over TCP/IP (that's ncacn_ip_tcp for the DCE geeks). If I remember correctly our idea had been a bit different. The idea was to load dynamic objects into the main smbd. All dynamic objects would reside in a special directory. A pipe is to be opened, smbd looks into a table of already loaded objects. If it's not loaded a libpipe_lsass.so (or so) is looked for and loaded on demand. This way the security issues look a lot simpler. This sounds similar to the IBM patch Anthony mentioned, except they may not have interfaced at the exact same place. We use filesystem permissions to deal with the security issues; SAMBA, LDAP, the KDC, our RPC server all form part of the TCB. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: dynamically loadable named pipe providers
Well, we're not doing it to get around the GPL per se; we just want to use use SMB as one of many transports for RPC. As it happens, most of the requests serviced by our RPC server come in over TCP/IP (that's ncacn_ip_tcp for the DCE geeks). I've recently tried to force Outlook 2000 to fall back to SMB. It worked :-) Yes, I've heard that this is the case. The point I was trying to make for the sake of argument is that one can treat SMB as transport as one would TCP/IP. This sounds similar to the IBM patch Anthony mentioned, except they may not have interfaced at the exact same place. We use filesystem permissions to deal with the security issues; SAMBA, LDAP, the KDC, our RPC server all form part of the TCB. Ah, your pipe daemons don't listen on TCP, only on unix domain sockets? The RPC server listens on ncacn_ip_tcp, ncacn_ip_udp, ncalrpc and ncacn_np endpoints. The latter is a special case, in that (in our implementation, obviously having no kernel support for NT named pipes) the RPC runtime accepts a preamble before the first RPC PDU, which contains a delegated security context. While we have implemetned named pipes on top of UNIX domain sockets, it is important to note that they are logically distinct from raw DCE RPC over domain sockets (ncalrpc). Non-named pipe clients must make a DCE RPC BIND or ALTER_CONTEXT in order to authenticate themselves to the RPC server. cheers, -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: dynamically loadable named pipe providers
The RPC server listens on ncacn_ip_tcp, ncacn_ip_udp, ncalrpc and Should be ncadg_ip_udp. Whoops. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Finding Domains in the GC (fwd)
base= objectclass=trusteddomain attrib=cn Each object will be a domain name inside the forest. From the cn attribute it's possible to guess the context of each domain (test.root.com = dc=test,dc=root,dc=com). If my understanding of the schema is correct, you should use the trustPartner attribute to determine the trusted domain name, as cn is _just_ a naming attribute. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
dynamically loadable named pipe providers
I would like to add support for dynamic loading of named pipe providers in rpc_server/srv_pipe_hnd.c. - Is anyone else working on this? - Would such a patch be accepted? -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: dynamically loadable named pipe providers
Are you looking for loadable named pipe support or just loadable RPC
support? We have a patch for the later but the former would be a
slightly different implementation.
We would just like to dynamically hook in our funnel which replaces
the make_internal_rpc_pipe_p() and pipe I/O functions. We have our
own implementations of the RPC services on \PIPE\lsass but would
like to defer to SAMBA for printing, registry, and other RPC services.
Presently the code looks roughly like:
if (strequal(pipe_name, PIPE lsass)) {
p-np_state = ncalrpc_make_funnel(pipe_name, conn, vuid);
...
} else {
p-np_state = namedpipe_create(pipe_name, conn, vuid);
...
}
Our (revised) funnel now works fairly closely to the TNG model, in
which a domain socket is opened to the RPC server and the security
context is passed as a preamble to the first RPC PDU. (Of course,
our security context token probably doesn't look the same as the
TNG one.)
We made some extensions to FreeDCE runtime to intercept this security
context token and inject it into the DCE authentication subsystem.
So, from a RPC server perspective, a named pipe client looks exactly
the same as a client that has authenticated using NTLMSSP, SPNEGO or
Kerberos.
Code is at http://www.padl.com/~lukeh/XAD/dce_funnel.tar.gz.
cheers,
-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
Private AUthentication LAyer authentication support
The attached file contains an extension to the SAMBA authentication
subsystem to support PAULA pass-through authentication. PAULA is
defined in the ActiveX/DCOM specification, at the following URL:
http://www.opengroup.org/onlinepubs/009899899
It should be refactored as a dynamically loadable plugin -- I am
told that this is trivial to do.
Note, though, that the present implementation does not encrypt
sensitive parameters with a shared secret, as required by the
specification. In our implementation, we needed a simple way of
allowing SAMBA to authenticate NTLM clients against our own DCE
RPC-based domain controller (on the same host), and wished to
avoid the configuration overhead of a shared secret. We only
accept PAULA requests that come from a trusted client on the
local machine.
-- Luke
/*
Unix SMB/CIFS implementation.
PAULA authentication implementation
Copyright (C) Luke Howard 2002
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include includes.h
#include paula.h
#undef DBGC_CLASS
#define DBGC_CLASS DBGC_AUTH
/*
* PAULA, or the Private AUthentication LAyer, is an interface for
* doing NTLM authentication on machines that don't have a fully-
* fleged LSA (eg. Unix systems).
*
* The interface is defined by Microsoft and Compaq in the DCOM
* specification available at:
* http://www.opengroup.org/onlinepubs/009899899/CHP01CHP.HTM#chap01.sect1.5
*/
static NTSTATUS check_paula_security(const struct auth_context *auth_context,
void *my_private_data,
TALLOC_CTX *mem_ctx,
const auth_usersupplied_info *user_info,
auth_serversupplied_info **server_info)
{
char Domain[64];
char Workstation[64];
char UserName[64];
char Challenge[8];
char CaseInsensitiveChallengeResponse[24];
char CaseSensitiveChallengeResponse[24];
char UserSessionKey[16];
char LanManSessionKey[8];
unsigned32 Cookie;
NTSTATUS status;
unsigned32 protocolStatus, protocolSubStatus;
if (user_info == NULL) {
return NT_STATUS_INVALID_PARAMETER;
}
if (auth_context == NULL) {
DEBUG(3, (check_paula_security: no authentication context provided
for user %s\n, user_info-internal_username.str));
return NT_STATUS_UNSUCCESSFUL;
}
if (user_info-domain.len = sizeof(Domain)) {
return NT_STATUS_BUFFER_TOO_SMALL;
}
memcpy(Domain, user_info-domain.str, user_info-domain.len + 1);
if (user_info-wksta_name.len = sizeof(Workstation)) {
return NT_STATUS_BUFFER_TOO_SMALL;
}
memcpy(Workstation, user_info-wksta_name.str, user_info-wksta_name.len + 1);
if (user_info-smb_name.len = sizeof(UserName)) {
return NT_STATUS_BUFFER_TOO_SMALL;
}
memcpy(UserName, user_info-smb_name.str, user_info-smb_name.len + 1);
if (auth_context-challenge.length sizeof(Challenge)) {
return NT_STATUS_BUFFER_TOO_SMALL;
}
memcpy(Challenge, auth_context-challenge.data,
auth_context-challenge.length);
if (user_info-lm_resp.length sizeof(CaseInsensitiveChallengeResponse)) {
return NT_STATUS_BUFFER_TOO_SMALL;
}
memcpy(CaseInsensitiveChallengeResponse, user_info-lm_resp.data,
user_info-lm_resp.length);
if (user_info-nt_resp.length sizeof(CaseSensitiveChallengeResponse)) {
return NT_STATUS_BUFFER_TOO_SMALL;
}
memcpy(CaseSensitiveChallengeResponse, user_info-nt_resp.data,
user_info-nt_resp.length);
PaulaLMLogonRequest(Cookie,
Domain,
Workstation,
UserName,
Challenge,
CaseInsensitiveChallengeResponse,
CaseSensitiveChallengeResponse,
Cookie,
protocolStatus,
protocolSubStatus,
(unsigned32 *)status,
UserSessionKey,
LanManSessionKey);
if (protocolStatus != 0) {
DEBUG(1, (check_paula_security: PaulaLMLogonRequest RPC failed (%08x
uuid_to_string() conflict
The uuid_to_string() function breaks including the OSF DCE headers in Samba (which we need for our DCE funnel) as there is a similarly named function in DCE. Any chance you could either use the same signature as the OSF DCE runtime or rename it to guid_to_string()? We can work around it with #defines but it would be nice not to. regards, -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: acctFlags/groupFlags ldap schema
Better yet is to support the sAMAccountType / userAccountControl attributes used by Active Directory. The only catch is that, for these to be useful, you really need to implement the bitwise LDAP matching rules. We implemented that for OpenLDAP, so if you're using the latest version (2.1.??) it should work. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Atomic RID allocation in LDAP
Our implementation updates the nextRid attribute in the domain entry (eg. dc=windows,dc=samba,dc=org) whenever a RID needs to be allocated. Removing the old value and adding the new one is used to guarantee atomicity. It is interesting to note that the distributed RID allocation scheme used in Active Directory is patented by Microsoft. This is only useful in a multi-master directory, though. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
[PATCH] OSF DCE RPC funnel
This is a funnel between named pipes (ncacn_np) and a TCP/IP DCE RPC server running on the local host (ncacn_ip_tcp). The OSF DCE runtime is required, because the endpoint mapper client stubs are used. You could rewrite this to not require the DCE runtime but, if you need this code, you probably already have the runtime. You should apply the patch to srv_pipe_hnd.c, and add srv_dce_funnel.c to the Makefile. Services not registered in the endpoint mapper will fall back to the SAMBA implementation. You will also need to compile with -DNCACN_IP_TCP_FUNNEL. Also, there is support for forwarding NTLM credentials via a temporary file. Thanks to the SAMBA team for making the named pipe API easy to extend! Luke Howard [EMAIL PROTECTED] PADL Software Pty Ltd August 26, 2002 dce_funnel.tar.gz Description: Binary data -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: MS's implementation of SPNEGO ...
Well, I have seen it on both the negTokenInit and negTokenTarg, and they both seem wrong. In neither case are they a MIC. Amen. It appears that they have just overloaded it. And with useless data in the case of the negTokenTarg.. As usual, behaviour rules; the spec is just a starting point... -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: MS's implementation of SPNEGO ...
The mechListMIC is an optional field. In the case that the chosen mechanism supports integrity, the initiator may optionally include a mechListMIC which is the result of a GetMIC of the MechTypes in the initial NegTokenInit and return GSS_S_COMPLETE. I haven't seen Microsoft's implementation include this field, though, except on the NegTokenTarg in which case it includes a copy of the responseToken. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: locating NETBIOS name of domain in a win2k domain
Also, there is the NetrLogonGetDomainInfo RPC, which operates over the secure channel. DsRoleGetPrimaryDomainInformation is another RPC on the Net Logon service. Ethereal should decode at least DsRoleGetPrimaryDomainInformation. -- Luke From: Gerald Carter [EMAIL PROTECTED] Subject: locating NETBIOS name of domain in a win2k domain To: Andrew Tridgell [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Fri, 4 Oct 2002 09:08:51 -0500 (CDT) Tridge, Weren't you asking about locating the netbios name of the domain in a win2k domain ? Or was this of a machine ? If the former, then look at the DsRoleGetPrimaryDomainInformation() Win32 call. I'll have the client side coded up today if it is any help to you. cheers, jerry - Hewlett-Packard http://www.hp.com SAMBA Team http://www.samba.org --http://www.plainjoe.org SAMS Teach Yourself Samba in 24 Hours 2ed. ISBN 0-672-32269-2 --I never saved anything for the swim back. Ethan Hawk in Gattaca-- -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Heimdal and 3.0
There was a fair bit of patching of the code. I can make some diffs but if someone has made a clean diff against Heimdal to add the necessary MIT functionality maybe it would be better to use that. -- luke From: Steve Shockley [EMAIL PROTECTED] Subject: Re: Heimdal and 3.0 To: [EMAIL PROTECTED] Date: Tue, 1 Oct 2002 09:29:44 -0400 I managed to convince the HEAD to compile with Heimdal with a little work, using the keytab rather than SAMBA's LSA secret repository. Haven't tested it yet, but I'm getting around to it. Thanks for the info. Did you solve it by patching the code, or was it just tweaking compile-time options? -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: nmbd cldap patch
Quick comments: s/objectSID/domainSid/ -- the netlogon attribute does not conform to the the Active Directory schema. Also, LDAP attributes are case-insensitive; don't use memcmp(). -- Luke From: Jim McDonough [EMAIL PROTECTED] Subject: nmbd cldap patch To: [EMAIL PROTECTED] Date: Fri, 27 Sep 2002 11:14:40 -0400 Here's a link to the patch that aliguori wrote and I cleaned up to respond to the connectionless ldap v3 requests for netlogon info. http://www-124.ibm.com/developer/opensource/linux/patches/?patch_id=540 I'm not so sure this belongs in nmbd, because once we respond to these, win2k clients send more variations...it could very easily get out of hand. Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984 -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Using winbind with Wine
- is the winbind team willing to standardize the protocol, or at least ensure backward compatibility in future versions? Rather than inventing new protocols, why not just use DCE RPC over domain sockets or TCP/IP? The only catch is that you need a DCE RPC client library. We're using the OSF DCE runtime (actually, FreeDCE), which is BSD-licensed. We are doing a similar thing, except in reverse, so that SAMBA can act as a named pipe front-end to our proprietary DCE RPC services. More information is at http://www.padl.com/Research/XAD.html. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Using winbind with Wine
I started thinking about other options when I found the wbinfo -n call. AFAIK there is no way to obtain equivalent info through PAM/NSS, simply because these APIs have no concept of a SID. Obviously apart from the SID there is a lot more information to gather from a PDC. I have not digged deeply enough into this to be able to enumerate everything, but think of the different GetUserInfo() calls on NT. I suspect those calls on NT ultimately call into the LSA. Sounds like it would be good if you could make RPCs to SAMBA without having to wrap them in SMB, ie. over something equivalent to ncalrpc (aka LPC on NT). What matters to wine is that if a call goes like this: Windows app - wine - PAM or other API - winbind - RPC - Windows server, we must ensure that the Unicode string wine receives from the app reaches the server ungarbled. You could use UTF-8 if you are forced through C string API. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
RE: unknown RPC opcodes during join+logon
Strangely though, if I don't align after the challenge and push a 0x006B006B (or 0x006B) before the neg_flags (= 0x0007), I could get it to work. I am not claiming that the preceding statement was very logical :-)) but it would be great if someone could verify it and at least disprove it. Isn't that just analagous to presenting different negotiation flags, assuming the IDL code on NT ignores the trailing data? -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
RE: unknown RPC opcodes during join+logon
Well, it was Luke who claimed to figure it out, and even then, from what I can tell, he could not get past the first exchange :-) Secondly, an XP client, when I switch off SignSeal, is happy with the standard 0x1FF flags that Samba returns, but does not like it when SignSeal is in force and simply stops communicating at that point. Right, there are two issues here, which can be confused by the definition of the secure channel. In Luke's book, the secure channel refers to the DCE RPC authentication flavour that is negotiated when SignAndSeal is enabled, and the normal NetLogon exchange is referred to as the NetLogon credentials chain. Microsoft use the term secure channel to refer to both these, as will I below. - if SignAndSeal is enabled, then the NetrReqChallenge() and some variant of NetrServerAuthenticate() are used to negotiate a session key, and subsequent NETLOGON RPCs are made over a new RPC connection with the rpc_c_authn_netlogon flavour (a client identifier is passed in the BIND PDU so that the server can look up the previously negotiated session key) Note that SignAndSeal exists on NT 4 (post SP4) and Windows 2000 machines and can be disabled via a registry setting. For the purposes of our testing, we have disabled it. - Windows 2000 clients call NetrServerAuthenticate3() over ncacn_ip_tcp when establishing the secure channel (which may or may not be SignAndSealed depending on registry settings) which is used for, amongst other things, PAC validation. It appears that by sending the 0x0007 flags the client is indicating that a different algorithm was used to calculate the authenticator, which is sent in the NetrServerAuthenticate3 request PDU. It appears some bits are used to indicate that a Kerberos (rather than SAM) logon should be attempted. That 0x6b flag looks important, because I seem to recall that it was the flags sent or returned by WinXP. Perhaps the AD client ignores the lower bits when SignSeal is in use. I haven't seen this, probably because I don't have WinXP. :-) But I have seen 0x0007bfff from Win2K. regards, -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
RE: unknown RPC opcodes during join+logon
But here are the results I got with changes to Samba: Odd name: credential4-byte flags = 0x0007: Access Denied Even name: credential,0x6B,0,flags=0x0007: Access Denied Odd name: credentialflags = 0x01ff: Success but servicePrincipalName attribute in Active Directory disappears Even name: credential,0x6B,0,flags=0x01ff: Success but servicePrincipalName attribute in Active Directory disappears I'm ont sure about the 0x6B but I would think that servicePrincipalName disappearing would have something to do with Active Directory presuming that downlevel clients (which negotiate 0x1ff) do not support Kerberos, and thus do not have a servicePrincipalName. You might try using the altSecurityIdentities attribute instead, eg: altSecurityIdentities: Kerberos:cifs/foobar.windows2000.spinnakernet.com -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: unknown RPC opcodes during join+logon
The return code always follows the last top-level [out] value, but there is an additional [out] ULONG in NetrServerAuthenticate3. The algorithm for calculating credentials is the same. Actually, I'm no longer sure this is the case. It seems that the algorithm for NetrServerAuthenticate3 is the same if the client thinks the domain is an NT4 domain (in which case it talks to it over SMB), but it looks like the algorithm is different in a Windows 2000 domain (where the RPC is made over ncacn_ip_tcp), as unlikely as this seems (given they are the same RPC). Note that the flags are ostensibly irrelevant, because the client sends the authenticator before it receives the flags from the server. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Problems with WinXP joining a Samba-head domain (and suggested solutions)
Hi Richard, 2. Then, once this was fixed, WinXP still would not join. I needed to switch off SignOrSeal as specified in the .reg file. Right, otherwise it will try and negotiate the Netlogon secure channel (or the secure Netlogon secure channel, depending on whose terminology you're using). Last time I looked, the secure channel bind PDU included the NetBIOS name, the workstation name, and the DNS domain name and host, which are presumably used by the server as a key to retrieve the session key previously negotiated by NetrReqChallenge() and NetrServerAuthenticate3(). The session key is used to sign/seal the channel (roughly per draft-brezak-win2k-krb-rc4-hmac-04.txt). I didn't take note of how these were encoded (whether they were Unicode strings, etc). Let me know if you have any traces, as we'd like to implement this in GSS-API (along with NTLMSSP). Of course, I could just turn SignOrSeal back on and get some traces myself :-) cheers, -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: Problems with WinXP joining a Samba-head domain (and suggested solutions)
Well, the interesting thing to me is that WinXP managed to join with Sign/Seal enabled, but failed on the first logon attempt. At least with Windows 2000 joining Active Directory (which is what we're testing right now) the domain join doesn't seem to mind if the NetrServerAuthenticate() / NetrLogonGetDomainInfo() fails. As long as the LSA and SAM RPCs that are made over SMB succeed, the client thinks that it has joined. This failure seems to occur after Samba responds SUCCESS to ServerAuthenticate2, but, I suspect, with the wrong bits. I noticed that XP includes at least one new flag bit that Win2K does not send. Interesting, which one is this? I surmise that it was some bit not set in the result flags that Samba returns, as it still returns 0X1FF. According to Luke Leighton's book 0x4000 is the Secure Channel flag. Presumably if the client is configured to _require_ SignOrSeal, then if this bit is not negotiated it will fail. Other bits appear to determine whether the client uses Kerberos or NT 4 RPCs for domain logon. A Windows 2000 sends 0x6007. Last time I looked, the secure channel bind PDU included the NetBIOS name, the workstation name, and the DNS domain name and host, which are presumably used by the server as a key to retrieve the session key previously negotiated by NetrReqChallenge() and NetrServerAuthenticate3(). The session key is used to sign/seal the channel (roughly per draft-brezak-win2k-krb-rc4-hmac-04.txt). I didn't take note of how these were encoded (whether they were Unicode strings, etc). Hmmm, that is interesting. It makes sense, and some of this is implemented in TNG (not sure whether it works or not). It's an interesting abstraction violation to consider how the session key gets passed to the RPC authentication layer; we did it with a callback in the Schannel GSS-API mechanism to the NETLOGON server. (By Schannel, I'm referring to the Netlogon secure channel, not Microsoft's SSL/TLS encapsulation within GSS-API; the nomenclature is confusing.) These might be interesting. I might not have enough VMware engines to test this all out. Huh, VMware and Ethereal are definitely the tools of the trade here :-) It might be interesting to implement SIGN/SEAL ... for a number of reasons. Well, the best reason is being able to work with out-of-the-box clients, regardless of whether we're talking about NT 4-style domain logon or Active Directory. Note that Active Directory clients still use the Netlogon credentials chain / secure channel for, amongst other things, verifying the PAC signatures (as completely unnecessary as this is from an architectural standpoint). OTOH, from a resourcing point of view, there are other interoperability hurdles that we need to resolve before we look at finishing our implementation of this (which doesn't use SAMBA anyway, so it's probably off-topic here). regards, -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: Problems with WinXP joining a Samba-head domain (and suggested solutions)
Well, I see the NetBIOS name, wks name, DNS domain name, etc in the SPNEGO negTokenTarg in the security BLOB. I have not noticed it in the BIND PDU. I will have to go and look. I'm talking about rpc_c_authn_netlogon (68) not rpc_c_authn_gss_negotiate (9). Unless you're saying that the secure channel is negotiated over SPNEGO? I haven't seen that before, I'd like to know what OID they use. -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: unknown RPC opcodes during join+logon
I think the uint32 is the return code since I have 0xC022 (access denied) from my trace. My question is regarding this. Is the algorithm for calculating client credentials in Authenticate3 different from the one in Authenticate2? If so, can somebody give me pointers to where I can find the algo ? The return code always follows the last top-level [out] value, but there is an additional [out] ULONG in NetrServerAuthenticate3. The algorithm for calculating credentials is the same. -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: Problems with WinXP joining a Samba-head domain (and suggested solutions)
OK, I can see them in the Auth Data. Ethereal does not break that out as yet. It looks like two UINT32s and two ASCII strings. Not sure. What I see is 00 00 00 00 03 00 00 00 F O O 00 F O O - B D C 00 Hmm, I think we saw the same thing but 0x17 instead of 0x03. You would think that Unicode names would be supported (unless this is UTF-8), I wonder if 0x03 is some sort of capability flag... What is returned in the bind response? Unless you're saying that the secure channel is negotiated over SPNEGO? I haven't seen that before, I'd like to know what OID they use. I don't know. The trace I have does not include the session setup, so I can't see what was negotiated. The auth data in the bind PDU is the session setup, at least for the purposes of this discussion. The verifier in subsequent PDUs, from what I've heard, is similar to the rc4-hmac GSS_Wrap() except with a token header of 0x77 0x00 0x7a 0x00 0xff 0xff 0x00 0x00 -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: Problems with WinXP joining a Samba-head domain (and suggested solutions)
What is returned in the bind response? An array of 8 nonce bytes if memory serves well. Hmm, maybe that is used to generate a subkey so the credential chain session key is not over-used. -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: Any traces with sign and seal and secure channel?
Does anyone have any traces showing secure channel, sign and seal, etc. No, but after implementing the rc4-hmac GSS-API sign/seal mechanism (as defined in John Brezak's draft) and reading Luke Leighton's notes on the NETLOGON secure channel, there appear to be a number of similarities. -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: GSSAPI Kerberos mechanism
I think that this document is close to defining the format of KRB5
requests in GSSAPI/SPNEGO
Alternatively, see The Kerberos Version 5 GSS-API Mechanism,
RFC 1964. There may be a WG update somewhere...
-- Luke
1.1. Context Establishment Tokens
Per RFC-1508, Appendix B, the initial context establishment token
will be enclosed within framing as follows:
InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMechMechType
-- MechType is OBJECT IDENTIFIER
-- representing Kerberos V5
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific;
-- ASN.1 usage within innerContextToken
-- is not required
}
The innerContextToken of the initial context token will consist of a
Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id
(TOK_ID) field, which shall contain the value 01 00.
The above GSS-API framing shall be applied to all tokens emitted by
the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR,
context-deletion, and per-message tokens, not just to the initial
token in a context establishment sequence. While not required by
RFC-1508, this enables implementations to perform enhanced error-
checking. The innerContextToken field of context establishment tokens
for the Kerberos V5 GSS-API mechanism will contain a Kerberos message
(KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID
field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP
messages and 03 00 for KRB_ERROR messages.
--
Luke Howard | lukehoward.com
PADL Software | www.padl.com
Re: [jcifs] Re: Win2K: Primary Domain Fld of Ssn Setup Not Proper ly Zero Term'd
This deserves further comment, because it demeans the fine detective work that the Extreme Blue team did in figuring out the details of the new RPCs and how to set up OpenLDAP so Samba can function as an AD Domain Controller. Sure, IBM have been very helpful. We've got some changes to OpenLDAP to support controls, matching rules, syntaxes, ms-cldap, the Netlogon virtual attribute, schema loading, which we'll be releasing shortly. Please note though that there is a *lot* more work necessary to make SAMBA (or indeed anything else) function as an Active Directory domain controller. cheers, -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: [jcifs] Re: Win2K: Primary Domain Fld of Ssn Setup Not Proper ly Zero Term'd
technically, the pipe split was at the RPC PDU layer. not arbitrary support for loading a named pipe module. We still have a hard coded path for supported pipe names. It was just the RPC functions that got split out. This is good from a SQA perspective but maybe not so much for supporting other named pipes (that will come later). Well, the next thing I plan to do with the DCE funnel is provide the option to fall back to SAMBA implementations for services not registered in the endpoint mapper. Although there is an initial cost in decoding the IDL for NT services and debugging the interoperability of the OSF DCE runtime, it's real nice to be able to have all the marshalling and unmarshalling taken care of by an IDL compiler, be able to support RPC directly over IP (as required by Windos 2000) and yet still have SAMBA funnel over named pipe RPCs. :-) -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: [jcifs] Re: Win2K: Primary Domain Fld of Ssn Setup Not Proper ly Zero Term'd
Oh, and the aforementioned funnel still relies on SAMBA's internal mapping of pipe names to UUIDs. It's a start, though... -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: SPNEGO and multiple authentication types ...
Am I right in thinking that SPNEGO allows for multiple authentication types by including multiple OIDs, for example KRB5, NTLMSSP, NTLM, etc? Yes, for example the following OIDs are included in a DCE RPC SPNEGO authentication: 24 069: OBJECT IDENTIFIER '1 2 840 48018 1 2 2' 35 069: OBJECT IDENTIFIER '1 2 840 113554 1 2 2' 46 06 10: OBJECT IDENTIFIER '1 2 840 113554 1 2 2 3' 58 06 10: OBJECT IDENTIFIER '1 3 6 1 4 1 311 2 2 10' The first is Microsoft's bodged Kerberos OID, which appears to be used in the SPNEGO negotiation only. The next is the real Kerberos OID. Not sure about the one afther that. The final one is NTLMSSP. -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: unknown RPC opcodes during join+logon
0x1A may be NetrServerAuthenticate3(). yes it can be, it's very close to NetrServerAuthenticate2(), at least the query are the same. There a uint32 of difference in the reply. Here are the two prototypes from our netlogon IDL file (slightly edited): NTSTATUS NetrServerAuthenticate2( [in] LOGONSRV_HANDLE ServerName, [in] LPWSTR UserName, [in] /* enum */ NETLOGON_SECURE_CHANNEL_TYPE SecChan, [in] LPWSTR ComputerName, [in] NETLOGON_CREDENTIAL *ClientChal, [out] NETLOGON_CREDENTIAL *ServerChal, [in, out] ULONG *Flags ); NTSTATUS NetrServerAuthenticate3( [in] LOGONSRV_HANDLE ServerName, [in] LPWSTR UserName, [in] NETLOGON_SECURE_CHANNEL_TYPE SecChan, [in] LPWSTR computer_name, [in] NETLOGON_CREDENTIAL *ClientChal, [out] NETLOGON_CREDENTIAL *ServerChal, [in, out] ULONG *Flags, [out] ULONG *Unknown ); You're correct about the additional uint32; not sure what this is yet but IIRC it was set to zero in the trace we saw. nope. I've got a trace with a w2k joining a w2k domain with kerberos disabled, and i still get the NETLOGON 0X1D. I think it's a variant of the NetrSamLogon() call. Hmm. The variant should be NetrLogonSamLogonEx(); the best candidate I could find was opcode 0x27, which seems to make sense for Kerberos as it doesn't take an NTLM authenticator, but it does take a NETLOGON_INFO query and return a NETLOGON_VALIDATION (one of the info levels for which is definitely a PAC verifier according to Ethereal). But I'm not sure whether anyone has actually seen this RPC. OTOH while we know the layout of the structures passed to and from 0x1D, the contents are not yet clear. Time to get a new trace with signseal disabled. Yes, please send one if you have it. cheers, -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: [FYI] samba_2_2 openLdap 2.1.3 and the auxiliary/structural objects
How should we handle this within Samba? Should we create a new user with a person objectClass and a sambaAccount (assuming an applicable non-sambaAccount object doesn't exist, of course). This does simplify some things (we can take cn out of the sambaAccount) but adds the (possible) difficulty of requiring an sn (which, btw is lacking from your example of a correct ldif, so you might want to fix that). It's been a while since I last looked at the samba attribubtes - LDAP mapping, so I don't remember if there is already something suitable for sn or not. The fact that sn is required is a constant annoyance. :-) It's good to use person or a subclass thereof for compatibility with white pages-type clients (e-mail address books, etc). The Active Directory User object class is also derived from person. Here however, it is perhaps better that the user of person as a structural object class is best left to administrators. SAMBA can just add the sambaAccount auxiliary object class to such entries. In the case where there is no existing entry, then SAMBA should probably use the account structural object class which only requires the uid attribute. See section 5.3 of RFC 2307. -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com
Re: New approach to win2k joins...
Last time I looked, Windows 2000 defines a number of different Kerberos principal name types that needed to be supported by the KDC, eg. KRB5_NT_MS_PRINCIPAL, KRB5_NT_ENTERPRISE_PRINCIPAL. -- Luke From: Jim McDonough [EMAIL PROTECTED] Subject: Re: New approach to win2k joins... To: Jean Francois Micouleau [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Mon, 5 Aug 2002 18:51:56 -0400 But when I try to logon, it tries to use the short version of the domain as the realm...which my MIT KDC doesn't like. Any ideas here? when is it supposed to get the realm ? are you sure it's getting it correctly ? I'm not sure exactly what your question is, but this is exactly how a win2k -win2k interaction is. If there is a short (netbios) domain name that shows up in the logon screen, that's what gets sent as the realm for the principal to the KDC...and the tgt that is returned has the full true realm name in the principal...! do you have a trace of a user logging on the box ? I can give you this or the equivalent in win2k-win2k, and you'll see the realm thing I'm talking about... Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984 -- Luke Howard | lukehoward.com PADL Software | www.padl.com
