Azure

Comparison: Microsoft Azure B2C vs Okta Identity Cloud

Just something one of my colleagues had written up and thought was interesting to share. I don’t take credit for it nor full responsibility of accuracy of it. Feel free to rebuttal.

FeaturesMicrosoft Azure B2COkta Identity Cloud
Ability to protect other application's API using OpenID Connect and OUATH protocol/frameworkYesYes
API based enrolmentYes but can't register a phone number that will be used as a MFA factor. The reason being not able to do this is because of OpenID Connect restriction over impersonation principle. This feature might come in 2019.Yes. But Okta user management is not yet OAUTH/OpenID Connect compliant
Federated SSO based on SAML and OpenID ConnectYesYes
Force Password ChangeNo (not out of the box but can be done through customisation)Yes
Identity Lifecycle Approvals (both for self-enrolment, API triggerred enrolment)NoYes (very suitable for Okta to act as external identity onboarding tool)
MFA FactorsOTP over SMS and Voice Call (Officially). Microsoft App (Separate commercials, professional service engagement and not out of the box at the moment. Official support is expected in 2019)OTP over SMS & Voice Call, Octa Verify Mobile App TOTP and Push Notification, Security Questions, Fido U2F, RSA SecurID, FIDO2 Microsoft Hello (very good range of MFA options - a major strength)
Non federated SSONo (It's designed as not to be)Yes (a major strength)
Notification templates customisations (SMS and Email)only EmailBoth Email and SMS
Password RecoveryYes (only SMS/Voice Call/Email OTP as Identity Proofing methods)Yes (all MFA factors can be identity proofing methods)
Programming support for customisationC#. (Java Script support is expected in 2019)C#, Java, Java Script (a major strength)
Risk Scoring and Step-up MFA (Adaptive/Contextual)NoNo. Okta Threat Insight product is in beta phase now. They would be integrating with Okta Identity Platform in 2019. Currently Okta Identity Cloud support a tightly coupled MFA policy when it comes to IP/network zones, black listed countries, region/location, devices etc.
Self-activation of credential such as setting a password post enrolled through an APINo (a major drawback)Yes
Syncing from on-premise ADYesYes
User Interface Customisation and support of CORS (cross origin resource sharing)Yes (But require Custom Sign On policies for flexibility) and a separate Azure Blob storage subscription.Yes. Very flexible to host custom pages in Okta Identity Cloud tenant and also for pages hosted in remote servers.
User management API compliant with OpenID Connect and OAUTHYes (major strength on security here)No (Proprietary protocol at the moment. Quite surprising)
User to Application access mappingNoYes (pretty good on security here)
Web based self-enrolment and activationYesYes

By Piyush Khandelwal, ago

AzureAD: Get List of all users with a particular license

You might have to do reporting and want a list of all users in Azure AD which have a particular license..

Following is an easy way to do so

Get-MsolAccountSku will give you a table of all the License Types you have and count

AccountSkuId ActiveUnits WarningUnits ConsumedUnits
TENANTNAME:AAD_BASIC 300000 0 1
TENANTNAME:AAD_PREMIUM 300000 0 200000
TENANTNAME:AAD_PREMIUM_P2 300000 0 200000
TENANTNAME:POWER_BI_STANDARD 1000000 0 200000

You can then choose the AccountSkuId you want to report on and pass that in the “TENANTNAME:AAD_PREMIUM” of the Get-MSOLUser command

It took me about 20 min to run this report for about 155000 users

By Piyush Khandelwal, ago

Quick Tip: Get local time for next AzureAD Sync

When you run the command

You get an output similar to

AllowedSyncCycleInterval : 00:30:00
CurrentlyEffectiveSyncCycleInterval : 01:00:00
CustomizedSyncCycleInterval : 01:00:00
NextSyncCyclePolicyType : Delta
NextSyncCycleStartTimeInUTC : 18/05/2017 10:55:42 PM
PurgeRunHistoryInterval : 7.00:00:00
SyncCycleEnabled : True
MaintenanceEnabled : True
StagingModeEnabled : False
SchedulerSuspended : False
SyncCycleInProgress : False

You will notice that the time is in UTC..

Quick one-liner can show you local time

Output is more sane

Friday, 19 May 2017 8:55:42 AM

By Piyush Khandelwal, ago

Extending Azure AD Schema via Graph API – The n00b Guide

I’ve been playing recently on try to figure out how I can extend the Azure AD Schema for my tenant.

In my endeavor, I have come across (till now) two way to do it:

  1. Using AADConnect and selecting directory extension to create the attribute in AzureAD in the form of “extension_{AppClientId}_{attributeName}“. This method works only if I have the custom attribute already in my on prem AD.
  2. Using Graph API to create it directly in Azure AD

Will expand on point 2 in this post. In our scenario, we have some custom attributes which are stored in AD LDS. For security and other reasons we didn’t want those attributes to be in our AD.

Goal

Create custom attributes in Azure AD when they are not available to be done via AADConnect Interface

Solution

  • Whenever AADConnect is installed for your tenant, it creates an app called “Tenant Schema Extension App”. You can find it in Azure Portal AAD Blade.

  • Click on the App and note its “Object ID”
  • Open https://graphexplorer.azurewebsites.net/
  • Login with the credentials which have write access to AAD (Global Admin or sorts).
  • In the main window select GET and put in the following URL :

https://graph.windows.net/myorganization/applications/<ObjectID>

You will see the App details in the window

  • To look at its extensionProperties (which shows the custom attributes created) goto the following link

https://graph.windows.net/myorganization/applications/<ObjectID>/extensionProperties

As you would see that it has some custom attributes I have created. The “name” tag has the attribute name with is “extension_{AppClientId}_{attributeName}“.

  • To create a new attribute change the GET to POST and put in the following code to create a new attribute called “newAttribute”

  • Press GO and it will create the new attribute for you

There you go. newAttribute is created and your schema has been extended in Azure AD. You can simply delete that by changing the type to DELETE and putting the URL

https://graph.windows.net/myorganization/applications/<ObjectID of App>/extensionProperties/<ObjectID of attribute>

Limitations

Now here is the bummer. For my scenario I thought when I do then and “Refresh Schema” in AADConnect for AzureAD MA, it will be visible and then I can create custom rules and flows from AD LDS (via Generic LDAP MA). BUT you still can’t see it (tested as of v1.1.524.0) . Microsoft says that this is as per design at the moment. They are thinking of future enhancements or even integrating AD LDS as an option in GUI.

Moreover, if you had directory extension done even by using the GUI (using custom attributes from AD), and you do a refresh schema – it looses those as well saying

The Attribute ‘extension_<GUID>_customAttribute’ could not be located in the schema.

I call this a bug rather than design.

 

Well, in the end, I couldn’t get to reach my end goal (provisioning values from AD LDS to AzureAD via custom schema) but atleast got there half way and understood how to create custom Attributes in Azure AD via Graph API.

 

There is more cool stuff you can do with graphAPI and for the people who are hardcore programmers.. not me atm.. Hit up the links below..

 

References

By Piyush Khandelwal, ago
%d bloggers like this: