Connecting to Objects in the Global Catalog
In the tutorial article "LDAP Bind: Establishing a Connection to the Directory" was described how to connect to a directory object in a script in general. On this page, we want to focus on connections to objects in the global catalog. Please remember: There is only read access to the global catalog, and only a subset of the attributes is provided there.
Global Catalog Bind using the user ID the script is run with
We use a normal Bind operation where the LDAP path name is changed, so that the TCP-Port-Nummer 3268 is used. This works for the function GetObject and also with OpenDSObject.
Prerequisite, of course, is that the regarding server 'server.cerrotorre.de' has been set up as a global catalog.
Here's an easier option that utilizes a special form of the pathname, where
the term 'LDAP' is simply replaced by 'GC'. So the special port number
3268 can be omitted:
A Serverless Binding can be run also when you are in Active Directory environments. Then a global catalog will automatically be searched by DNS:
Global Catalog Bind using special credentials
The common method of binding to the directory always works when a logged on user wants to access objects of his own domain respectively his own Active Directory forest. However, it might quite often be necessary to access a directory service where you are not an currently authenticated user. In that case, the bind variation OpenDSObject allows to pass the username and password and thus the logon to e.g. foreign forests is possible.
In this example the OU object of the domain company.com is accessed by logging on the server 'controller.domain.com' with the username 'administrator' and password 'P@ssw0rd'. The last parameter (1) acts as a logon-flag, ensuring a secure Kerberos logon.
ADSI
Reference in MSDN: OpenDSObject()
The username of an AD logon can be given in the following way:
| Pure logon name | e.g. 'administrator', for this, the logon-flag needs to be set to '1' (secure logon) |
| NetBIOS logon name | e.g. 'DOMAIN\administrator' |
| User principal name | e.g. 'administrator@domain.com' |
| Distinguished name | e.g. 'cn=administrator,cn=users,dc=domain,dc=com', for this, the logon-flag needs to be set to '0' (clear text logon). |
The logon flag determines the type of access. Important are the two values '0' (for encrypted logon in clear text) and '1' (for secure logon via Kerberos or NTLM). Of course, a secure logon should be preferred to clear text logon. However, situations may arise when an insecure clear text logon is needed. Especially when using a bind operation to logon to other directory services like Novell eDirectory or OpenLDAP systems, the logon-flag must be set to '0'. In order to avoid a disclosure of the password from the net, the use of LDAP-SSL is recommended - then the whole traffic of the LDAP protocol is encrypted.
Microsoft
explanations of the logon flag in MSDN
The server name can be left out in the LDAP pathname of Active Directory environments and it is automatically bind to an accessible domain controller of the own domain. Also, username and password can be provided as NULL string (''), then the logon data of the own user is used automatically. This possibility might be useless if using the bind option for the logon to another forest DC - thus, server and logon data have to be indicated accordingly.
Global Catalog Bind over LDAP SSL
You can also use LDAP-SSL to connect to the global catalog. Simply use the TCP-Port-Nummer 3269 (instead of 3268) to initiate the connection. However, this is working only if a valid SSL certificate was installed on the server before.
Global Catalog Bind without knowing the own Domain / Forest name
In many cases you want to develop scripts that run in different Active Directory environments.
Think about a script that e.g. displays any information about certain objects
within the own domain or is responsible for specific changes. In order
that this script runs in any domains, you could let pass the domain name
as parameter. But it is more sophisticated to automatically identify the
current domain name by querying the Active Directory itself through severless
binding.
The relevant information can be read in a special directory entry, available
on every domain controller: the rootDSE (Root
Directory Service Entry).
You can read here the distinguished name of your own domain from the attribute
'defaultNamingContext' and make an LDAP
pathname right away with which the desired domain objects can be accessed.
The next example shows how to detect the name of the root domain in the own forest. You can use the ADSSystemInfo COM object for this - the returned DNS name has to be converted to an LDAP-Pfad: