Active Directory UDF

[supersonic]

Currently I'm running W7.

Now it works better:

DOMAIN\Administrator, password "" = error code 7, extended code 0.

DOMAIN\Administrator, invalid password = error code 8, extended code -2147352567.

[water]

DOMAIN\Administrator, password "" = error code 7, extended code 0.

DOMAIN\Administrator, invalid password = error code 8, extended code -2147352567.

error code 7 is fine because the password is missing.

error code 8 i not OK. You should get an error code > 8 and the returned error array should be displayed using _ArrayDisplay.

What do you get when you run

ConsoleWrite(@OSVersion & @CRLF)

What version of AutoIt do you run?

[supersonic]

Sorry, it was my fault... Although I'm running W7, @OSVersion returned "WIN_XP".

The reason: For testing I've changed the property "Compatibility mode" to "Windows XP (Service Pack 3)".

Now @OSVersion returns "WIN_7".

What can I test now?

[water]

Hi supersonic,

good to know!

If you run the testscript with an invalid userid and/or invalid password (not empty) you should get the error array display similar to this screenshot.

Edited August 18, 2010 by water

[supersonic]

Hi water,

When running the test script with an invalid password an array will be returned. Like this:

[0]|5

[1]|2148074248

[2]|80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece

[3]|LDAP Provider

[4]|52e

[5]|Logon failure: unknown user name or bad password.

When running with no password ($sAD_PasswordParam = "") no array will be returned, @error = 7.

Edited August 18, 2010 by supersonic

[water]

Perfect! That's how it should work!

This feature now allows for better debugging and a return code that lets the user see if _AD_Open was successful or not.

Thanks a lot for testing!

Edited August 18, 2010 by water

[supersonic]

Was a pleasure!

[Joe2010]

Hi,

I'm trying to build a script that will create new users in our AD, includiung the creation of Home-Directory etc...

The only thing is the Terminalserver Attributes Problem:

http://gallery.technet.microsoft.com/ScriptCenter/en-us/9ecb867c-1856-444f-8345-004d1f35f753

When I try to use TerminalServicesProfilePath a DCOM failure 000000A9 will pop up.

_AD_GetObjectsInOU($accountants,"dc=test,dc=local","(name=narf*)","2","TerminalServicesProfilePath")

Is there a way to manipulate the TerminalServer Attributes with this UDF?

Greetings

Joe

Edited August 27, 2010 by Joe2010

[Baraoic]

Ok I have a question if something is possible. The situation is we have lets say a.com and then multiple sub-domains like b.a.com and c.a.com and we are administrators in b.a.com. Now we don't have domain admins, instead we have delegated control. We can manually go into users and computers and take Bob@c.a.com and add him to a universal security group in b.a.com, but when we try automating it with the active directory script it returns the user doesn't exist. I am guessing because it is using our sub-domain to look up the users which then doesn't exist there. So then the question is how do I get it to use a different sub-domain to search and add it to our security group in our sub-domain?

[water]

Hi,

I'm trying to build a script that will create new users in our AD, includiung the creation of Home-Directory etc...

The only thing is the Terminalserver Attributes Problem:

http://gallery.technet.microsoft.com/Scr...-us/9ecb867c-1856-444f-8345-004d1f35f753

When I try to use TerminalServicesProfilePath a DCOM failure 000000A9 will pop up.

_AD_GetObjectsInOU($accountants,"dc=test,dc=local","(name=narf*)","2","TerminalServicesProfilePath")

Is there a way to manipulate the TerminalServer Attributes with this UDF?

Greetings

Joe

You can modify any property in AD as long as you have the required rights. Use _AD_ModifyAttribute.

Your usage of _AD_GetObjectsInOu seems to be wrong (if you use the latest version of the UDF). Try:

$aResult = _AD_GetObjectsInOU("dc=test,dc=local","(name=narf*)","2","TerminalServicesProfilePath")

Edited August 30, 2010 by water

[water]

Ok I have a question if something is possible. The situation is we have lets say a.com and then multiple sub-domains like b.a.com and c.a.com and we are administrators in b.a.com. Now we don't have domain admins, instead we have delegated control. We can manually go into users and computers and take Bob@c.a.com and add him to a universal security group in b.a.com, but when we try automating it with the active directory script it returns the user doesn't exist. I am guessing because it is using our sub-domain to look up the users which then doesn't exist there. So then the question is how do I get it to use a different sub-domain to search and add it to our security group in our sub-domain?

This is not possible at the moment. Using _AD_Open you connect to a single domain. All functions and error checking is done in this single domain.

I would suggest you extract the required functions from the AD UDF and modify them to your needs.

If you have further questions or any suggestions to enhange the UDF just drop me a note.

[Joe2010]

You can modify any property in AD as long as you have the required rights. Use _AD_ModifyAttribute.

Your usage of _AD_GetObjectsInOu seems to be wrong (if you use the latest version of the UDF). Try:

$aResult = _AD_GetObjectsInOU("dc=test,dc=local","(name=narf*)","2","TerminalServicesProfilePath")

Thanks! I see. The problem was my windows xp operating system. I have only Terminal Services rights on a windows server 2003 machine. Edited August 30, 2010 by Joe2010

[supersonic]

Hi water,

currently I'm using the pre-release UDF '_AD_ObjectExistsInSchema()'.

Is it useful to change the line:

$sAD_SchemaNamingContext = $oAD_RootDSE.Get("SchemaNamingContext")

to:

Local $sAD_SchemaNamingContext = $oAD_RootDSE.Get("SchemaNamingContext")

???

When setting 'Opt("MustDeclareVars")' to 1 scripts always stop with:

D:\SUPERSONIC\_\AUTOIT_ADQUERY\include\_AD_ObjectExistsInSchema.au3 (5) : ==> Variable used without being declared.:
$sAD_SchemaNamingContext = $oAD_RootDSE.Get("SchemaNamingContext")
^ ERROR

Greets,

-supersonic.

Edited August 31, 2010 by supersonic

[water]

Hi supersonic,

this has already been changed in version 0.40.

I run AU3Check with the following parameters: #AutoIt3Wrapper_AU3Check_Parameters= -d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6

I hope to release the next version in about 2-3 weeks.

Greetings

Water

[water]

Version 0.40 has been released.

For download please see signature.

[supersonic]

Hi water,

thank you for V0.40.

I have some trouble with '_AD_Open()'.

Now, with the new version, the function doesn't return any error value (0 = failure or 1 = success).

When the function was successful, it always returns @error = 1317!? I expect @error = 0.

'_AD_Open()' from V0.39 works fine.

It there anything I could do to help fixing the problem (- if it is a problem)?

Greets,

-supersonic.

Edited September 8, 2010 by supersonic

[water]

I have some trouble with '_AD_Open()'.

Now, with the new version, the function doesn't return any error value (0 = failure or 1 = success).

When the function was successful, it always returns @error = 1317!? I expect @error = 0.

'_AD_Open()' from V0.39 works fine.

Hi supersonic,

it's not a bug - it's a feature

If you are running Windows 7 and _AD_Open() returns an error then the return value is no longer 0 but an array.

@error is set to the decimal value of the last error.

In your case:

1317 (decimal) is 525 (hex) and means "user not found"

I would check @error to see if _AD_Open worked properly and then inspect the return value.

Edited September 8, 2010 by water

[supersonic]

Hi water,

ahhh, I see, thanks for your explanation.

Greets,

-supersonic.

[water]

Hi supersonic,

I enhanced the change history on page 1 of this thread and will enhance the _AD_Open example script for the next version.

[supersonic]

Hi water,

I hope I'm not bothering you...

May be you can help me...

I'm still talking about '_AD_Open()':

The new functionality in this UDF is very welcome,

but the changes are somehow script-breaking...

1. The error-handling has to be done partly outside the UDF.

Since last changes you have to check for the underlaying OS

to interpret the @error-codes right... And you have to handle

with return values, if they are empty or not...

For example you can not simply use "If Not @error Then" or

"If _AD_Open() = 1 Then" anymore...

2. In the corresponding sample script your're talking about

"On Windows XP or lower ..." and "For Windows 7 systems ...".

What about Win_Vista - same @error-codes as Win_XP?

What about Win_2008 and Win_2008_R2 (= Win_7)?

Currently the UDF checks only for Win_7...

I think checking for @OSVersion is not always precise enough...

Here's a sample to addess this issue (I know, there are better ones):

expandcollapse popup

#include-once


#cs
    Microsoft Windows Server 2008 R2    6.1
    Microsoft Windows 7                 6.1
    Microsoft Windows Server 2008       6.0
    Microsoft Windows Vista             6.0
    Microsoft Windows Server 2003 R2    5.2
    Microsoft Windows Server 2003       5.2
    Microsoft Windows XP                5.1
    Microsoft Windows 2000              5.0
#ce


; Example.
; ConsoleWrite(_OSVersion() & @CRLF)


; !!! INTERNAL !!!
Func __HKLM()
    Local $RetVal = "HKLM"
    ; <...>
    If @OSArch = "IA64" Or @OSArch = "X64" Then
        $RetVal = "HKLM64"
    EndIf
    ; <...>
    Return $RetVal
EndFunc


; ----------------------------------------------------------------------------------------------------
; Function Name:    _OSVersion()
; Description:      Identify operating system and return OS version string.
; Syntax:           _OSVersion()
; Parameter(s):     None.
; Requirement(s):   #include "__HKLM.au3".
; Return Value(s):  "UNKNOWN"       - Operating system could not be identified.
;                   "WIN_????_??"   - "WIN_2000", "WIN_XP", "WIN_2003", "WIN_2003_R2", "WIN_VISTA", "WIN_2008", "WIN_7", "WIN_2008_R2".
; ----------------------------------------------------------------------------------------------------
Func _OSVersion()
    Local $aTmp[8][3]   = [ ["6.1", "R2", "WIN_2008_R2"],   _
                            ["6.1", "7", "WIN_7"],          _
                            ["6.0", "2008", "WIN_2008"],    _
                            ["6.0", "Vista", "WIN_VISTA"],  _
                            ["5.2", "R2", "WIN_2003_R2"],   _
                            ["5.2", "2003", "WIN_2003"],    _
                            ["5.1", "XP", "WIN_XP"],        _
                            ["5.0", "2000", "WIN_2000"]]
    Local $sTmp1        = RegRead(__HKLM() & "\SOFTWARE\Microsoft\Windows NT\CurrentVersion", "CurrentVersion")
    Local $sTmp2        = RegRead(__HKLM() & "\SOFTWARE\Microsoft\Windows NT\CurrentVersion", "ProductName")
    Local $RetVal       = "UNKNOWN"
    ; <...>
    For $i = 0 To UBound($aTmp, 1) - 1 Step 1
        If $aTmp[$i][0] = $sTmp1 And StringInStr($sTmp2, $aTmp[$i][1], 0) > 0 Then
            $RetVal = $aTmp[$i][2]
            ; <...>
            ExitLoop
        EndIf
    Next
    ; <...>
    Return $RetVal
EndFunc

3. In my opinion it is rather unlikely that a function on one side

returns values (=< Win_XP) but under certain circumstances not (= array, e. g. Win_7),

although the function call was successful both times...

May be the UDF could be changed this way:

- Return values - regardless what OS (NOT @error-codes):

0 = failure

1 = success

- Extended return values for Win_7/Win_2008(R2):

It's a good way to return them using 'ByRef' or another (internal) global array variable could be defined...

If you need the extended return values of the last '_AD_Open()'-call you could read this array...

- @error-codes - regardless what OS:

0 = success

1...8 = errors as currently defined...

Alternatively I could write some kind of wrapper, like "_AD_OpenWrapper()'" to simplify handling.

But I don't think this is a good point to start with...

What do you think?

Or am I crazy?

If you need support, I'm waiting...

Greets,

-supersonic.

Edited September 9, 2010 by supersonic