RE: Can't enumerate user list from WinXP -- samba-3.0alpha21
Win2k doesn't reply sids set just because WinXP doesn't request owner and group sids. You can check the "Securify Information" field of Win2k packet #201. In Samba3.0 alpha21, I have check the code. We don't check this field, always return owner and group sids. I have ever tried to return the same format as Win2k to WinXP, but it still couldn't enumerate user and group list when I tried to add new acl entry. -Original Message- From: Esh, Andrew [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 12:11 AM To: 'Richard Sharpe'; Vich Cc: [EMAIL PROTECTED] Subject: RE: Can't enumerate user list from WinXP -- samba-3.0alpha21 I don't think the Win2K example needs to look up user info. I wonder if this is really a correct comparison. I noticed that the example file being opened on FreeBSD has an owner and group sid: root.wheel, while the win2k capture shows a file with a zero offset for the sids, and no sids set. Compare Win2K packet #202 with FreeBSD packet #274. Either the missing user lookup is not the problem, or if it is, the problem may be that the Win2K file does not have enough security info on it to require a lookup. This needs more characterization.
Re: [Samba] limits question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 14 Feb 2003, William Jojo wrote: > > > what do the following values in local.h do with respect to a single smbd > or are they absolute limits? please explain... > > #define MAX_DIRECTORY_HANDLES 2048 > > #define MAX_OPEN_DIRECTORIES 256 > > #define MAX_OPEN_PIPES 2048 single smbd limits. Mostly upper boundaries on internal data structures. Also prevent DoS attacks from clients wanting to consume all the memory on the server. cheers, jerry -- Hewlett-Packard- http://www.hp.com SAMBA Team -- http://www.samba.org GnuPG Key http://www.plainjoe.org/gpg_public.asc "You can never go home again, Oatman, but I guess you can shop there." --John Cusack - "Grosse Point Blank" (1997) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE+WuQeIR7qMdg1EfYRAhJyAJ9omkvFN4h5XWnSmuHPnyImHaXYLQCg5i1C IfdpNK9zKltVEr+KSirZTKY= =nH06 -END PGP SIGNATURE-
RE: Can't enumerate user list from WinXP -- samba-3.0alpha21
Win2k doesn't reply sids set just because WinXP doesn't request owner and group sids. You can check the "Securify Information" field of Win2k packet #201. In Samba3.0 alpha21, I have check the code. We don't check this field, always return owner and group sids. I have ever tried to return the same format as Win2k to WinXP, but it still couldn't enumerate user and group list when I tried to add new acl entry. -Original Message- From: Esh, Andrew [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 12:11 AM To: 'Richard Sharpe'; Vich Cc: [EMAIL PROTECTED] Subject: RE: Can't enumerate user list from WinXP -- samba-3.0alpha21 I don't think the Win2K example needs to look up user info. I wonder if this is really a correct comparison. I noticed that the example file being opened on FreeBSD has an owner and group sid: root.wheel, while the win2k capture shows a file with a zero offset for the sids, and no sids set. Compare Win2K packet #202 with FreeBSD packet #274. Either the missing user lookup is not the problem, or if it is, the problem may be that the Win2K file does not have enough security info on it to require a lookup. This needs more characterization.
Re: [PATCH] Re: 3.0a21: "net ads lookup" for a child domain gotmessyoutput
The 0xc018 and 0xc022 are most likely string deliminators and a one byte
flag. This makes sense since it always seems to be either 0xc018 or 0xc022
(0xc022 == 0xc018 | 0x04) What the meaning of these flags is remains to be
seen.
The net ads lookup code is really out of date anyway. I've construct a
patch that reworks most of the parsing such and I think we're at a point
where every field we have a least a pretty good guess as to what it is.
I'll submit the patch once I get an opportunity to test it.
Anthony Liguori
Linux/Active Directory Interoperability
Linux Technology Center (LTC) - IBM Austin
E-mail: [EMAIL PROTECTED]
Phone: (512) 838-1208
Tie Line: 678-1208
Chere Zhou
<[EMAIL PROTECTED]To: Anthony
Liguori/Austin/[EMAIL PROTECTED]
>cc: [EMAIL PROTECTED]
Subject: [PATCH] Re: 3.0a21: "net ads
lookup" for a child
02/24/2003 02:00 domain got messy output
PM
Please respond to
qzhou
With the following patch, it works for me now. However, there are still
mysteries like what 0xc018 and 0xc022 means in the received netlogon
responses. My fix is to split the "domain" into "forest" and "domain",
where
the new "domain" is the child/grandchild under "forest". The ultimate
domain
name should be domain+'.'+forest.
Even if this does not go into the sources eventually, I hope it can be
helpful for other people who had the same problem as I did.
Chere
--- utils/net_ads_cldap.c.orig Fri Feb 21 15:34:18 2003
+++ utils/net_ads_cldap.c Mon Feb 24 11:27:47 2003
@@ -27,6 +27,7 @@
uint32 version;
uint32 flags;
GUID guid;
+char *forest;
char *domain;
char *server_name;
char *domain_flatname;
@@ -42,11 +43,13 @@
*/
static unsigned pull_len_string(char **ret, const char *p)
{
- unsigned len = *p;
+ unsigned char len = *p;
(*ret) = NULL;
if (len == 0) return 1;
+ if ((len == 0xc0) && ((unsigned char)(*(p+1)) == 0x18))
+ return 1;
(*ret) = smb_xstrndup(p+1, len);
- return len+1;
+ return (unsigned)(len+1);
}
/*
@@ -194,8 +197,13 @@
reply->flags = IVAL(p, 0); p += 4;
memcpy(&reply->guid.info, p, GUID_SIZE);
p += GUID_SIZE;
- p += pull_dotted_string(&reply->domain, p);
- p += 2; /* 0xc018 - whats this? */
+ p += pull_dotted_string(&reply->forest, p);
+ if ((unsigned char)*p == 0xc0)
+ p += 2; /* 0xc018 - whats this? */
+ else {
+ p += pull_dotted_string(&reply->domain, p);
+ p += 1;
+ }
p += pull_len_string(&reply->server_name, p);
p += 2; /* 0xc018 - whats this? */
p += pull_len_string(&reply->domain_flatname, p);
@@ -218,6 +226,7 @@
*/
static void cldap_reply_free(struct cldap_netlogon_reply *reply)
{
+ SAFE_FREE(reply->forest);
SAFE_FREE(reply->domain);
SAFE_FREE(reply->server_name);
SAFE_FREE(reply->domain_flatname);
@@ -258,6 +267,7 @@
d_printf("GUID: ");
print_guid(&reply.guid);
d_printf("Flags: 0x%x\n", reply.flags);
+ d_printf("Forest root: %s\n", reply.forest);
d_printf("Domain: %s\n", reply.domain);
d_printf("Server Name: %s\n", reply.server_name);
d_printf("Flatname: %s\n", reply.domain_flatname);
[PATCH] Re: 3.0a21: "net ads lookup" for a child domain got messyoutput
With the following patch, it works for me now. However, there are still
mysteries like what 0xc018 and 0xc022 means in the received netlogon
responses. My fix is to split the "domain" into "forest" and "domain", where
the new "domain" is the child/grandchild under "forest". The ultimate domain
name should be domain+'.'+forest.
Even if this does not go into the sources eventually, I hope it can be
helpful for other people who had the same problem as I did.
Chere
--- utils/net_ads_cldap.c.orig Fri Feb 21 15:34:18 2003
+++ utils/net_ads_cldap.c Mon Feb 24 11:27:47 2003
@@ -27,6 +27,7 @@
uint32 version;
uint32 flags;
GUID guid;
+char *forest;
char *domain;
char *server_name;
char *domain_flatname;
@@ -42,11 +43,13 @@
*/
static unsigned pull_len_string(char **ret, const char *p)
{
- unsigned len = *p;
+ unsigned char len = *p;
(*ret) = NULL;
if (len == 0) return 1;
+ if ((len == 0xc0) && ((unsigned char)(*(p+1)) == 0x18))
+ return 1;
(*ret) = smb_xstrndup(p+1, len);
- return len+1;
+ return (unsigned)(len+1);
}
/*
@@ -194,8 +197,13 @@
reply->flags = IVAL(p, 0); p += 4;
memcpy(&reply->guid.info, p, GUID_SIZE);
p += GUID_SIZE;
- p += pull_dotted_string(&reply->domain, p);
- p += 2; /* 0xc018 - whats this? */
+ p += pull_dotted_string(&reply->forest, p);
+ if ((unsigned char)*p == 0xc0)
+ p += 2; /* 0xc018 - whats this? */
+ else {
+ p += pull_dotted_string(&reply->domain, p);
+ p += 1;
+ }
p += pull_len_string(&reply->server_name, p);
p += 2; /* 0xc018 - whats this? */
p += pull_len_string(&reply->domain_flatname, p);
@@ -218,6 +226,7 @@
*/
static void cldap_reply_free(struct cldap_netlogon_reply *reply)
{
+ SAFE_FREE(reply->forest);
SAFE_FREE(reply->domain);
SAFE_FREE(reply->server_name);
SAFE_FREE(reply->domain_flatname);
@@ -258,6 +267,7 @@
d_printf("GUID: ");
print_guid(&reply.guid);
d_printf("Flags: 0x%x\n", reply.flags);
+ d_printf("Forest root: %s\n", reply.forest);
d_printf("Domain: %s\n", reply.domain);
d_printf("Server Name: %s\n", reply.server_name);
d_printf("Flatname: %s\n", reply.domain_flatname);
Re: Recovery from Domain/WINS Outage - Didn't work well
"Hall, Ken (ECSS)" wrote: > > We're using Samba 2.2.5 and 2.2.7 in SECURITY=DOMAIN mode. > > This morning we lost contact with our PDC, and for about 2 hours, users > were unable to logon. After chasing this down, we determined that we > were also unable to contact the WINS server defined in smb.conf. Our > backup WINS server was available, but it seems Samba only supports one > WINS server in smb.conf, so this didn't help much. After manually > switching to the other WINS server, we were able to connect. WINS failover has been implemented. It may, however, only be available in the 3.0 beta. I am not sure. I wrote the original implementation but Tridge came up with a (much) better way to handle this. > We're still new with this, and so far Samba isn't looking too reliable to > our management. This is the second time a WINS-related problem has > knocked us down while the Windows servers remained available. Was the missing WINS server a Samba server or a Windows box? In all seriousness, we did not bother implementing WINS failover because the Samba-based WINS servers generally didn't go down. The decision to add it came from pressure from people who used Samba in a primarily Windows environment. > I'm assuming we're still only allowed to specify a single WINS server. > Does anyone have any idea if this will be fixed anytime soon? You might try putting in two IP addresses separated by a colon. The first will be the primary and the second the secondary WINS server. The code that makes this work is in 2.2.7 *but it was not completed* so it was left undocumented. It is a beta feature in 2.2.x. > Should Samba have recovered from the DC outage? It appears that after > losing contact with the DC, it went back to WINS, and tried to get a new > list. Does it only try the first DC on the list, or does it work down > till it finds a good one? Am I correct in assuming that being unable to > connect to the WINS server would prevent this from happening? When a client sends a query for a <1C> name the Windows WINS server responds by sending a list of IPs. This is correct per the RFCs, but unusual for WINS (Microsoft's original implementation was kludged such that it replies to group name queries by sending only the limited broadcast address: 255.255.255.255). Anyway, the first entry in the list of <1C> names is the PDC. All others are BDCs. > Thanks in advance for any info you can provide. Hope that's somewhat useful. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
RE: Nasty OU names - patch to ldap.c
In reply to myself:
That's not a very general solution. You run into the same problem if
the OU string contains "/".
I see two possibilities: supply the full OU string (yuck), or provide
some means to escape characters.
Any better ideas?
Ken
Ken Cross
Network Storage Solutions
Phone 865.675.4070 ext 31
[EMAIL PROTECTED]
> -Original Message-
> From:
> [EMAIL PROTECTED]
>
> [mailto:[EMAIL PROTECTED]
> amba.org] On Behalf Of Ken Cross
> Sent: Monday, February 24, 2003 12:30 PM
> To: 'Multiple recipients of list SAMBA-TECHNICAL'
> Subject: Nasty OU names - patch to ldap.c
>
>
> Samba-folk:
>
> I've run into a problem using "net ads join OU", where OU is an
> Organizational Unit.
>
> An OU can have virtually any name, e.g., "Planes, Trains, &
> Automobiles". When returned from the Active Directory, it's
> in the form
> "Planes\, Trains\, & Automobiles". That's the only form that it will
> accept when specifying the OU.
>
> When passed to net in this form, ads_ou_string uses "\" as a
> separator.
> I'm not sure of the reason for this, but it makes it impossible to
> specify the OU above.
>
> A simple patch (shown below for SAMBA_3_0) removes this, but
> leaves the
> "/" separator. Now this OU works.
>
> Anybody know if this will break something?
>
> Ken
>
>
> Ken Cross
>
> Network Storage Solutions
> Phone 865.675.4070 ext 31
> [EMAIL PROTECTED]
>
>
>
>
> Index: ldap.c
> ===
> RCS file: /cvsroot/samba/source/libads/ldap.c,v
> retrieving revision 1.55.2.22
> diff -p -u -r1.55.2.22 ldap.c
> --- ldap.c 24 Feb 2003 03:43:49 - 1.55.2.22
> +++ ldap.c 24 Feb 2003 17:21:15 -
> @@ -1015,7 +1015,7 @@ char *ads_ou_string(const char *org_unit
> return strdup("cn=Computers");
> }
>
> - return ads_build_path(org_unit, "\\/", "ou=", 1);
> + return ads_build_path(org_unit, "/", "ou=", 1); /*
> KJC - removed
> \\ from separators */
> }
>
>
>
Re: [Samba] Recovery from Domain/WINS Outage - Didn't work well
On Mon, 24 Feb 2003, Hall, Ken (ECSS) wrote: > We're using Samba 2.2.5 and 2.2.7 in SECURITY=DOMAIN mode. > > This morning we lost contact with our PDC, and for about 2 hours, users > were unable to logon. After chasing this down, we determined that we > were also unable to contact the WINS server defined in smb.conf. Our > backup WINS server was available, but it seems Samba only supports one > WINS server in smb.conf, so this didn't help much. After manually > switching to the other WINS server, we were able to connect. > > We're still new with this, and so far Samba isn't looking too reliable > to our management. This is the second time a WINS-related problem has > knocked us down while the Windows servers remained available. > > I'm assuming we're still only allowed to specify a single WINS server. > Does anyone have any idea if this will be fixed anytime soon? Yes, in Samba-3.0.0 which is currently in Alpha test. Should be released around April. You might want to download it and try it before then. We can do with your feedback. > > Should Samba have recovered from the DC outage? It appears that after > losing contact with the DC, it went back to WINS, and tried to get a new > list. Does it only try the first DC on the list, or does it work down > till it finds a good one? Am I correct in assuming that being unable to > connect to the WINS server would prevent this from happening? If Samba can not resolve the netbios name to an IP address then obviously it can not find the machine it needs to communicate with. If WINS goes down, then in effect you can be hosed. - John T. -- John H Terpstra Email: [EMAIL PROTECTED]
Nasty OU names - patch to ldap.c
Samba-folk:
I've run into a problem using "net ads join OU", where OU is an
Organizational Unit.
An OU can have virtually any name, e.g., "Planes, Trains, &
Automobiles". When returned from the Active Directory, it's in the form
"Planes\, Trains\, & Automobiles". That's the only form that it will
accept when specifying the OU.
When passed to net in this form, ads_ou_string uses "\" as a separator.
I'm not sure of the reason for this, but it makes it impossible to
specify the OU above.
A simple patch (shown below for SAMBA_3_0) removes this, but leaves the
"/" separator. Now this OU works.
Anybody know if this will break something?
Ken
Ken Cross
Network Storage Solutions
Phone 865.675.4070 ext 31
[EMAIL PROTECTED]
Index: ldap.c
===
RCS file: /cvsroot/samba/source/libads/ldap.c,v
retrieving revision 1.55.2.22
diff -p -u -r1.55.2.22 ldap.c
--- ldap.c 24 Feb 2003 03:43:49 - 1.55.2.22
+++ ldap.c 24 Feb 2003 17:21:15 -
@@ -1015,7 +1015,7 @@ char *ads_ou_string(const char *org_unit
return strdup("cn=Computers");
}
- return ads_build_path(org_unit, "\\/", "ou=", 1);
+ return ads_build_path(org_unit, "/", "ou=", 1); /* KJC - removed
\\ from separators */
}
Recovery from Domain/WINS Outage - Didn't work well
We're using Samba 2.2.5 and 2.2.7 in SECURITY=DOMAIN mode. This morning we lost contact with our PDC, and for about 2 hours, users were unable to logon. After chasing this down, we determined that we were also unable to contact the WINS server defined in smb.conf. Our backup WINS server was available, but it seems Samba only supports one WINS server in smb.conf, so this didn't help much. After manually switching to the other WINS server, we were able to connect. We're still new with this, and so far Samba isn't looking too reliable to our management. This is the second time a WINS-related problem has knocked us down while the Windows servers remained available. I'm assuming we're still only allowed to specify a single WINS server. Does anyone have any idea if this will be fixed anytime soon? Should Samba have recovered from the DC outage? It appears that after losing contact with the DC, it went back to WINS, and tried to get a new list. Does it only try the first DC on the list, or does it work down till it finds a good one? Am I correct in assuming that being unable to connect to the WINS server would prevent this from happening? Thanks in advance for any info you can provide.
RE: Can't enumerate user list from WinXP -- samba-3.0alpha21
I don't think the Win2K example needs to look up user info. I wonder if this is really a correct comparison. I noticed that the example file being opened on FreeBSD has an owner and group sid: root.wheel, while the win2k capture shows a file with a zero offset for the sids, and no sids set. Compare Win2K packet #202 with FreeBSD packet #274. Either the missing user lookup is not the problem, or if it is, the problem may be that the Win2K file does not have enough security info on it to require a lookup. This needs more characterization. > -Original Message- > From: Richard Sharpe [mailto:[EMAIL PROTECTED] > Sent: Monday, February 24, 2003 1:25 AM > To: Vich > Cc: [EMAIL PROTECTED] > Subject: RE: Can't enumerate user list from WinXP -- samba-3.0alpha21 > > > On Mon, 24 Feb 2003, Vich wrote: > > > Hi Richard, > > > > Thanks for your reply. I have captured the packets you need. > > This is my network environment. > > > > WinXP (vich-xp 192.168.101.174/255.255.0.0) > > Win2k (vich-dev 192.168.101.247/255.255.0.0) > > FreeBSD (vich-test 192.168.100.251/255.255.0.0) > > > > I captured the packets and saved them to "FreeBSD.cap" when > > I used WinXP to connect to FreeBSD, right-click a shred service > > to get ACL information, click Add button to try to add a new entry, > > and click Search now button to get all entries that I could add. I > > did the same steps when I used WinXP to connect Win2k box > > and saved them to "Win2k.cap". > > I have looked at these, and can see that there are > differences in the set > of SAMR calls that WinXP sends to Win2K vs Samba/FreeBSD. In > particular, > with Win2K, WinXP does a QueryDispInfo after an OpenDomain > S-1-5-21-x-y-z, > while against Samba/FreeBSD, WinXP does not do that. > > I will have to try it myself from a WinXP client to Samba. > > Regards > - > Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, > sharpe[at]ethereal.com, http://www.richardsharpe.com >
Re: mount points / free disk space / dfree command
On Thu, 20 Feb 2003, Panko, Kevin wrote: > We have a share with mount points beneath it. Free disk space is incorrect > because samba always returns the free space in the top level directory of > the share. It is the same problem discussed before in this thread: > > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&th=4c04c4aeb2405 > d4d&seekm=9q2iee%242s7r%241%40FreeBSD.csie.NCTU.edu.tw&frame=off > > I was hoping to use the dfree command smb.conf option, as the "df" command > reports the correct amount of free space for each subdirectory. I found > that my dfree command was always given the directory name of the top level > of the share, regardless of the current directory on the Win2k client, so > the answer I get with dfree is the same as the internal samba routines. > > Why does that happen? Does the QUERY_FS_INFO trans2 call have knowledge of > the current directory of the client, or is that not included in the client's > request? If not, then I must admit that this may be impossible. If it > does, and if that > directory were passed to the df command, then what I need can be done via > samba. This raises a slightly wider question, of which yours is one case. Another case, already handled, is when the samba server (typically UNIX) has user quotas. Samba's behaviour is to let any individual user-quota override its normal "df-for-whole-volume" behaviour. Also the "smb.conf" file does allow an alternative command to be specified and run. (This might be an immediate way for you to address your particular issue, although I get the feeling, possibly wrongly, that this option might be regarded in the as "try to avoid if reasonably possible" or "at your own risk" etc.) Now pulling all that together and looking at the wider question... I wonder whether there is a case for reshaping this functionality into VFS modules in the VFS stack? The default would still be "df" behaviour, but there might be a VFS/quota module, which could act as a model for other free-space modules. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
[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" = x"yes"; 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_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" = x"yes"; 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
On Mon, Feb 24, 2003 at 08:01:39PM +1100, Luke Howard wrote: > > >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. :-) I remembered why we needed the original password - we need the original password so that we can salt it with various domains/principal names. So while it will work fine for just type 23, I think I'll skip it for now :-) Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
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
