Can't Get Attribute from OpenLDAP (ADO)

[tatane]

Hi !

I'm playing with ADO and OpenLDAP connection. My script works with Windows 7 but don't with Windows XP.

Here is the code :

expandcollapse popup

$oMyError = ObjEvent('AutoIt.Error', 'MyErrFunc')

$ado = ObjCreate("ADODB.Connection")
$ado.Provider = "ADSDSOObject"
$ado.Properties("User ID") = "cn=reader,o=gouv,c=fr"
$ado.Properties("Password") = "passsword"
$ADS_SERVER_BIND = 0x200
$ado.Properties("ADSI Flag") = $ADS_SERVER_BIND
$ado.Open("OpenLDAP-Search")

$adoCmd = ObjCreate("ADODB.Command")
$adoCmd.ActiveConnection = $ado
$adoCmd.Properties("Page Size") = 999
$adoCmd.Properties("Cache Results") = True
$adoCmd.Properties("Timeout") = 10

$serverName = "192.168.0.1"
$strBase = "<LDAP://" & $serverName & "/ou=users,o=gouv,c=fr>"
$strFilter = "(&(objectClass=person)(uid=toto))"
$strAttributes = "ADsPath"
$strQuery = $strBase & ";" & $strFilter & ";" & $strAttributes & ";subtree"
$adoCmd.CommandText = $strQuery

$objectList = $adoCmd.Execute

$objectList.GetRows

$objectList.MoveFirst
While Not $objectList.EOF

    $user = ObjGet($objectList.Fields("ADsPath").Value)

    ConsoleWrite($user.ENTPersonProfils & @CRLF)

    $objectList.MoveNext
Wend

Func MyErrFunc()
    $HexNumber = Hex($oMyError.number, 8)
    ConsoleWrite($HexNumber&@CRLF)
    MsgBox(0, 'AutoItCOM Test', 'We intercepted a COM Error !' & @CRLF & @CRLF & _
            'err.description is: ' & @TAB & $oMyError.description & @CRLF & _
            'err.windescription:' & @TAB & $oMyError.windescription & @CRLF & _
            'err.number is: ' & @TAB & $HexNumber & @CRLF & _
            'err.number is (non Hex): ' & @TAB & $oMyError.number & @CRLF & _
            'err.lastdllerror is: ' & @TAB & $oMyError.lastdllerror & @CRLF & _
            'err.scriptline is: ' & @TAB & $oMyError.scriptline & @CRLF & _
            'err.source is: ' & @TAB & $oMyError.source & @CRLF & _
            'err.helpfile is: ' & @TAB & $oMyError.helpfile & @CRLF & _
            'err.helpcontext is: ' & @TAB & $oMyError.helpcontext _
            )
EndFunc   ;==>MyErrFunc

 

The error is at this line :

ConsoleWrite($user.ENTPersonProfils & @CRLF)

The attribute "ENTPersonProfils" is unknown. If I replace it by "cn" attribute, it works. And no problem with Windows 7...

Any Idea ?

 

Thanks.

Edited June 3, 2015 by tatane

[water]

Does the COM error handler output any messages?

[tatane]

err.windescription : Unknown name ("Nom inconnu" in french)

err.number : 80020006

That's all.

Could it be a problem of provider ?

Edited June 3, 2015 by tatane

[mLipok]

how you use COM Error handler ?
I ask because you do not have all information , at least you do not put it here - I mean err.scriptline ?

And which script line it is in your script ?

[tatane]

The error mentionned by COM Error handler (err.scriptline) is at the line

ConsoleWrite($user.ENTPersonProfils & @CRLF)

The "ENTPersonProfils" attribute name is not recognized although it exists and it works if the script is executed under Windows 7.

[water]

Do you check a different user on Windows 7?

[tatane]

Yes. I'm using this function to know if a user is a professor or a student (the ENTPersonProfils attribute of $user object).

It seems only few attributes are accessibles : $user.cn, $user.uid, $user.sn.

Is there a way to list the attribute of an object ?

 

Edited June 3, 2015 by tatane

[water]

Some attributes are created when they get a value assigned for the first time (at least in MS AD).
So when the attribute does not exists it means it never had a value.
I simply would ignore this error and keep on processing as if the attribute existed but contained no value.

[tatane]

The problem is that this attribute always have a value ("student" or "teacher") and I need this information.

 

Maybe another way is to test one of the objectClass. One of them contains the type of user : ENTAuxEnseignant for teacher and ENTEleve for student.

How can I test it with the $user object ?

EDIT : I found how to get values from objectClass. It is an array type. So I just have to search for "ENTAuxEnseignant" or "ENTEleve" in this array to determine the usertype. Just a workaround. It works under Win XP and 7.

But I still don't know why my first script doesn't work correctly with Win XP

Edited June 3, 2015 by tatane

[water]

(uid=toto)

is the userid you check on both systems?
I ask so we know if the problem is related to the operating system or the userid.

[tatane]

Yes I checked the same uid on both systems.

By the way, the $objectList.execute method works fine.

[water]

Then I have run out of ideas why on XP your script can't access the property!
As support for Windowx XP has ended already I would - for security reasons - upgrade to a supported version of Windows as soon as possible.

[tatane]

Don't you think it might be a provider problem ? Is it OS dependent ?
 

In any event, thank you for your time.

Edited June 4, 2015 by tatane

[water]

Don't you think it might be a provider problem ? Is it OS dependent ?

​As it works on Windows 7 and doesn't on Windows XP for the same uid it has to be a problem of the XP machine. Either a bug in one of the components (provider etc.) or a different setting for the cmd or connection objects etc.

Unfortunately I have never played with OpenLDAP, just MS AD.

Last question: Do you run the same version of AutoIt on both machines?

Edited June 4, 2015 by water

[tatane]

Yep same version.

[water]

Another idea:
Those properties you can access from XP seem to be standard properties, ENTPersonProfils seems to be a property of an schema extension.
Maybe XP has a problem with this extensions?

Found this on the web (it's a problem with Windows 8 though) but maybe this sentence describes the problem you face: "LdapGetSchema: ReadSubSchemaSubEntry failed, hr=0x8007200a, falling back to default schema"?

[tatane]

Indeed you're right. This attribute isn't standard. The post you mentionned is similar to mine, with Win 8 instead of Win Xp.

They talk about Bytes type return, do you think I can get what I want through Bytes type data ?

[water]

The difference I see is that in the article they get the data - but in the wrong format. You do not get the data at all.
At the moment I have no idea how you could access the properties from a XP machine