Active Directory UDF - Help & Support

[wolkenloser]

Hi,

I use the AD fuctions. It was very helpfull

Now, my user move into another context and my script doesn't work.

My old domain: dom1.de.name.loc

My User is in ("OU=admins,OU=D,OU=dom1,DC=de,DC=name,DC=loc")

My Servers are in ("OU=Server,OU=D,OU=dom1,DC=de,DC=name,DC=loc")

My new Userdomain was chance to dom2.de.name.loc

My User is in ("OU=admins,OU=D,OU=dom2,DC=de,DC=name,DC=loc")

The Servers don't change anything.

I use thes line to get an array of my servers, but now the array is empty now.

$aSERVERs = _AD_GetObjectsInOU("OU=Server,OU=D,OU=dom1,DC=de,DC=name,DC=loc")

Have I had to change the Domaincontext ?

The hole script:

#include <AD.au3>
_AD_Open()
$aSERVERs = _AD_GetObjectsInOU("OU=Server,OU=D,OU=dom1,DC=de,DC=name,DC=loc")
_ArrayDisplay($aSERVERs, "AD Servers")

Whats wrong with it ?

regards

Wolke

Edited August 10, 2011 by wolkenloser

[water]

HI wolkenloser,

The AD UDF can only work with one domain at a time as a default.

If you want to work with multiple domains you can either open/close the connection to boths domains (for details please see function _AD_Open)

or you can query the global catalog. This is achieved by specifying the DC you want to connect to plus port 3268. Make sure the DC you connect to has the GC available by using function _AD_ListDomaiNControllers (column 6 is set to true).

Please have a look at the Wiki for examples.

Edited August 10, 2011 by water

[wolkenloser]

HI wolkenloser,

The AD UDF can only work with one domain at a time as a default.

If you want to work with multiple domains you can either open/close the connection to boths domains (for details please see function _AD_Open)

or you can query the global catalog. This is achieved by specifying the DC you want to connect to plus port 3268. Make sure the DC you connect to has the GC available by using function _AD_ListDomaiNControllers (column 6 is set to true).

Please have a look at the Wiki for examples.

If I use _AD_OPEN as following it works.

$iResult = _AD_Open("", "", "DC=subdomain,DC=example,DC=com", "servername.subdomain.example.com", "CN=Configuration,DC=subdomain,DC=example,DC=com")

Thanks

[water]

Glad it works now

[tirrith2]

Hello,

would it be possible to create a function in autoIt to create, name, affect rigts on a blank GPO ?

I found it in powershel but i'm not enough strong to convert it :

http://www.gpanswers.com/component/content/category/104.html?layout=blog

thanks a lot

Stephane

[water]

Hi tirrith2,

there once was a discussion about

The result was that the GPO stuff was too complex and demand was too low to include it in the AD UDF or to create a new UDF.

The link above points to the first entry of the discussion so you can see how we decided not to include GPO's in the AD UDF.

[water]

Ah yes...that should get me going on the right path. Thanks.

Now here's an issue which may really need to be addressed. I had the same trouble with the earlier UDF: the FQDNtoDisplayName function doesn't actually return the DisplayName. I had to modify the earlier UDF and again had to do the same with the new. I don't have the file in front of me, but it has something to do with obj.name. It should be obj.displayName.

Sorry I can't give more details. I'm sure you can figure it out.

Thanks again! This UDF no doubt saves a lot of folks a lot of headaches and time.

Here the properties "name" and "displayname" have the same value. Can you please run the example script _AD_GetObjectProperties.au3 for one of your objects where you get an invalid result and post the content of this two properties?

[hannes08]

A short question that may or may not be answered pretty fast:

I have a script using _AD_Open() with different credentials:

$s_user = "JohnDoe"
$s_passwort = "APassw0RD"
$s_domain = "DC=Domain,DC=company"
$s_domaincontroller = "dc.domain.company"
$s_configuration = "cn=Configuration," & $s_domain
$i_security = 2
$rc = _AD_Open($s_user,$s_password,$s_domain,$s_domaincontroller,$s_configuration,$i_security)

The script works just fine on a member computer.

But it returns an error on a computer that is NOT a member of any domain (Workgroup with Novell )

Interesting enough: It returns a 0 with an @error of 8. As per doc, this should indicate a wrong user or pass under XP, but I'm 100% sure both are correct.

[water]

But it returns an error on a computer that is NOT a member of any domain (Workgroup with Novell )

Interesting enough: It returns a 0 with an @error of 8. As per doc, this should indicate a wrong user or pass under XP, but I'm 100% sure both are correct.

Return value 0 means: The function call didn't work properly.

@error = 8 means: OpenDSObject method failed. Could you please post the value of @extended. This contains the COM error code.

Edit: Or even better. Insert "$iAD_Debug = 2" before the _AD_Open call.

What is your operating system?

Edited August 25, 2011 by water

[hannes08]

Return value 0 means: The function call didn't work properly.

@error = 8 means: OpenDSObject method failed. Could you please post the value of @extended. This contains the COM error code.

Edit: Or even better. Insert "$iAD_Debug = 2" before the _AD_Open call.

What is your operating system?

Hi water,

I'll do so tomorrow. The extended errorcode is: -2147352567. This is running under Windows XP. We're in the transition from Novell to AD domain, so some of the clients are still just "Workgroup" PCs with Novell Client.

Full error description from setting $iAD_debug:

COM Error Encountered in myscript.au3
Scriptline = 401
NumberHex = 80020009
Number = -2147352569
WinDescription = Der Server ist nicht funktionstüchtig / Server is not operational
Description = 
Source =
HelpFile =
HelopContext = 0
LastDllError = 0

Hope this will help you.

Edited August 26, 2011 by Hannes123

[water]

Please drop the $i_security parameter and try again.

The description points to the certificate server not being operational.

[hannes08]

Hi water,

thanks for your help, it worked instantly. So it is not possible to use a SSL encrypted communication if you're not in the same domain? Do you know a way to change this? Maybe importing a SSL certificate?

Edited August 26, 2011 by Hannes123

[water]

Unfortunately I'm not very familiar with the SSL stuff.

The web didn't help very much to help me understand. If you find a way I will be happy to build it into the UDF.

I'm on vacation for the next two weeks so I won't be of much help in the next time.

[hannes08]

Unfortunately I'm not very familiar with the SSL stuff.

The web didn't help very much to help me understand. If you find a way I will be happy to build it into the UDF.

I'm on vacation for the next two weeks so I won't be of much help in the next time.

Well, in this case: Happy vacation! I'll go researching and ask my colleagues if they have a clue about it

[water]

If you find an answer I would like to know about your solution. If you would like to see any code added to the UDF I will be happy to insert whatever is needed (and makes sense).

[coopdaveel]

Here the properties "name" and "displayname" have the same value. Can you please run the example script _AD_GetObjectProperties.au3 for one of your objects where you get an invalid result and post the content of this two properties?

Water--first, thanks for moving my request to the appropriate place. Also, I apologize for the delay in responding: I can no longer access autoitscript.com from work because the host is in Germany, or so I've been told.

In my understanding of AD accounts, "name" and "displayname" are not the same thing. And in my environment, they contain different values. I can certainly try the example you requested, but IMHO, either the function should be renamed or the correct AD value queried.

That is, if "name" is queried it should return the value for "name;" if "displayname" is queried it should return the value for "displayname." In this case, although the function is named "FQDNtoDisplayName" it returns the value for "name." I know this because in my environment, "name" = user ID and "displayname" = the user's preferred first and last name.

As I mentioned previously, this was an issue in the original UDF. It can be corrected simply by changing one line: from obj.name to obj.displayname.

Perhaps future revs could contain both "FQDNtoDisplayName" and "FQDNtoName" for clarity.

I cannot thank you enough for what you've done to further the development of this UDF. It has been a life-saver for me!

[water]

I think I will change _AD_FQDNtoDisplayName to return the Displayname property as you suggested. I hope it won't break too many scripts

These functions are quite redundant - they can be replaced by _AD_GetObjectAttribute or _AD_GetObjectProperties.

[rikimaru110011]

Hi Water

If i have user Admin Local PC , and i login with user domain, can i change pw domain other way ?

[water]

My understanding is that the user with which you connect to the Active Directory has to have proper permissions to change his own or another users password.

You can specify the user credentials when you call _AD_Open. If you don't specify any credentials then the userid/password of the currently logged on user are used.

[rikimaru110011]

Sorry Water, i have other Question:

Local $userAdmindomain="admin"
Local $PassAdmindomain ="admin"
Local $var = RunAsWait($userAdmindomain,@LogonDomain,$PassAdmindomain,0,"My Test",@SYStemdir,@SW_hide)
processwaitclose($var)

Because "My test" i call a link " \\192.168.10.8\\ *.bat" ,

This "My Test" , i can call program autoit run as admin domain change pass for user doman?

Thanks for help

Edited September 16, 2011 by rikimaru110011