Azure – Integrate Azure AD B2C with ServiceNow

If you aren’t familiar with Azure AD B2C, it is a customer identity access management (CIAM) solution and is a separate service from Azure Active Directory (Azure AD). It is built on the same technology as Azure AD but for a different purpose. It allows businesses to build customer facing applications, and then allow anyone to sign up into those applications with no restrictions on user account. Azure AD B2C uses standards-based authentication protocols including OpenID Connect, OAuth 2.0, and SAML.

In an earlier post, I detailed steps on how to configure ServiceNow with Azure AD SSO. In this post, I will go through steps on how to integrate Azure AD B2C with ServiceNow.

Below is a diagram show the high level implementation steps on how to do this integration,

OpenID Connect (OIDC) is an identity layer built on top of the OAuth protocol, which provides a modern and intuitive Single Sign-on (SSO) experience. ServiceNow supports OIDC to authenticate users in Azure B2C.

I will not cover the Azure AD B2C tenant creation steps in this post.

Create new user flow

A user flow lets us determine how users interact with our application when they do things like sign-in, sign-up, edit a profile, or reset a password.

  1. Sign in to the Azure portal
  2. Make sure you’re using the directory that contains your Azure AD B2C tenant. Select the Directories + subscriptions icon in the portal toolbar
  3. On the Portal settings | Directories + subscriptions page, find your Azure AD B2C directory in the Directory name list, and then select Switch
  4. In the Azure portal, search for and select Azure AD B2C
  5. Under Policies, select User flows, and then select New user flow
  1. On the Create a user flow page, select the Sign up and sign in user flow
  2. Under version, select Recommended, and then select Create
  1. Enter a Name for the user flow. For example, su_si-1
  2. For Identity providers, select Email signup
  3. Under User attributes and token claims, choose the claims and attributes to collect and send from the user during sign-up. Select Show more, and then choose attributes and claims. Click OK. Below screenshot shows the attributes I’m collecting but it is up to you. These attributes can be modified in the user flow at any time
  1. Click Create to add the user flow. A prefix of B2C_1_ is automatically prefixed to the name

Create App Registration

  1. Stay logged into the Azure portal
  2. Make sure you are in the B2C directory
  3. In the left navigation menu, under Manage, Click App registrations, and then select New registration
  4. Enter a Name for the application. For example, ServiceNow
  5. Under Supported account types, select Accounts in any identity provider or organizational directory (for authenticating users with user flows)
  6. Under Redirect URI, select Web then enter your ServiceNow instance with /navpage.do in the URL text box
  7. Under Permissions, select the Grant admin consent to openid and offline_access permissions check box
  8. Click Register

Create a client secret

The client secret is also known as an application password. The secret will be used by ServiceNow to exchange an authorization code for an access token

  1. In the left menu, under Manage, select Certificates & secrets
  2. Click New client secret
  3. Enter a description for the client secret in the Description box. For example, SnowSecret
  4. Under Expires, select a duration for which the secret is valid, and then select Add
    • Note down the secret’s Value for use in ServiceNow. This value is never displayed again after you leave this page

Information needed to configure ServiceNow instance

  1. Click on the Overview, copy the Application (client) ID
  2. Next Click Endpoints
  3. Copy the value in Azure AD B2C OpenID Connect metadata document
  4. Replace with the User flow name we created earlier e.g. B2C_1_su_si-1. Browse to the URL in a Web browser to confirm you have the right URL
  5. You should have these 3 values,
    • Application (client) ID
    • Client Secret Value
    • OIDC well-known endpoint

Configure ServiceNow Instance

Hopefully, you already have SSO enabled in your ServiceNow instance. If not, please refer to this earlier post of mine

  1. Search for multi-provider sso and click Properties
  2. Enable multiple provider SSO
    • You’ll be asked to setup a recovery account
  1. Under Multi-Provider SSO and click Identity Providers
  2. Click New
  3. Click OpenID Connect
  4. In the Import OpenID Connect Well Known Configuration window, provide following information
    • Name = Name of the IdP you wish. Example, B2C
    • Client ID = Application (client) ID from Azure B2C application
    • Client Secret = Client Secret Value we created earlier in the application
    • Well Known Configuration URL = URL we constructed earlier with the policy name
  5. Click Import
  1. Make sure the new IdP is marked Active and Show as Login option is checked
  1. Click on the OIDC Entity tab and click to open the OIDC Entity
  2. Click on OAuth Entity Scopes, double-click on OAuth scope and replace openid with the below value
    • Use your Application (client) ID from B2C app registration
<Application (client) ID> openid offline_access profile email

This OAuth Scope value is required to generate an access token and without that ServiceNow will error out with a missing parameter. I realized this later on based on my research. I initially left it at openid and searching with the error, lead me to this.

  1. Click Update to save changes
  2. Click on OIDC Provider Configuration
  3. Click on OIDC provider value
  1. Update the User Claim to emails
  1. Click Update
  2. To keep things simple, I’m not enabling the Automatic user provisioning option
    • You can choose to enable automatic user provisioning during user login. When automatic user provisioning is enabled, a user record is automatically created in the ServiceNow instance if that user record does not exist.
  3. Back in the Identity provider window, Click Update to save the OIDC Identity Provider values
  4. Navigate to the login page of the instance to verify that IdP appears as a login option
  1. Create a test user in ServiceNow and login with the credentials to test if the IdP configuration works
  2. Optionally you can browse to the login page with the URL in following format,
    • To determine the sys_id, open the OIDC Identity provider we created, right-click on the grey bar and click Copy sys_id
    • Replace this sys_id in the URL below
    • This URL will take you directly to the sign-in page
https://<yourinstance>/login_with_sso.do?glide_sso_id=<sys_id>

Hope this post helped you in setting up your ServiceNow instance with Azure AD B2C.

Thank you for stopping by. ✌

Office 365 – Plus Addressing – Updated

What is Plus addressing?

Plus addressing or subaddressing is available in Exchange Online. Plus addressing is using a unique, dynamically created receive-only email addresses for mailboxes.

  • Basic syntax of an SMTP email address: @. Example, JohnD@domain.com
  • Plus addressing syntax: +@. Example, JohnD+statements@domain.com

The original email address must be valid one. The +tag value is arbitrary, although regular character restrictions for SMTP email addresses apply.

Here is a scenario, Let’s say the users’ email address is JohnD@domain.com. User can use plus addresses as unique addresses for services that you sign up for, right after the local part (JohnD) and add (string) of choice. So for instance, to receive all bank statement, the user can end up with something like this: JohnD+statements@domain.com

Plus addressing Limitations

When using plus addressing, there are a few things to keep in mind:

  • Plus addresses aren’t aliases in Exchange Online
    • Hence, it can be used only to receive messages and not send them
    • It does not resolve to a user’s name in Outlook clients, so it is easily identifiable in the To and CC fields
  • In a Hybrid environment, plus addressing won’t work for on-premises mailboxes that do not resolve in Exchange Online
  • Web Developers are aware of plus addresses and some online forms/services won’t accept a plus sign in the email field
  • Some subscription services require the user use the original email address that they subscribed with
    • Can’t unsubscribe with plus email address

Enabling the feature

Enable using the Exchange admin center

  1. Login to the new Exchange admin center (https://admin.exchange.microsoft.com)
  2. In the left navigation menu Settings > Mail flow
  3. Select Turn on plus addressing for your organization, and then select Save

Note: After the plus addressing is turned on by default in April 2022, you will see the option Turn off plus addressing for your organization if you are following the above steps. Which will be unchecked meaning it is turned on. So placing a checkmark will turn off plus addressing. See screenshot below.

Enable using Exchange Online PowerShell

Before proceeding further make sure you are connected to Exchange Online,

$o365cred = Get-Credential
Connect-ExchangeOnline -credential $o365cred

The cmdlet uses below syntax:

Set-OrganizationConfig -AllowPlusAddressInRecipients $true

Disable using Exchange Online PowerShell

This setting will be effective only after plus addressing is turned on by default in all organizations starting in late April 2022. Before that happens, plus addressing can be disabled in the O365 tenant by using the AllowPlusAddressInRecipients parameter I described earlier with the value $false value. This can also be proactively set, you don’t have to wait for it to be turned on by default.

To disable plus addressing in the O365 tenant:

Set-OrganizationConfig -DisablePlusAddressInRecipients $true

Determine settings with PowerShell

To determine plus address related settings in the exchange organization:

Get-OrganizationConfig | Select *PlusAddress* | fl

Hope this helped you in understanding the plus address settings in O365.

Thank you for stopping by. ✌

Azure AD – Create Dynamic Groups

In Azure AD you can create dynamic groups based on user or device properties. Users or devices can be automatically added or removed based on the group’s definition, so you don’t have to maintain the list of users in this group manually.

Whenever any property of a user or device changes, all dynamic group rules in your Azure AD tenant are reevaluated to determine if the user or device should still remain in the group. If a user or device satisfies a rule on a group, they are added as a member and If they no longer satisfy the rule, they are removed.

Manually adding or removing users from dynamic groups is not allowed.

Why use Dynamic Groups?

Simply put, dynamic groups have query-based memberships. This helps in maintaining group membership and application access depending on the query defined. For example, A dynamic group can be defined for all Marketing department users based on the value filled in the ‘department’ attribute. The conditions can also be combined. Following the same example above, a dynamic group of all Marketing department users from New York or a dynamic group with a list of users who report to a specific manager and need access to an application.

In a scenario where you are maintaining user access to applications based on the department, location, this comes in handy.

Note: You need Azure AD P1 and above to be able to create dynamic groups.

Dynamic Groups in Azure AD

Azure AD admin center provides a rule builder to create and/or update the dynamic group rules.

In the below steps I’ll create a dynamic group in my tenant with users who are in the Marketing department,

  1. Sign in to the Azure AD admin center portal (https://aad.portal.azure.com/) as global administrator
  2. Select Azure Active Directory –> Click on the Groups tab –> New group
  3. In New Group:
    • Select Security as the group type
    • Enter ‘Marketing Department Users’ as the name and description for the group
    • Change Membership type to Dynamic User
  4. Select Owners and in the Add Owners blade search for any desired owners. Click on the desired owners to add to the selection
  5. Click Select to close the Add Owners blade
  6. Click Add dynamic query in the Dynamic user members
Creating new group
  1. On the Dynamic membership rules blade:
    • In the Property field, click on the existing value and select department
    • The Operator field as Equals
    • Select the Value field and type ‘Marketing Department Users’
membership rules

Azure AD now provides an option to validate dynamic group rules. On the Validate rules tab, you can validate your dynamic rule against sample group members to confirm the rule is working as expected. This feature is now in public preview.

validate rules

The rule builder supports the construction of up to 5 expressions. You also need to use the text editor for setting operator precedence, and for writing more complex rules. The rule builder can’t be used to reproduce every rule.

‘Add Expression’ disabled after 5 expressions defined

If the rule builder doesn’t support the rule you want to create, the text box can be used. And below are some of the scenarios to use the text box,

  • Rule with more than 5 expressions
  • Direct reports rule
    • For the rule to work, make sure the Manager property is set correctly for users. If you are syncing from your on-premise AD, make sure the Manager attribute is filled
    • When the manager’s direct reports change in the future, the group’s membership is adjusted automatically
    • This rule can’t be combined with any other membership rules
  • Setting operator precedence
    • All operators are listed below in order of precedence from highest to lowest. Operators on same line are of equal precedence:
      1. -eq -ne -startsWith -notStartsWith -contains -notContains -match –notMatch -in -notIn
      2. -not
      3. -and
      4. -or
      5. -any -all
  • Rules with complex expressions
    • Property consists of a collection of values; specifically, multi-valued properties
      • assignedPlans
      • proxyAddresses
    • Expressions use the -any and -all operators
      • -any (At least one item in the collection matches the condition)
      • -all (All items in the collection match the condition)
    • Value of the expression can itself be one or more expressions

Constructing a membership rule

Three parts of a simple rule are Property, Operator and Value

Supported properties

Three types of properties that can be used to construct a rule are Boolean, String and String collection.

The following are the user properties that can be used to create a single expression.

Boolean

PropertiesAllowed valuesUsage
accountEnabledtrue falseuser.accountEnabled -eq true
dirSyncEnabledtrue falseuser.dirSyncEnabled -eq true

String

PropertiesAllowed valuesUsage
cityAny string value or null(user.city -eq “value”)
countryAny string value or null(user.country -eq “value”)
companyNameAny string value or null(user.companyName -eq “value”)
departmentAny string value or null(user.department -eq “value”)
displayNameAny string value(user.displayName -eq “value”)
employeeIdAny string value(user.employeeId -eq “value”)
(user.employeeId -ne null)
facsimileTelephoneNumberAny string value or null(user.facsimileTelephoneNumber -eq “value”)
givenNameAny string value or null(user.givenName -eq “value”)
jobTitleAny string value or null(user.jobTitle -eq “value”)
mailAny string value or null (SMTP address of the user)(user.mail -eq “value”)
mailNickNameAny string value (mail alias of the user)(user.mailNickName -eq “value”)
mobileAny string value or null(user.mobile -eq “value”)
objectIdGUID of the user object(user.objectId -eq “11111111-eeee-1111-aaaa-111111111111”)
onPremisesSecurityIdentifierOn-premises security identifier (SID) for users
who were synchronized from on-premises to the cloud.
(user.onPremisesSecurityIdentifier -eq “S-1-1-11-1111111111-1111111111-1111111111-1111111”)
passwordPoliciesNone DisableStrongPassword DisablePasswordExpiration DisablePasswordExpiration, DisableStrongPassword(user.passwordPolicies -eq “DisableStrongPassword”)
physicalDeliveryOfficeNameAny string value or null(user.physicalDeliveryOfficeName -eq “value”)
postalCodeAny string value or null(user.postalCode -eq “value”)
preferredLanguageISO 639-1 code(user.preferredLanguage -eq “en-US”)
sipProxyAddressAny string value or null(user.sipProxyAddress -eq “value”)
stateAny string value or null(user.state -eq “value”)
streetAddressAny string value or null(user.streetAddress -eq “value”)
surnameAny string value or null(user.surname -eq “value”)
telephoneNumberAny string value or null(user.telephoneNumber -eq “value”)
usageLocationTwo lettered country/region code(user.usageLocation -eq “US”)
userPrincipalNameAny string value(user.userPrincipalName -eq “alias@domain”)
userTypemember guest null(user.userType -eq “Member”)

String Collection

PropertiesAllowed valuesUsage
otherMailsAny string value(user.otherMails -contains “alias@domain”)
proxyAddressesSMTP: alias@domain smtp: alias@domain(user.proxyAddresses -contains “SMTP: alias@domain”)

Supported expression operators

Operators can be used with or without the hyphen (-) prefix. Contains operator does partial string matches but not item in a collection matches. Following are the supported operators and their syntax for a single expression,

SyntaxOperator
-neNot Equals
-eqEquals
-notStartsWithNot Starts With
-startsWithStarts With
-notContainsNot Contains
-containsContains
-notMatchNot Match
-matchMatch
-inIn
-notInNot In

Supported values

Values used in an expression can consist of several types, including:

  • Strings
  • Boolean = true or false
  • Numbers
  • Arrays = number array, string array

To specify a null value in a rule, you can use the null value. The -not operator can’t be used as a comparative operator for null.

Common rules in a typical environment

Below, I will go over some of the rules that are typically used in production environments

“Direct reports” rule

This rule supports only the manager’s direct reports. A group consisting of manager’s direct reports and their reports can’t be created.

Use below syntax. Object ID can be found in the user’s(in this case, the user who is the manager) profile in Azure AD.

Direct Reports for "{objectID_of_manager}"
Direct reports rule

“All users” rule

Include only members of your organization and exclude guest users.

(user.objectId -ne null) -and (user.userType -eq "Member")
all users

Device Rules

A rule to select devices objects can also be created for membership in a group. Both users and devices as group members is not allowed.

Below are the device attributes,

Device attributeValuesExample(s)
accountEnabledtrue false(device.accountEnabled -eq true)
displayNameany string value(device.displayName -eq “Bob iPhone”)
(device.deviceOSType -eq “iPad”) -or (device.deviceOSType -eq “iPhone”)
(device.deviceOSType -contains “AndroidEnterprise”)
(device.deviceOSType -eq “AndroidForWork”)
(device.deviceOSType -eq “Windows”)
deviceOSVersionany string value(device.deviceOSVersion -eq “9.1”)
(device.deviceOSVersion -startsWith “10.0.1”)
deviceCategorya valid device category name(device.deviceCategory -eq “BYOD”)
deviceManufacturerany string value(device.deviceManufacturer -eq “Samsung”)
deviceModelany string value(device.deviceModel -eq “iPad Air”)
deviceOwnershipPersonal, Company, Unknown(device.deviceOwnership -eq “Company”)
enrollmentProfileNameApple Device Enrollment Profile name, Android Enterprise Corporate-owned dedicated device Enrollment Profile name, or Windows Autopilot profile name(device.enrollmentProfileName -eq “DEP iPhones”)
isRootedtrue false(device.isRooted -eq true)
managementTypeMDM (for mobile devices)(device.managementType -eq “MDM”)
deviceIda valid Azure AD device ID(device.deviceId -eq “d4fe7726-5966-431c-b3b8-cddc8fdb717d”)
objectIda valid Azure AD object ID(device.objectId -eq “76ad43c9-32c5-45e8-a272-7b58b58f596d”)
devicePhysicalIdsany string value used by Autopilot, such as all Autopilot devices, OrderID, or PurchaseOrderID(device.devicePhysicalIDs -any _ -contains “[ZTDId]”) (device.devicePhysicalIds -any _ -eq “[OrderID]:179887111881”) (device.devicePhysicalIds -any _ -eq “[PurchaseOrderId]:76222342342”)
systemLabelsany string matching the Intune device property for tagging Modern Workplace devices(device.systemLabels -contains “M365Managed”)

Update an existing rule

  1. Sign in to the Azure AD admin center portal (https://aad.portal.azure.com/) as global administrator
  2. Select Azure Active Directory –> Click on the Groups tab –> All groups
  3. Select a group to open it
  4. On the profile page for the group, select Dynamic membership rules
update an existing rule
  1. After updating the rule, select Save

Dynamic Groups with PowerShell

To create dynamic groups

Use the New-AzureADMSGroup cmdlet,

New-AzureADMSGroup -DisplayName "Sales Department Users" -Description "Sales Department Users" -MailEnabled $false -MailNickname "SalesDepartmentUsers" -SecurityEnabled $true -GroupTypes "DynamicMembership" -MembershipRule "(User.department -eq ""Sales"")" -MembershipRuleProcessingState "On"
PowerShell: New-AzureADMSGroup

To update dynamic groups

Use the Set-AzureADMSGroup cmdlet,

Set-AzureADMSGroup -Id '23c2768b-6cef-4006-a052-d9b288b4d17c' -MembershipRule "(User.department -eq ""Sales"") and (user.city -eq ""Tulsa"")"
PowerShell: Set-AzureADMSGroup

Another interesting part I came across when I was exploring dynamic groups is, I was trying to create a dynamic group of administrators to whom I can assign an Azure AD role. And it turns out, the membership type for role-assignable groups must be Assigned and can’t be an dynamic group. This makes sense as automated population of groups could lead to unwanted access being granted.

Thank you for stopping by. ✌

Teams – Reports with PowerShell – Updated

It is important to know about the current state of your Teams rollout and this is one of those which can easily get out of control in a blink of an eye. I wanted to understand and determine the current Teams state in a tenant I manage and I had to create reports to present.

The portal does give a few options to export the data but I decided to take a look at the option the Teams PowerShell module offers. I spent some time on creating a script that will output these five reports,

  • All Teams data with Channel type, Channel count, Channel count with types, Teams member count and owners count
  • Teams users data with role information
  • Channel information for each Teams with Channel types
  • Channel user information with user information and role
  • Permissions on each Teams

This report can also be scheduled to run if you already use a mechanism to store your credentials securely and pass it on to your PS scripts.

I use the ImportExcel PowerShell module for this script,

Install-Module -Name ImportExcel

Before proceeding further, make sure you have the Teams PowerShell module installed. You’ll need to run this script with Teams Administrator role.

$TeamsCred = Get-Credential
Connect-MicrosoftTeams -credential $TeamsCred

$xlsxPath = ".\Teams-Report_$((Get-Date).ToString("MMddyyyy")).xlsx"

Get-Team | Select GroupId,DisplayName,MailNickName,Archived,Visibility,Description | foreach {
        $ID = $_.GroupId
        $TeamName = $_.DisplayName
        $NickName = $_.MailNickName
        $Archived = $_.Archived
        $visibility = $_.Visibility
        $Description = $_.Description
        $ch = Get-TeamChannel -GroupId $ID
        $ChannelCount = $ch.count
        $TeamUser = Get-TeamUser -GroupId $ID
        $TeamMemberCount = $TeamUser.Count
        $TeamOwnerCount = ($TeamUser | ?{$_.role -eq "owner"}).count
        $stdchannelCount = ($ch | ?{$_.MembershipType -eq "Standard"}).count
        $privchannelCount = ($ch | ?{$_.MembershipType -eq "Private"}).count

        [PSCustomObject]@{
                  'Teams Name'=$TeamName;
                  'Teams MailNickName'=$NickName;
                  'Teams Type'=$Visibility;
                  'Description'=$Description;
                  'Archived?'=$Archived;
                  'Channel Count'=$ChannelCount;
                  'Standard Channel Count'=$stdchannelCount;
                  'Private Channel Count'=$privchannelCount;
                  'Team Members Count'=$TeamMemberCount;
                  'Team Owners Count'=$TeamOwnerCount} | Export-Excel -Path $xlsxPath -WorksheetName "All Teams Report" -TableStyle Medium16 -AutoSize -Append
}

Get-Team | foreach {
    $ID = $_.GroupId;
    $TeamName = $_.DisplayName;
    $NickName = $_.MailNickName;
    Get-TeamUser -GroupId $ID | Select User,Name,Role |
    Foreach {
		[PSCustomObject]@{
			'Teams ID' = $ID;
			'Teams Name' = $TeamName;
			'Teams MailNickName' = $NickName;
                        'User UPN' = $_.User;
			'User DisplayName' = $_.Name;
			'Role' = $_.Role
		}
    }
} | Export-Excel -Path $xlsxPath -WorksheetName "Teams_users" -TableStyle Medium16 -AutoSize

Get-Team | Foreach {
    $ID = $_.GroupId;
    $TeamName = $_.DisplayName;
    $NickName = $_.MailNickName;
    Get-TeamChannel -GroupId $ID | Select Id, DisplayName, MembershipType |
    Foreach {
		[PSCustomObject]@{
			'Teams ID' = $ID;
			'Teams Name' = $TeamName;
			'Teams MailNickName' = $NickName;
			'Channel Name' = $_.DisplayName;
			'Channel Type' = $_.MembershipType
		}
	}
} | Export-Excel -Path $xlsxPath -WorksheetName "Channels" -TableStyle Medium16  -AutoSize

Get-Team | Foreach {
    $ID = $_.GroupId;
    $TeamName = $_.DisplayName;
    $NickName = $_.MailNickName;
    Get-TeamChannel -GroupId $ID | Select DisplayName | 
            Foreach {
            $chName = $_.DisplayName;
                Get-TeamChannelUser -GroupId $ID -DisplayName $chName | Select User,Name,Role |
                    Foreach {
		                [PSCustomObject]@{
			                'Teams Name' = $TeamName;
			                'Channel Name' = $chName;
                                        'User UPN' = $_.User;
                                        'User DisplayName' = $_.Name;
                                        'User Role' = $_.Role
		    }
        }
    }
} | Export-Excel -Path $xlsxPath -WorksheetName "Channel_Users" -TableStyle Medium16  -AutoSize

Get-Team | foreach {
   $nickName = $_.MailNickName
   Get-Team -MailNickName $nickName | Select -Property * |
	Foreach {
		[PSCustomObject]@{
			'Teams ID' = $_.GroupId;
			'Teams Display Name' = $_.DisplayName;
                        'Teams MailNickName' = $nickName;
                        'Giphy Allowed?' = $_.AllowGiphy;
                        'Giphy Content Rating' = $_.GiphyContentRating;
                        'Allow Stickers And Memes' = $_.AllowStickersAndMemes;
                        'Allow Custom Memes' = $_.AllowCustomMemes;
                        'Allow Guest to Create & Update Channels' = $_.AllowGuestCreateUpdateChannels;
                        'Allow Guest to Delete Channels' = $_.AllowGuestDeleteChannels;
                        'Allow Members to Create & Update Channels' = $_.AllowCreateUpdateChannels;
                        'Allow Members to Create Private Channels' = $_.AllowCreatePrivateChannels;
                        'Allow Members to Delete Channels' = $_.AllowDeleteChannels;
                        'Allow Members to Add & Remove Apps'= $_.AllowAddRemoveApps;
                        'Allow Members to Create Update Remove tabs' = $_.AllowCreateUpdateRemoveTabs;
                        'Allow Members to Create Update Remove Connectors' = $_.AllowCreateUpdateRemoveConnectors;
                        'Allow Members to Edit Messages' = $_.AllowUserEditMessages;
                        'Allow Members to Delete Messages' = $_.AllowUserDeleteMessages;
                        'Allow Owner to Delete Messages' = $_.AllowOwnerDeleteMessages;
                        'Allow Team Mentions' = $_.AllowTeamMentions;
                        'Allow Channel Mentions' = $_.AllowChannelMentions;
                        'Show In Teams Search & Suggestions' = $_.ShowInTeamsSearchAndSuggestions
		}
    }
} | Export-Excel -Path $xlsxPath -WorksheetName "Teams_permissions" -TableStyle Medium16 -AutoSize

Hope this script was helpful in determining the current state of your Teams deployment.

Thank you for stopping by. ✌

Azure AD – Implement Single Sign-On with ServiceNow

In this post I will go over the steps required to implement Azure AD SSO integration with ServiceNow. With this in place, it is easier to control access to your ServiceNow implementation and also allow your users to login with their domain credentials.

ServiceNow also supports user account provisioning which I will cover in a later post.

I’ve updated this post for ServiceNow San Diego version. The earlier versions may have different UI options but the steps behind the integration mostly remains the same.

High level implementation steps

In Azure AD add ServiceNow to Enterprise Applications

To configure this integration, first step is to add ServiceNow from the gallery to your list of managed SaaS apps. Below are the steps,

  1. Login to Azure AD Admin Center and click on the Enterprise applications tab
  2. To add new application, Click New application
  3. In the Browse Azure AD gallery section, enter ServiceNow in the search box
  4. Select ServiceNow and you can name it to differentiate from development to production instance with a prefix but in this scenario, I’ll leave it as default as in screenshot below. Click Create
  5. It takes a few seconds for the app to be added
Search ‘ServiceNow’
add ServiceNow by clicking ‘Create’

Configure Azure AD SSO

Below steps details how to enable SSO in Azure AD portal for the ServiceNow application,

  1. On the ServiceNow application page, select SAML-based Sign-on under the Manage section. Select SAML
  2. Select the edit icon in the Basic SAML configuration section
Basic SAML config

Your ServiceNow administrator should know this information and if not, you can contact ServiceNow support. But in general, this information is easy to figure out. I’ve mentioned the format of these URLs below. and I have used my own instance’s URL in the screenshot.

Identifier (Entity ID)https://{your-instance-name}.service-now.com
Reply URLhttps://{your-instance-name}.service-now.com/navpage.do
https://{your-instance-name}.service-now.com/customer.do
Sign on URLhttps://{your-instance-name}.service-now.com/login_with_sso.do?glide_sso_id=[sys_id of sso configuration]
Logout URLhttps://{your-instance-name}.service-now.com/navpage.do

Please follow along and I have a step below on how to determine the sys_id value from ServiceNow for the Sign on URL. Refer to Step 16. under the ‘Configure ServiceNow’ section below.

Below screenshots show values from my environment. I constructed the Sign on URL based on the sys_id information I got from ServiceNow as mentioned above

  1. In the SAML Signing Certificate section, find Certificate (Base64). Click Download to download Certificate(Base64), and then save the certificate file to your computer.
Download Certificate(Base64)

Create ServiceNow test user

  1. In ServiceNow portal, go to User Administration > Users
  2. Click New, complete the properties for your new user, and click Submit

Most organizations do ‘Automated user provisioning’ and this way you won’t have to create all the users in your Azure AD domain onto ServiceNow. But to make the SSO part easier, co-ordinate with your ServiceNow administrator and create an user account in ServiceNow with the email ID of a user in your Azure AD.

Configure ServiceNow

  1. Login on to your ServiceNow application portal as an administrator
  2. In the left pane, search for the System Definition section from the search box, and then select Plugins
ServiceNow plugins
  1. Search for Integration – Multiple Provider single sign-on Installer
  2. Right-click, and select Activate/Repair
search plug-in and activate
  1. Select Activate
Click Activate
wait till activation complete
Click Close & Refresh List
  1. In the left pane, search for the Multi-Provider SSO, and then select Properties
  1. Enable multiple provider SSO option is not active as in screenshot below and this is because Account Recovery is not setup. This comes in handy if something goes wrong with the SSO configuration and prevents admins from being locked out.
Enable multiple provider SSO not active
  1. Place a checkmark next to Enable account recovery to enable it
Account recovery properties
  1. Now back on the Customization Properties for Multiple Provider SSO page, place check mark next to below options,
    • Enable multiple provider SSO
    • Enable Auto Importing of users from all identity providers into the user table
    • Enable debug logging for the multiple provider SSO integration
    • The field on the user table that…,
      • email
Customization Properties for Multiple Provider SSO options
  1. Click Save to save configuration
  2. In the left pane, search for the Multi-Provider SSO, and then select Identity Providers
  1. Click New
  1. select SAML
  1. In the Import Identity Provider Metadata, select URL
    • The Metadata Url can be found in the Azure AD ServiceNow application SAML Signing Certificate section
    • Copy the App Federation Metadata Url value
Azure AD App Federation Metadata Url
  1. Paste the App Federation Metadata Url from Azure AD under Enter the URL and click Import
Paste the App Federation Metadata Url value
  1. Right click on the grey bar at the top of the screen and click Copy sys_id and save this value in a notepad to construct your Sign on URL in Azure AD
  1. The import metadata url reads the metadata and populates all the necessary information
    • Enter a name for your configuration. I’ve named it ‘Azure AD’
    • Confirm the NameID Policy is set to urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    • Select Advanced. In User Field, enter email
SSO config
  1. Scroll down to the Encryption And Signing tab and X.509 Certificate section, and select New
  2. Open the .cer file with notepad which was downloaded from Azure AD and saved to your PC
    • copy the entire content and leave it in the clipboard
Azure AD certificate open using notepad
  1. Paste the contents in PEM certificate section
    • Provide a Name
    • Select Format as PEM
  2. Click Submit
x.509 certificate
  1. Click Update
Click Update
  1. Click Test Connection at the upper-right corner of the page
    • Sign-in using the test user account created earlier in the ‘Create ServiceNow test user’ section
    • Click Close
  1. Click Activate
Click Activate
  1. Ensure Default and Active are checked like in screenshot below
Active enabled
  1. To ensure ServiceNow auto-redirects the users to Azure AD SSO, click on the Set as Auto Redirect IdP in the Related Links section
Set as Auto Redirect IdP
Auto Redirect IdP is enabled
  1. Click Update to save the configuration

Test SSO

  1. Open ServiceNow portal
    • Use Incognito or InPrivate mode to avoid previously saved cookies
  2. The portal should auto-redirect to login.microsoftonline.com and prompt a sign-in

Issues you may encounter and How to fix it

Error: Ensure that the user you are trying the test connection with is present in the system.
Ensure that ‘User Field’ property value corresponds to the value set in the IDP returned through ‘Subject NameID’ in the response.

Fix: I tried the SSO with a user ID that only existed in Azure AD and not in ServiceNow. The System didn’t know what to do and hence the error..duh!

Error: SAML2ValidationError: Signature cryptographic validation not successful

Fix: I imported the PEM certificate from Azure AD into ServiceNow but I forgot to save it by not clicking update

This should help you with the Azure Active Directory single (SSO) integration with ServiceNow. I believe I’ve covered everything in this process.

Thank you for stopping by.✌