wntUserAdd Bug

Question:

I'm using WinBatch compiler version 2006B. I have a full admin privilege (local and domain) on my system (Windows XP SP2) and I test the wntUserAdd command by just taking the sample in the Help file of wntUserAdd:

AddExtender("WWWNT34I.DLL")
wntUserAddDat("name", "jdoe")
wntUserAddDat("full_name", "John Doe")
wntUserAddDat("flags", 1)
wntUserAddDat("acct_expires", "0000:00:00:00:00:00")
wntUserAdd("")
Exit

I got a Windows exception error. I tried on my test machine Windows 2000, I got the same problem. I uninstalled my WinBatch version 2006B and use the version 2005C, the problem still there. Thanks for any help.

Answer:

That's interesting...disturbing, but still interesting. We've been able to duplicate it with a compiled version of the code. We'll kick it around in the debugger for a bit and let you know what we find out. It looks like *something* *somewhere* has encountered a NULL pointer and has thus walked off of the edge of the known universe into crashland.

You *might* try getting an older version of the extender - which you can extract from the following archive - and see if that works...

http://files.winbatch.com/wwwftp/wb01/extenders2005c.zip You will want to be verify what version of the extender you are running in your test script by using

a=wntVersion()
Message("NT Dll Version",a)

in your test script. Or specify a full path in your AddExtender function.

Update:

I found the source of the problem. It's a weird one, too. It actually has to do with strong passwords being enabled in conjunction with attempting to add a user w/o specifying a password value in a call to wntUserAddDat() before wntUserAdd() is called. The error handling code is what's actually causing the crash.

I can get the error handling code fixed so that it doesn't crash when a password doesn't meet the password policy. However, for an immediate work-around to the problem, simply specify a password that meets the password policy requirements. The example code does not set a password and thus the other underlying bug in the error handler is being manifested.

User Reply:

I tried to use the wntUserAddDat("password","hien1082hope"), the program stops scratching but I got the following error: "683: Password is unacceptable, maybe because it's being re-used". We never used that password and that jdoe account never hasn't been existed yet.I also tried 1082hope as password but got the same error.

Answer:

There's an endlessly growing list of possible reasons that a password is not acceptable. As password policies evolve, it's not feasible to attempt to enumerate every single reason. However, in your case, what you need to do is to actually examine the password values that you are specifying and compare them to the password policy rules that are in effect. Then you'll figure out why the password is not acceptable.

In this case, I suspect that you have strong passwords enabled, and both of the password values that you referenced aren't going to meet the strong password rules. You need a mixture of 3 out of 4 possible types of characters from the following types:

uppercase alpha, lowercase alpha, numeric and special symbols [e.g. punctuation].

Your passwords only have lowercase alpha and numeric characters, which is only 2 out of the 4. Add in at least one uppercase alpha character or put in a symbol like "$" or "#" or "@" or "&".

User Reply:

It works!!!!! I changed the password to something like "10824@pnh" and it works! Apparently "10824hope" was not strong enough.

Article ID:   W17076

File Created: 2007:07:03:14:28:06

Last Updated: 2007:07:03:14:28:06

Database Search

TechHome

wntUserAdd Bug

Question:

Answer:

Update:

User Reply:

Answer:

User Reply: