on AD objectsid instead of objectguid should be used

Windows uses the ObjectSID to identify users and the SID-History property to track when a user moves between domains.

TL;dr

If any object is moved within a domain, both objectSID and objectGIUD remain unchanged. If any object is moved to another domain, the objectSID changes, but not the objectGUID. If any object is copied (to anywhere), both objectSID and objectGUID will be different. It should never happen that two objects have the same objectSID or objectGUID.

We already had a case where a mass change of the cn property on a copy of all the users and then moving them back under the original ou caused a change of all GUIDs. So whenever we touch the user identification logic, we should store the objectsid, so we can use the sidhistory property in AD to correctly identify the user.

From

• How security identifiers work

Security Identifiers and Globally Unique Identifiers

When a new domain user or group account is created, Active Directory stores the account's SID in the Object-SID (objectSID) property of a User or Group object. It also assigns the new object a globally unique identifier (GUID), which is a 128-bit value that is unique not only in the enterprise, but also across the world. GUIDs are assigned to every object that is created by Active Directory, not just User and Group objects. Each object's GUID is stored in its Object-GUID (objectGUID) property.

Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of an object's properties that is published in the global catalog. Searching the global catalog for a User object's GUID produces results if the user has an account somewhere in the enterprise. In fact, searching for any object by Object-GUID might be the most reliable way of finding the object you want to locate. The values of other object properties can change, but the Object-GUID never changes. When an object is assigned a GUID, it keeps that value for life.

If a user moves from one domain to another, the user gets a new SID. The SID for a group object does not change because groups stay in the domain where they were created. However, if people move, their accounts can move with them. If an employee moves from North America to Europe, but stays in the same company, an administrator for the enterprise can move the employee’s User object from, for example, Contoso\Noam to Contoso\Europe. If the administrator does this, the User object for the account needs a new SID. The domain identifier portion of a SID that is issued in Noam is unique to Noam; so the SID for the user’s account in Europe has a different domain identifier. The relative identifier portion of a SID is unique relative to the domain; so if the domain changes, the relative identifier also changes.

When a User object moves from one domain to another, a new SID must be generated for the user account and stored in the Object-SID property. Before the new value is written to the property, the previous value is copied to another property of a User object, SID-History (sIDHistory). This property can hold multiple values. Each time a User object moves to another domain, a new SID is generated and stored in the Object-SID property and another value is added to the list of old SIDs in SID-History. When a user logs on and is successfully authenticated, the domain authentication service queries Active Directory for all the SIDs that are associated with the user — the user's current SID, the user's old SIDs, and the SIDs for the user's groups. All these SIDs are returned to the authentication client and are included in the user's access token. When the user tries to gain access to a resource, any one of the SIDs in the access token, including one of the SIDs in SID-History, can allow or deny the user access.

If you allow or deny user’s access to a resource based on their jobs, you should allow or deny access to a group, not an individual. That way, when users change jobs or move to other departments, you can easily adjust their access by removing them from certain groups and adding them to others. However, if you allow or deny an individual user access to resources, you probably want that user's access to remain the same no matter how many times the user's account domain changes. The SID-History property makes this possible. When a user changes domains, there is no need to change the access control list (ACL) on any resource. If an ACL has the user's old SID but not the new one, the old SID is still in the user's access token, listed among the SIDs for the user's groups, and the user is granted or denied access based on the old SID.

The reason for using SIDs, and not GUIDs, is for backward compatibility. Windows NT uses SIDs to identify users and groups in ACLs on resources; so you do not have to change ACLs on your resources when you upgrade. In Windows 2000 and Windows Server 2003, ACLs continue to identify users and groups by SID, not GUID — even ACLs on resources in Active Directory. For example, a user gains access to a Group Policy object based on one of the user's SIDs, not on the GUID for the User object.

Also see

• What Are Security Identifiers?
• https://docs.microsoft.com/en-us/windows/desktop/ADSchema/c-user
• https://docs.microsoft.com/en-us/windows/desktop/ADSchema/a-objectguid
• https://docs.microsoft.com/en-us/windows/desktop/ADSchema/a-objectsid
• German description of ObjectSID and a conversion code

Start by tracing the user identification logic in this PHP LDAP app and review how Active Directory exposes objectSID and sIDHistory. The issue does not name files or tests; done would mean identifying the affected logic and ensuring users remain correctly identified after cross-domain moves using the stored SID information.