Group membership in SharePoint Online

Yesterday, one of my customers asked me to provide her a list of groups and its members for her main SharePoint site. An internal technician used to provide her that information every month by manually going to the site and copying/pasting screenshots of each group.
I decided to use PowerShell for that. I have never used PS cmdlets for SharePoint Online before, so this is my first try. I hope it is useful for you.


$cred = Get-Credential
$adminSite = "https://contoso-admin.sharepoint.com/"
$rootSite =  "https://contoso.sharepoint.com/"
Connect-SPOService -Url $adminSite -Credential $cred

$groups = Get-SPOSiteGroup -Site $rootSite

$objectCollection = $groups |
    ForEach-Object {
        $groupName = $_.LoginName
        $_.Users | ForEach-Object {
            $user = Get-SPOUser -Site $rootSite -LoginName $_
            $properties = @{
                GroupName = $groupName;
                UserName = $user.DisplayName;
                LoginName = $_
            }
            New-Object -TypeName PSObject -Property $properties
        }
    }

Disconnect-SPOService

$objectCollection

Let me know in the comments if there is something that can be done to make it run faster (it takes about 80 second to complete for this specific tenant).

Understanding SIDs

Sometimes times while we are working in the ACL of an object in any computer (especially a domain computer), we found one or more entries with the following format: S-1-5-21-1934748396-2879691208-1016013054-1145 (If our computers are slow enough, we are able to see those numbers before they turn into the actual user or group names).

Those numbers are known as security identifiers and represent a security principal in any Windows computer. Security principal? Ok, let’s start again.

The security model of Windows is based on the subject-action-object tuple. For instance, John Smith (the subject) needs to read documents (the action) in the accounting folder (the object). I’ll talk later about actions and objects, let’s focus now on subjects. Subjects are any entities that can be granted permissions to access an object, they can be users, groups or services. In the Windows language, subjects are Security Principals and each Security Principal has a unique identifier: a SID.

SIDs are composed by the following elements:

Literal “S” - <Revision Level> - <Identifier Authority> - <First Sub Authority + other Sub Authorities> - <Relative Identifier>

Confusing? Let’s check what each part means:

• Literal “S”: All SIDs starts with an “S” which I think it means the identifier is a Security Identifier”.
•  <Revision Level>: currently is always 1.
• <Identifier Authority>: Denotes which entity has issued the SID. Don’t think about the Identifier Authority as an actual object (server, domain, etc.), but as an abstract identity that represents the world (everybody), a local authority (the actual system), a creator (a subject that creates objects) or the NT authority (the actual Windows operating system).Thus, the following values are valid for the Identifier Authority component:

0	SECURITY_NULL_SID_AUTHORITY. Used when the identifier authority is unknown. For instance, the SID S-1-0-0 represents Nobody (no security principal)
1	SECURITY_WORLD_SID_AUTHORITY. Used for SIDs that represent all users. For instance, the group Everyone has the following SID: S-1-1-0
2	SECURITY_LOCAL_SID_AUTHORITY. Used to represent users who logon physically on local terminals. For instance the SID S-1-2-0 represents all users that have logged on locally.
3	SECURITY_CREATOR_SID_AUTHORTY. When a SID with this Identifier Authority is on the ACL list of an object, it will be replaced by the SID of the user of group on the inheritable objects. (I will create a post about this later).
5	SECURITY_NT_SID_AUTHORITY. The actual Windows operating system. All the users you’ll create will start with S-1-5

•  <First Sub Authority + other Sub Authorities>: Denotes a second level of abstract authorities. The most common used values you will see here are:

5 or 6	Represents sessions or processes.
21	SECURITY_NT_NON_UNIQUE. This is the one you’ll see in the users or groups created in your domain or local computer. They will start with S-1-5-21 and be followed by three other numbers that represent your domain or local computer (see the example at the beginning).
32	SECURITY_BUILTIN_DOMAIN_RID. Used for SIDs that represent built-in users or groups. For example, the SID S-1-5-32-544 represent the built-in administrators group.
80	SECURITY_SERVICE_ID_BASE_RID. Used to represent SID for services.

•  <Relative Identifier>: Also known as RID, is the last part of the SID and represent the actual unique ID of the subject within its authorities. The subjects you’ll create will have s random number as RID, but there are also know RID numbers:

500	Administrator
501	Guest
512	Domain Admins
513	Domain Users
514	Domain Guests
515	Domain Computers
516	Domain Controllers
544	Built-In Administrators
545	Built-In Users
546	Built-In Guests
547	Built-In Power Users
548	Built-In Account Operators
550	Built-In Print Operators
551	Built-In Backup Operators

           

You can see more know SIDs on http://support.microsoft.com/kb/243330.

Let’s go back to our example at the beginning:

S-1-5-21-1934748396-2879691208-1016013054-1145

S-1 means it a SID revision level 1.
21 means that it’s a domain or local account.
1934748396-2879691208-1016013054 is the domain ID.
1145 is the unique RID within the domain.

Where are SIDs used?

The main purpose of SIDs is to be used in objects’ ACLs.

How can I get the SID of a subject?

If you are in a domain, you can use the Active Directory Users and Computers snap-in with the advances features enabled (View/Advanced features…) to display the properties of an object and then select its Attribute Editor tab:

You can also use Power Shell:

$user = New-Object System.Security.Principal.NTAccount("Administrator")
$sid = $user.Translate([System.Security.Principal.SecurityIdentifier])
$sid.Value

This will get the SID of the local Administrator. If you want to get the SID of a domain subject, use the following script:

$user = New-Object System.Security.Principal.NTAccount(“domain”, "Administrator")
$sid = $user.Translate([System.Security.Principal.SecurityIdentifier])
$sid.Value

Lastly, I want to mention that the SIDs are also used in the registry to record the settings and profile of each user. You can see (and edit) them in the HK_USERS key. I actually had an issue a while ago with a user profile that somehow got corrupted. I had to get the SID of the user and manually dig on the registry to delete all references to that profile. After doing that, I was able to recreate the profile (be careful of modifying the registry, this is not the recommended solution of cleaning up a profile and in this case it was the only way I could do it).

I hope you enjoyed this post!

Sharing free/busy information between two Office 365 tenants

Recently, I was asked for one my customers, which is an Office 365 tenant, to share its free/busy information of Exchange Online with one of its partners ( another Office 365 tenant).

I looked for information about how to accomplish this, and my findings were out of the budget (some guys suggested to create an hybrid deployment on one of the sites). I even asked the question in the Office 365 community and the first answer was that it wasn't possible. The same MS representative replied days later with the solution: create organization relationships (aka Federated Delegation).

Long story short, in order for two Office 365 tenants to share free/busy information, you need to use Power Shell to connect to Exchange Online and then run the following command:

Get-FederationInformation -DomainName <the other cloud-based organization> | New-OrganizationRelationship -Name <the other tenant domain> -FreeBusyAccessEnabled $true -FreeBusyAccessLevel LimitedDetails

The full sequence of commands is:

Remember to do this command in both tenants if you want to have a both sides relationship.

Next, instruct your users to share their calendars with users in the other tenancy:

Finally, users on the other tenancy will be able to see free/busy information when creating a meeting request: