SamDB.enable_account does not work against Windows
nivanova at samba.org
Thu Jun 10 12:11:58 MDT 2010
Sure, do ask Andrew what he thinks about it. But the thing is, one does not
run tests against a machine in use for something else - you use a "virgin"
virtual machine for that purpose exactly to avoid messing stuff up. Besides,
you do not need to change the other flags - just read dsHeuristcs, raise the
flag we need in the value and set it. When the tests suite is through you
can unset it the same way if you like, although this particular flag does
only this one thing. It is up to you of course, its your work, but in my
opinion tests that do not pass against Windows without manual tinkering do
not prove that Samba is working correctly, which is their main goal...
On Thu, Jun 10, 2010 at 8:20 PM, Matthias Dieter Wallnöfer <mdw at samba.org>wrote:
> I hesitate to do this since someone could already have customised the
> "dSHeuristics". And I don't like to overwrite existing settings only just
> for doing a test. Well, I will also ask abartlet what he does think and then
> I decide how to modify the testsuite.
> Nadezhda Ivanova wrote:
>> I am sorry, but I think the tests should do that. They are supposed to
>> pass against Windows without "crutches" like manually changing the system.
>> In addition, Samba should have the same behavior. That is another feature
>> entirely, I just believe that we should set dsHeuristics if we plan to use
>> userPassword in the tests, otherwise the next person who works with them
>> will stumble on the same problem.. It will have no effect in Samba and the
>> tests will pass against Windows. Will you send me a passwords.py that passes
>> against Windows and does not have workarounds for the ACL problem? Its OK if
>> it fails against Samba, that is kind of the idea :).
>> On Thu, Jun 10, 2010 at 3:53 PM, Matthias Dieter Wallnöfer <mdw at samba.org<mailto:
>> mdw at samba.org>> wrote:
>> sorry I seem to have forgotten to tell you that on s4 we do always
>> behave as the "fUserPwdSupport" in "dSHeuristics" was set
>> ("000000001" should fit). This is since we have always been
>> interpreting the "userPassword" as password change attribute (we
>> use it mainly for password changes through the Python bindings -
>> function SamDB.set_password). So please do set these
>> "dSHeuristics" on your Windows Server machine.
>> Then you should be able to run the tests without further problems.
>> Nadezhda Ivanova wrote:
>> Hi Matthias,
>> I was trying out your passwords.py tests, and found the following:
>> Against Windows, the SamDB.enable_account does not work if the
>> user password has been provided with userPassword attribute
>> instead of unicodePwd. The reason is that Windows treats that
>> case as if the password has not been actually set, and returns
>> UNWILLING_TO_PERFORM when we attempt to unset the
>> ADS_UF_PASSWD_NOTREQD flag. I suspect that the reason for this
>> is as described in 220.127.116.11.1.5 Password Modify Operations.
>> userPassword is only accepted if fUserPwdSupport is true in
>> dsHeuristics, which by default it is not. Why Windows does not
>> return an error is another thing. So I suppose we have 2
>> options here - use only unicodePwd and secure connections or
>> set fUserPwdSupport if we need to use userPassword. I have not
>> tried the second option yet, the first one I tried and it
>> works. However then some tests in passwords.py start to fail,
>> as the userPassword attribute is no longer present. Actually,
>> when I run passwords.py against Windows, a couple of them fail
>> even if I change nothing.
>> Since I will rely on these tests to be able to fix the ACL CAR
>> problem, do you think you could make a version that works as
>> expected (e. g. uses the newly created user rather than
>> credentials from the command line) and passes against windows.
>> Send me the patch then and I will push it together with the
>> ACL fix. This would really help.
More information about the samba-technical