Microsoft Student Partner Virtual University FSD

MVP Community Pakistan Microsoft MVP Community is partnering with PlanX to invite you for a thrilling and Pakistan’s 1st ever meetup on Intel Realsense using Microsoft C # code samples.  We’ll be joined by Mr. Omar Barlas. O

SID vs. GUID
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 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 will yield 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 find. 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.
However, SIDs can sometimes change. The SID for a Group object won't change. Groups stay in the domain where they were created. But people move and when they do, their accounts can move with them. If Alice moves from North America to Europe, but stays in the same company, her account can be transferred with her. An administrator for the enterprise can simply move her User object from, say, Reskit\Noam to Reskit\Euro. If he does, the User object for Alice's account needs a new SID. The domain identifier portion of a SID issued in Noam is unique to Noam, so the SID for Alice's account in Euro 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.
Thus 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 the all of the SIDs associated with the user—the user's current SID, the user's old SIDs, and the SIDs for the user's groups. All of 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, could allow or deny the user access.
The reason for maintaining a SID history is obvious. If you allow or deny users access to a resource by virtue of their jobs, you should allow or deny access to a group, not an individual. This 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 will be granted or denied access based on the old SID.
The reason for using SIDs at all, and not GUIDs, is for backward compatibility. Windows NT uses SIDs to identify users and groups in ACLs on resources. You shouldn't have to change ACLs on all your resources when you upgrade, simply because someone came up with a better scheme. So, in Windows 2000, ACLs continue to identify users and groups by SID, not GIUD—even ACLs on resources in Active Directory. A user gains access to, say, a Group Policy object, based on one of the user's SIDs, not on the GUID for the User object.

Watch Build Live
https://channel9.msdn.com/LiveEmbedPlayer/Build2016

Channel 9: Videos about the people building Microsoft Products and Services Channel 9 keeps you up to date with videos from people behind the scenes building products at Microsoft.

Watch Build Live
https://channel9.msdn.com/LiveEmbedPlayer/Build2016

Attention ! Here's your gateway to leverage the latest Microsoft technologies to create web : http://aka.ms/noq02i

TechRewards gives you a last chance to attend Build 2016 in person! Activity TechRewards gives you the chance to attend the Build 2016 conference by doing what we do best…. giving you challenges to complete! Follow these tasks and you could be handsomely rewarded with... an entry into our sweepstakes to attend Build 2016!

Create a UWP app that can run on any Windows-based device from phones, tablets, to PCs.
http://spr.ly/6188BwFhp

It's game time!
Learn the tools and skills you need to build games for Windows PCs, tablets, and mobile devices.

http://aka.ms/mdfbfh

Sign up to Microsoft Virtual Academy and build your dev skills! New web, mobile, and game development courses added every week.

https://mva.microsoft.com/