unsubscribe

Ryan Hiebert ryan at ryanhiebert.com
Thu Jan 13 18:33:56 MST 2011


2011/1/13 <samba-technical-request at lists.samba.org>

> Send samba-technical mailing list submissions to
>        samba-technical at lists.samba.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.samba.org/mailman/listinfo/samba-technical
> or, via email, send a message with subject or body 'help' to
>        samba-technical-request at lists.samba.org
>
> You can reach the person managing the list at
>        samba-technical-owner at lists.samba.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of samba-technical digest..."
>
> Today's Topics:
>
>   1. Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS
>      (J. Bruce Fields)
>   2. Re: [PATCH] torture:drs/rpc/msds_intid.c - proof for the
>      correct   "intId" (Kamen Mazdrashki)
>   3. Re: [PATCH] torture:drs/rpc/msds_intid.c - proof for the
>      correct   "intId" (Matthias Dieter Walln?fer)
>   4. SAMBA4 provision with OpenLDAP giving
>      NT_STATUS_INVALID_PARAMETER (Joe Comeaux)
>   5. s4: Patch proposal for bug #7887 (Matthias Dieter Walln?fer)
>   6. modification of userAccountControl according to MS-SAMR
>      3.1.1.8.1. (Anatoliy Atanasov)
>   7. Re: modification of userAccountControl according to MS-SAMR
>      3.1.1.8.1. (Andrew Bartlett)
>   8. Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS
>      (Paul B. Henson)
>   9. Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS
>      (Paul B. Henson)
>  10. How to log quota exceed msg in cifs host (Yu Liao)
>  11. Re: How to log quota exceed msg in cifs host (David Disseldorp)
>  12. Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS
>      (J. Bruce Fields)
>  13. Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS
>      (Gordon Ross)
>  14. Re: modification of userAccountControl according to MS-SAMR
>      3.1.1.8.1. (Rafal Szczesniak)
>  15. Re: ldap stronger authentication required error after upgrade
>      (Aaron Solochek)
>  16. Re: modification of userAccountControl according to MS-SAMR
>      3.1.1.8.1. (Kamen Mazdrashki)
>
>
> ---------- Forwarded message ----------
> From: "J. Bruce Fields" <bfields at fieldses.org>
> To: "Paul B. Henson" <henson at acm.org>
> Date: Wed, 12 Jan 2011 14:37:59 -0500
> Subject: Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS
> On Tue, Jan 11, 2011 at 01:35:19PM -0800, Paul B. Henson wrote:
> >
> > I'm working with Solaris' bundled version of samba 3.5.5, and am seeing
> > some weirdness with ACL mapping between ZFS and windows. By default (in
> my
> > configuration), a new file in a directory inherits an initial (zfs) acl
> > like:
> >
> > -rw-------+  1 henson   csupomona       0 Jan 11 12:32 test.txt
> >             owner@:rw-pdDaARWcC--:------:allow
> >
> > Or more verbosely:
> >
> > -rw-------+  1 henson   csupomona       0 Jan 11 12:32 test.txt
> >      0:owner@:read_data/write_data/append_data/read_xattr/write_xattr
> >          /delete_child/read_attributes/write_attributes/delete/read_acl
> >          /write_acl:allow
> ...
> > I also noticed that whenever an acl is set from the windows side, it also
> > includes the SYNCHRONIZE permission for all entries. That permission
> isn't
> > listed in the GUI, although the command line icacs program allows you to
> > control it. It seems SYNCHRONIZE more or less should always be on?
>
> That sounds like a ZFS bug to me....  I've verified in the past that
> their NFSv4 server always set SYCHRONIZE by default--I suppose that
> could have been a hack in their NFSv4 server, or they could have changed
> the behavior since then.  Either would be strange.
>
> --b.
>
>
>
> ---------- Forwarded message ----------
> From: Kamen Mazdrashki <kamenim at samba.org>
> To: samba-technical at lists.samba.org
> Date: Wed, 12 Jan 2011 22:54:39 +0200
> Subject: Re: [PATCH] torture:drs/rpc/msds_intid.c - proof for the correct
> "intId"
> Hi Matthias
>
> Thanks for catching this!
>
> I wonder how this code haven't failed in tests...
>
> --
> CU,
> Kamen Mazdrashki
> Samba Team                                            http://samba.org
> http://gitweb.samba.org/?p=kamenim/samba.git;a=summary
>
>
>
> ---------- Forwarded message ----------
> From: "Matthias Dieter Wallnöfer" <mdw at samba.org>
> To: Kamen Mazdrashki <kamenim at samba.org>
> Date: Wed, 12 Jan 2011 21:59:59 +0100
> Subject: Re: [PATCH] torture:drs/rpc/msds_intid.c - proof for the correct
> "intId"
> I've only discovered this by watching at buildfarm host "opi" - which
> claimed "possible uninitialised variable".
>
> Matthias
>
> Kamen Mazdrashki wrote:
>
>> Hi Matthias
>>
>> Thanks for catching this!
>>
>> I wonder how this code haven't failed in tests...
>>
>>
>>
>
>
>
>
> ---------- Forwarded message ----------
> From: Joe Comeaux <joe.comeaux at gmail.com>
> To: samba-technical at lists.samba.org
> Date: Wed, 12 Jan 2011 15:24:57 -0600
> Subject: SAMBA4 provision with OpenLDAP giving NT_STATUS_INVALID_PARAMETER
> Still trying to get Samba4 installed with OpenLDAP as the back end.
> I've followed the steps on
> http://wiki.samba.org/index.php/Samba4/LDAP_Backend/OpenLDAP on a
> ubuntu 10.10 clean install. I've tried openldap from cvs as well as
> stable-2.4.23, samba from rsync as well as samba-4-0.0.0alpha14. All
> give the same error. ( there was a small window with the samba rsync
> branch at the beginning of december where the provision script
> actually was able to complete, but then I would get no schema head
> present errors when trying to use samba-tool )
>
> setup/provision --realm=LDAP.SAMBA.EXAMPLE.COM --domain=LDAP
> --server-role='domain controller' --ldap-backend-type=openldap
> --slapd-path=/usr/local/libexec/slapd
> Administrator password will be set randomly!
> Looking up IPv4 addresses
> config file testing succeeded
> Failed to bind - LDAP client internal error:
> NT_STATUS_UNEXPECTED_NETWORK_ERROR
> Failed to connect to
> 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi' with backend
> 'ldapi'
> Failed to bind - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
> Failed to connect to
> 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi' with backend
> 'ldapi'
> Failed to bind - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
>
> The invalid_parameter error message is repeated 15 times before the
> provision script eventually gives up and fails with :
> Could not connect to slapd started with: '/usr/local/libexec/slapd'
> '-F/usr/local/samba/private/ldap/slapd.d' '-h'
> 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi' '-d0'
> ProvisioningError: slapd never accepted a connection within 15 seconds
> of starting
>
> ----- Anatoliy Atanasov -----
> > On clean Ubuntu 10.10 install i fixed it by running make install again in
> the
> > openldap folder, also before provisioning make sure to clean the prefix
> folder
> > you are installing into and do again make install for samba4.
>
> I tried this, got same results.
>
> ----- Andrew Bartlett -----
> > ensure that slapd -Ttest always runs.
>
> /usr/local/libexec/slapd -Ttest -F/usr/local/samba/private/ldap/slapd.d
> hdb_monitor_db_open: monitoring disabled; configure monitor database to
> enable
> config file testing succeeded
>
> some other information that may be helpful, when running
> '/usr/local/libexec/slapd' '-F/usr/local/samba/private/ldap/slapd.d'
> '-h' 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi' '-d99'
> to verify that slapd is able to open, I get this :
>
> backend_startup_one: starting "dc=ldap,dc=samba,dc=example,dc=com"
> hdb_db_open: database "dc=ldap,dc=samba,dc=example,dc=com":
> dbenv_open(/usr/local/samba/private/ldap/db/user).
> str2filter "(!(rdnValue=*))"
> put_filter: "(!(rdnValue=*))"
> put_filter: NOT
> put_filter_list "(rdnValue=*)"
> put_filter: "(rdnValue=*)"
> put_filter: simple
> put_simple_filter: "rdnValue=*"
> begin get_filter
> NOT
> begin get_filter
> PRESENT
> ber_scanf fmt (m) ber:
> end get_filter 0
> end get_filter 0
> => hdb_search
> bdb_dn2entry("dc=ldap,dc=samba,dc=example,dc=com")
> => hdb_dn2id("dc=ldap,dc=samba,dc=example,dc=com")
> <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found
> (-30988)
> send_ldap_result: conn=-1 op=0 p=0
> bdb_dn2entry("dc=ldap,dc=samba,dc=example,dc=com")
> => hdb_dn2id("dc=ldap,dc=samba,dc=example,dc=com")
> <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found
> (-30988)
> slapd starting
>
>
> I notice some NOT...PRESENT error messages after the rdnValue filter
> message, which leads me to think that perhaps there may be an error
> with the rdnval. The rdnval.so is compiled and exists in
> /usr/local/libexec/openldap
>
> I tried compiling openldap with some more flags to see if that made
> any difference, but it didnt. ( --with-cyrus-sasl
> --enable-overlays=mod --enable-modules --enable-spasswd
> --enable-lmpasswd --enable-dynamic --enable-rewrite --enable-ldap
> --enable-deref )
>
>
> This is where I get stuck. I don't know where to go from here. It
> seems to me like the provision script is building all the LDAP pieces,
> but when it comes time to connecting it just errors out. I dont know
> if this is because it may be depending on some SASL pieces which may
> not be installed, or if it has anything to do with ubuntu relying on
> gnutls as opposed to the SSL pieces for encryption or what.
>
> Any ideas on how to get this up and running are appreciated.
> Thanks
> -Joe Comeaux
>
>
>
> ---------- Forwarded message ----------
> From: "Matthias Dieter Wallnöfer" <mdw at samba.org>
> To: Jelmer Vernooij <jelmer at samba.org>
> Date: Wed, 12 Jan 2011 22:31:55 +0100
> Subject: s4: Patch proposal for bug #7887
> Hi Jelmer,
>
> here the patch proposal for bug #7887
>
>
> ---------- Forwarded message ----------
> From: Anatoliy Atanasov <anatoliy.atanasov at postpath.com>
> To: Kamen Mazdrashki <kamenim at samba.org>, "Matthias Dieter Wallnöfer" <
> mdw at samba.org>
> Date: Wed, 12 Jan 2011 23:42:38 +0200 (EET)
> Subject: modification of userAccountControl according to MS-SAMR 3.1.1.8.1.
> Hi Matthias,
>
> Kamen and I stumbled upon a code that modifies the userAccountControl
> attribute of a user object, when it shouldn't.
> We noticed that when you add a user with userAccountControl 66080 it ends
> up with 66082, which means that the account is disabled.
>
> The code modifies the userAccountControl of a user that is being added to
> the database and the documentation regarding the change of that attribute
> states:
> "If the value of the userAccountControl attribute _in_the_database_
> contains a bit that is specified in the following table, the
> userAccountControl attribute MUST be updated with the corresponding bit(s)
> using a bitwise OR."
>
> The add operation is still an originating update, but in this case the
> attribute isn't in the database and shouldn't be modified.
>
> Do you agree to change it?
>
> Regards, Anatoliy
>
>
>
> ---------- Forwarded message ----------
> From: Andrew Bartlett <abartlet at samba.org>
> To: anatoliy.atanasov at postpath.com
> Date: Thu, 13 Jan 2011 09:04:42 +1100
> Subject: Re: modification of userAccountControl according to MS-SAMR
> 3.1.1.8.1.
> On Wed, 2011-01-12 at 23:42 +0200, Anatoliy Atanasov wrote:
> > Hi Matthias,
> >
> > Kamen and I stumbled upon a code that modifies the userAccountControl
> attribute of a user object, when it shouldn't.
> > We noticed that when you add a user with userAccountControl 66080 it ends
> up with 66082, which means that the account is disabled.
>
> Isn't this what Windows does?
>
> > The code modifies the userAccountControl of a user that is being added to
> the database and the documentation regarding the change of that attribute
> states:
> > "If the value of the userAccountControl attribute _in_the_database_
> contains a bit that is specified in the following table, the
> userAccountControl attribute MUST be updated with the corresponding bit(s)
> using a bitwise OR."
> >
> > The add operation is still an originating update, but in this case the
> attribute isn't in the database and shouldn't be modified.
> >
> > Do you agree to change it?
>
> I'm rather confused, can you please give an example where Windows does
> not disable the account on add?
>
> Is this based just on a reading of the docs, or a specific test?  If
> it's a test, can you give some more detail on what you have tested?
>
> Thanks,
>
> Andrew Bartlett
>
> --
> Andrew Bartlett                                http://samba.org/~abartlet/
> Authentication Developer, Samba Team           http://samba.org
> Samba Developer, Cisco Inc.
>
>
>
>
> ---------- Forwarded message ----------
> From: "Paul B. Henson" <henson at acm.org>
> To: Jeremy Allison <jra at samba.org>
> Date: Wed, 12 Jan 2011 19:17:04 -0800 (PST)
> Subject: Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS
> On Tue, 11 Jan 2011, Jeremy Allison wrote:
>
> > Ok, here's the patch I'm planning for master. Can you test it (I don't
> > have access to a ZFS filesystem) for me please ?
>
> Looks good, all ACL's when viewed from the windows side appear to have sync
> set, and ACL's written from windows don't add sync to the underlying ZFS
> ACL.
>
> > This means the logical place to do this is not in modules/vfs_zfsacl.c,
> > but in modules/nfs4_acls.c which contains the master mapping code, so
> > that's where I've put it.
>
> I considered that, but didn't necessarily want to muck with the generic
> nfs4 code for my specific need. I agree that's the better place to do it if
> windows will always need the sync bit set in general.
>
> > However, I'm assuming that the other filesystems that support Samba
> > mapping to NFSv4 ACLs (gpfs and aixacl2.c) are ok with all incoming NFSv4
> > ACLs being rewritten on write to contain the sync bit. They must already
> > accept it from a Windows ACL so I'm pretty sure this is ok.
>
> I'm not sure what you mean; the change to the generic nfs4 code only
> results in the sync bit being added when converting an ACL to send it to
> windows, there's no change in the generic nfs4 code for taking a windows
> ACL and writing it out on the unix side. For the other filesystems using
> the nfs4 code that will continue to work as it always did.
>
> > I haven't added the code to strip the sync bit on write to the gpfs and
> > aixacl2 modules, as I don't think it's really needed.
> >
> > Do you want me to make the ZFS module code the same (i.e. not strip the
> > sync bit on write) ? It would make all modules more consistent.
>
> No; I definitely want the sync bit stripped before writing out the ZFS ACL.
> Given it's a noop on the zfs side, there's no functional difference, but
> there's a user interface difference. The underlying ACL is modified on the
> unix side both by interactive users at shell prompts and also by a web gui
> our webdev group put together that's layered on top of the zfs ACL. Having
> the sync bit start popping up everywhere a windows box happens to have
> touched the acl will be confusing, and possibly even break the webapp if
> they didn't account for it. And just on general principal I don't want my
> ACL's cluttered up with meaningless bits.
>
> While the stripping not be strictly needed, given that the sync bit is
> meaningless on the unix side, to make all the modules consistent I think it
> would be better to strip everywhere. Perhaps it could be a new option for
> the nfs4 module, like "stripsync". Defaulting to false for backwards
> compatibility (or to true for forward adaptability ;) ), when set to true
> it would strip the sync bit from the acl before writing it out.
>
> Per the AIX docs:
>
>
> http://publib.boulder.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.security/doc/security/acl_nfs4.htm
>
> -----
> Note: Concerning the SYNCHRONIZE Ace_Mask value key, s, AIX does not take
> any action concerning this value key. AIX stores and preserves the s value
> key but this value key does not have any meaning to AIX.
> -----
>
> It seems the only reason the sync bit exists in nfs4 is because it was
> copied from the ntfs acl. I'm not aware of anything on the unix side that
> cares about it. Windows seems to (virtually) always want it on. It seems
> cleanest to just always set it for the acl returned to windows, but strip
> it from the acl coming from windows. It's a trivial amount of extra work to
> create the new option for the nfs4 module to allow optional stripping, so
> maybe that's the best course of action?
>
> Or I'd be perfectly happy with the patch as is, it addresses my needs :).
>
> Thanks...
>
>
> --
> Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
> Operating Systems and Network Analyst  |  henson at csupomona.edu
> California State Polytechnic University  |  Pomona CA 91768
>
>
>
> ---------- Forwarded message ----------
> From: "Paul B. Henson" <henson at acm.org>
> To: "J. Bruce Fields" <bfields at fieldses.org>
> Date: Wed, 12 Jan 2011 20:17:53 -0800 (PST)
> Subject: Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS
> On Wed, 12 Jan 2011, J. Bruce Fields wrote:
>
> > That sounds like a ZFS bug to me....  I've verified in the past that
> > their NFSv4 server always set SYCHRONIZE by default--I suppose that could
> > have been a hack in their NFSv4 server, or they could have changed the
> > behavior since then.  Either would be strange.
>
> Hmm, I don't know what it used to do, but we've used the NFSv4 server on
> top of zfs since Solaris 10 update 6, and I've never seen the sync bit set
> unless there was a windows box involved via samba... I'm not sure what the
> in-kernel CIFS server does under OpenSolaris/Solaris Express.
>
>
> --
> Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
> Operating Systems and Network Analyst  |  henson at csupomona.edu
> California State Polytechnic University  |  Pomona CA 91768
>
>
>
> ---------- Forwarded message ----------
> From: Yu Liao <liaoyu17 at gmail.com>
> To: samba-technical at lists.samba.org
> Date: Thu, 13 Jan 2011 15:07:04 +0800
> Subject: How to log quota exceed msg in cifs host
> Hi, All
>
> I create a cifs share and set quota on the fs. I access the share from the
> windows client, and copy files exceed the quota. Then I get the error
> message"There is not enough free disk space." from the windows client, but
> I
> can't log the error message in /var/log/messages of the host. The host is
> SLES11 and use syslog-ng as the log system.
>
> Could you tell me how the log the quota exceeded messages in the
> /var/log/messages?
>
> --
> Best Regards.
> Liao Yu
> Tel:13880992031
>
>
>
> ---------- Forwarded message ----------
> From: David Disseldorp <ddiss at suse.de>
> To: Yu Liao <liaoyu17 at gmail.com>
> Date: Thu, 13 Jan 2011 21:30:52 +1100
> Subject: Re: How to log quota exceed msg in cifs host
> Hi Liao Yu,
>
> On Thu, 13 Jan 2011 15:07:04 +0800
> Yu Liao <liaoyu17 at gmail.com> wrote:
>
> > Could you tell me how the log the quota exceeded messages in the
> > /var/log/messages?
>
> Quota limits are enforced by the underlying filesystem rather than
> Samba.
>
> The warnquota(8) utility can be used to perform an action (normally
> send mail) when a user exceeds their soft quota limit.
>
> Cheers, David
>
>
>
> ---------- Forwarded message ----------
> From: "J. Bruce Fields" <bfields at fieldses.org>
> To: "Paul B. Henson" <henson at acm.org>
> Date: Thu, 13 Jan 2011 10:10:05 -0500
> Subject: Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS
> On Wed, Jan 12, 2011 at 08:17:53PM -0800, Paul B. Henson wrote:
> > On Wed, 12 Jan 2011, J. Bruce Fields wrote:
> >
> > > That sounds like a ZFS bug to me....  I've verified in the past that
> > > their NFSv4 server always set SYCHRONIZE by default--I suppose that
> could
> > > have been a hack in their NFSv4 server, or they could have changed the
> > > behavior since then.  Either would be strange.
> >
> > Hmm, I don't know what it used to do, but we've used the NFSv4 server on
> > top of zfs since Solaris 10 update 6, and I've never seen the sync bit
> set
> > unless there was a windows box involved via samba... I'm not sure what
> the
> > in-kernel CIFS server does under OpenSolaris/Solaris Express.
>
> Huh.  I still have my test results.  Looking back at them, I see that it
> always returned an ACL ending in an allow EVERYONE@ entry including
> the synchronize bit.
>
> That was several years ago, though, and come to think of it that *may*
> have been some translation layer on top of UFS at the time, instead of
> ZFS....
>
> Still, I doubt leaving synchronize unset is what they intended, so it
> might be worth reporting as a bug if you think it would get any
> attention.
>
> --b.
>
>
>
> ---------- Forwarded message ----------
> From: Gordon Ross <gordon.w.ross at gmail.com>
> To: samba-technical at lists.samba.org
> Date: Thu, 13 Jan 2011 10:31:29 -0500
> Subject: Re: mapping SYNCHRONIZE permission in NTFS ACL for ZFS
> [...]
> > Still, I doubt leaving synchronize unset is what they intended, so it
> > might be worth reporting as a bug if you think it would get any
> > attention.
>
> I've known about this bug for a while.  I thought we had an "issue"
> for this already, but I couldn't find it, so I filed a new one:
> http://www.illumos.org/issues/627
>
> Yes, the SYNC bit is missing sometimes when it should be there.
> I advise setting the bit (where appropriate) before storing an ACL.
>
> Gordon
>
>
>
> ---------- Forwarded message ----------
> From: Rafal Szczesniak <mimir at samba.org>
> To: Andrew Bartlett <abartlet at samba.org>
> Date: Thu, 13 Jan 2011 08:37:31 +0100
> Subject: Re: modification of userAccountControl according to MS-SAMR
> 3.1.1.8.1.
> On Thu, Jan 13, 2011 at 09:04:42AM +1100, Andrew Bartlett wrote:
> > On Wed, 2011-01-12 at 23:42 +0200, Anatoliy Atanasov wrote:
> > > Hi Matthias,
> > >
> > > Kamen and I stumbled upon a code that modifies the userAccountControl
> attribute of a user object, when it shouldn't.
> > > We noticed that when you add a user with userAccountControl 66080 it
> ends up with 66082, which means that the account is disabled.
> >
> > Isn't this what Windows does?
>
> Yes, it is.
>
> > > The code modifies the userAccountControl of a user that is being added
> to the database and the documentation regarding the change of that attribute
> states:
> > > "If the value of the userAccountControl attribute _in_the_database_
> contains a bit that is specified in the following table, the
> userAccountControl attribute MUST be updated with the corresponding bit(s)
> using a bitwise OR."
> > >
> > > The add operation is still an originating update, but in this case the
> attribute isn't in the database and shouldn't be modified.
> > >
> > > Do you agree to change it?
> >
> > I'm rather confused, can you please give an example where Windows does
> > not disable the account on add?
> >
> > Is this based just on a reading of the docs, or a specific test?  If
> > it's a test, can you give some more detail on what you have tested?
>
> Since this applies to the originating update of the objectClass attribute
> and I don't
> really see any way of updating it other than adding an account this makes
> sense perfectly
> - newly created account is disabled.
>
>
> cheers,
> --
> Rafal Szczesniak
> Samba Team member   http://www.samba.org
> Likewise Software   http://www.likewise.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iD8DBQFNLqu7Hvdfyv3qiKkRAtgQAJ9rSSID/i6Pv/EXqrGcjOUCtM1ArACeJsah
> slcYN5fnlJ85f+BZWMlgGRg=
> =0Vtp
> -----END PGP SIGNATURE-----
>
>
> ---------- Forwarded message ----------
> From: Aaron Solochek <aarons-samba at aberrant.org>
> To: Andrew Bartlett <abartlet at samba.org>
> Date: Thu, 13 Jan 2011 11:55:40 -0500
> Subject: Re: ldap stronger authentication required error after upgrade
> On 01/08/2011 12:41 AM, Andrew Bartlett wrote:
> > On Fri, 2011-01-07 at 20:02 -0500, Aaron Solochek wrote:
> >> On 01/07/2011 06:51 PM, Brad Hards wrote:
> >>> On Saturday, January 08, 2011 10:29:01 am Aaron Solochek wrote:
> >>>> So what changed that would cause this, and how to fix it?  I have a
> wiki
> >>>> that was authenticating against ldap, and now no one can log in.
> >>> It might have been easier to tell if you could have described which
> version
> >>> worked and which version didn't, but you're probably using an anonymous
> bind,
> >>> which isn't allowed in more recent samba versions.
> >>>
> >>> To fix it, authenticate the ldap bind.
> >>>
> >>
> >> No, it's not an anonymous bind, I'm authenticating as an admin.
> >>
> >> The version that worked was, I believe
> >>
> >> 4.0.0~alpha14~bzr14682~ppa170+191~maverick1
> >>
> >> The version that doesn't is
> >>
> >> 4.0.0~alpha14~bzr15953~ppa174+199~maverick
> >
> > Sadly those versions don't mean anything.  We will need the GIT hashes
> > to be able to line these up to dates.
> >
> > However, I think you should confirm with a network capture that you are
> > not doing any searches or other operations before that administrative
> > bind.  These will now be rejected as they are anonymous.
> >
> > Andrew Bartlett
> >
>
> Ok, getting back to this.  I again pulled in the latest from git, and using
> luma, attempted to browse ldap.  I am biding as aarons at foo.com, no
> encryption,
> simple authentication.
>
> I open up the browser and see:
>
> CN=Configuration,DC=foo,DC=com
> CN=Schema,CN=Configuration,DC=foo,DC=com
> DC=foo,DC=com
>
> I test and can successfully expand the Schema.  I attempt to expand the
> last
> entry in that list, and I get the error "Could not check if object is a
> leaf in
> the ldap tree.  Reason: {'info': '00002020: Operations error - Operation
> unavailable without authentication', 'desc': 'Operations error'}"
>
> This is a dump of the LDAP traffic I saw:
>
> 10.1.10.25  10.1.10.10  LDAP  106    bindRequest(1) "aarons at foo.com"
> simple
> 10.1.10.10  10.1.10.25  LDAP  80     bindResponse(1) success
> 10.1.10.25  10.1.10.10  LDAP  121    searchRequest(2) "<ROOT>" baseObject
> 10.1.10.10  10.1.10.25  LDAP  220    searchResEntry(2) "<ROOT>"  |
> searchResDone(2) success
>
> 10.1.10.25  10.1.10.10  LDAP  73     unbindRequest(3)
> 10.1.10.25  10.1.10.10  LDAP  106    bindRequest(1) "aarons at foo.com"
> simple
> 10.1.10.10  10.1.10.25  LDAP  80     bindResponse(1) success
> 10.1.10.25  10.1.10.10  LDAP  168    searchRequest(2)
> "CN=Schema,CN=Configuration,DC=foo,DC=com" singleLevel
>
> 10.1.10.10  10.1.10.25  LDAP  1240   searchResEntry(2)
> "CN=Instance-Type,CN=Schema,CN=Configuration,DC=foo,DC=com"
>
> ... (many lines of schema response omitted)
>
> 10.1.10.25  10.1.10.10  LDAP  73     unbindRequest(3)
> 10.1.10.25  10.1.10.10  LDAP  106    bindRequest(1) "aarons at foo.com"
> simple
> 10.1.10.10  10.1.10.25  LDAP  80     bindResponse(1) success
> 10.1.10.25  10.1.10.10  LDAP  141    searchRequest(2) "DC=foo,DC=com"
> singleLevel
>
> 10.1.10.10  10.1.10.25  LDAP  1312   searchResEntry(2)
> "CN=Users,DC=foo,DC=com"
>  | searchResEntry(2) "CN=Computers,DC=foo,DC=com"  | searchResEntry(2)
> "CN=Builtin,DC=foo,DC=com"  | searchResEntry(2) "OU=Domain
> Controllers,DC=foo,DC=com"  | searchResEntry(2)
> "CN=ForeignSecurityPrincipals,DC=foo,DC=com"  | searchResEntry(2)
> "CN=Infrastructure,DC=foo,DC=com"  | searchResEntry(2)
> "CN=LostAndFound,DC=foo,DC=com"  | searchResEntry(2) "CN=NTDS
> Quotas,DC=foo,DC=com"  | searchResEntry(2) "CN=Program Data,DC=foo,DC=com"
>  |
> searchResEntry(2) "CN=System,DC=foo,DC=com"  | searchResEntry(2)
> "OU=People,DC=foo,DC=com"  | searchResEntry(2)
> "CN=defaultMigrationContainer30,DC=foo,DC=com"  | searchResEntry(2)
> "OU=ma,DC=foo,DC=com"  | searchResEntry(2) "OU=ca,DC=foo,DC=com"  |
> searchResRef(2)  | searchResDone(2) success
>
> 10.1.10.25  10.1.10.10  LDAP  80     bindRequest(4) "<ROOT>" simple
> 10.1.10.10  10.1.10.25  LDAP  80     bindResponse(4) success
> 10.1.10.25  10.1.10.10  LDAP  158    searchRequest(3)
> "CN=Configuration,DC=foo,DC=com" baseObject
>
> 10.1.10.10  10.1.10.25  LDAP  153    searchResDone(3) operationsError
> (00002020:
> Operations error - Operation unavailable without authentication)
>
> 10.1.10.25  10.1.10.10  LDAP  73     unbindRequest(5)
> 10.1.10.25  10.1.10.10  LDAP  73     unbindRequest(6)
>
> So I see that it does return some results after the second search request,
> but
> even using a different ldap browser, jxplorer, I'm getting the same
> behavior.
>
> It seems these clients are expecting some slightly different LDAP behavior
> than
> the recent samba4 is exhibiting.  I know for sure that luma used to work
> for
> with samba4 ldap.
>
>
> Next steps to debug this?
>
> -Aaron
>
>
>
> ---------- Forwarded message ----------
> From: Kamen Mazdrashki <kamenim at samba.org>
> To: Andrew Bartlett <abartlet at samba.org>
> Date: Thu, 13 Jan 2011 19:46:12 +0200
> Subject: Re: modification of userAccountControl according to MS-SAMR
> 3.1.1.8.1.
> On Thu, Jan 13, 2011 at 00:04, Andrew Bartlett <abartlet at samba.org> wrote:
> > On Wed, 2011-01-12 at 23:42 +0200, Anatoliy Atanasov wrote:
> >> Hi Matthias,
> >>
> >> Kamen and I stumbled upon a code that modifies the userAccountControl
> attribute of a user object, when it shouldn't.
> >> We noticed that when you add a user with userAccountControl 66080 it
> ends up with 66082, which means that the account is disabled.
> >
> > Isn't this what Windows does?
> Yes, when userAccountControl is not supplied on add.
>
> >
> >> The code modifies the userAccountControl of a user that is being added
> to the database and the documentation regarding the change of that attribute
> states:
> >> "If the value of the userAccountControl attribute _in_the_database_
> contains a bit that is specified in the following table, the
> userAccountControl attribute MUST be updated with the corresponding bit(s)
> using a bitwise OR."
> >>
> >> The add operation is still an originating update, but in this case the
> attribute isn't in the database and shouldn't be modified.
> >>
> >> Do you agree to change it?
> >
> > I'm rather confused, can you please give an example where Windows does
> > not disable the account on add?
> We are working on this example :)
>
> >
> > Is this based just on a reading of the docs, or a specific test?  If
> > it's a test, can you give some more detail on what you have tested?
> >
> This is based on what we were observing while testing our internal tool.
> Account created is disabled on Samba, but not disabled on w2k3-r2.
>
>
> ----------------------------------------------------------------------------
> I am writing here after testing it and it proofs we have a bug in Samba.
> I've used this simple record for creating a user record:
>  {'dn': 'CN=test_736,CN=Users,DC=samba,DC=devel',
>  'objectClass': 'user',
>  'userAccountControl': '66080',
>  'sAMAccountName': 'test_736'}
>
> Against w2k8-r2 after adding the record,  userAccountControl = '66080'
> Against Samba4 after adding the record, userAccountControl = '66082'
>
> So I think Anatoliy's statement holds true and we have a bug.
> I will work on Samba implementation to come with a patch, if
> Matthias is ok with this?
>
>
> --
> CU,
> Kamen Mazdrashki
> Samba Team                                            http://samba.org
> http://gitweb.samba.org/?p=kamenim/samba.git;a=summary
>
>
> _______________________________________________
> samba-technical mailing list
> samba-technical at lists.samba.org
> https://lists.samba.org/mailman/listinfo/samba-technical
>
>


More information about the samba-technical mailing list