We are currently testing the feature EnforceCloudPasswordPolicyForPasswordSyncedUsers (https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization#public-preview-of-the-enforcecloudpasswordpolicyforpasswordsyncedusers-feature) which makes it possible for a tenant to comply to the Azure AD password expiration policy when a user password has expired.
By default, If the customer uses Password Hash Synchronization (PHS), the value DisablePasswordExpiration is set for every user. Which means that If a password is expired on-premise, the user is still able to make use of any Azure AD integrated services. Since we want them to comply the password expiration policy set in AD/AAD, we want this feature configured.
I have this feature working in a LAB environment with a demo M365 tenant.
Situation LAB: 1 AAD Connect Server - 1 M365 tenant - PHS enabled - Specific OU synced - ForcePasswordChangeOnLogOn feature enabled
When I create a new user with the feature enabled, it sets the value to DisablePasswordExpiration, when I initiate a password change on-premise it changes the value from DisablePasswordExpiration to None as expected.
Now the challenge, in the dev environment of the customer.
Situation: 1 AAD Connect Server - 1 M365 tenant - PHS enabled - Specific OU synced - ForcePasswordChangeOnLogOn feature enabled
When I create a new user, it does not have any value set. It should have the DisablePasswordExpiration set, but it doesn't. When I initiate a sync between on-prem and AAD, the value doesn't appear.
When I change the password on-prem for an existing user WITH the value DisablePasswordExpiration value set, it changes the value to "None". So in the above scenario for the feature does not work for newly created users, but does works for existing users.
The feature EnforceCloudPasswordPolicyForPasswordSyncedUsers is enabled in both cases.
Related
We have a C# web app for new customer intake, at the end of which the user enters a password value we apply to their new Active Directory user object when we invoke the userPrincipal .NET method to create their user object. Our code also creates an account in our Azure AD tenant, with the correct values (ImmutableID) set for Azure AD Connect to import and join both accounts on its next pass (30 minutes AADC cycle wait time not acceptable for our requirements). We sync our password hashes from on-premise AD to Azure AD, and we have password complexity enabled in AD, and we enabled and added our own vocabulary to the Banned Words (substrings) facility in Azure AD. We are considering installing the MS "Password Protection" service on our DC's that will also apply Azure Banned Words checking when passwords are updated on-premise.
To keep this question short, we really would like to pre-validate the user entered passwords against all the password policies, including the banned words list (assume we install that service on all our on-prem DCs), but we can't find a method or service in .NET that will pre-validate that a proposed password passes all the active password policies. Our users tend to use Azure Self Service Password Reset, on-premise password changes later on are rare. But in the C# programming, it appears you have to actually request an Add of a new AD username to get .NET to evaluate the password value and signal status back, from the userPrincipal method in .NET
Anyone got any tricky ideas how to get a password pre-validated against AD password policies without the context of adding an actual new user, but assuming that the sAMAccountName that will be submitted does NOT yet exist in Active Directory? We thought about creating a temporary AD user with hash or base64 of a GUID for a unique temporary usernames, get any password evaluation feedback back from .NET, then delete the temporary user object, but that's a lot of overhead just to check a password, would trigger replications and generate beaucoup EventViewer and AD-AuditPlus log events, much junk network traffic. Thank you.
My Azure AD admin have created an Enterprise App for me and I'm Configuration Owner for it.
The app Provisioning is setup to:
Provision Azure Active Directory Groups
Provision Azure Active Directory Users
to my SCIM server.
The setup is working fine, users are created via and groups are updated also.
My problem is that in my company workflow when a consultant contract is renewed the user's AccountEnabled property is set to false and then later re-enabled with AccountEnabled=true, this is translating right now into a Delete / Create via SCIM in my app.
My impression was that AccountEnabled=false would translate to a isSoftDeleted=true (as mentioned in Customizing user provisioning attribute-mappings for SaaS application in Azure Active Directory) and that in turn will translate to a SCIM Disable User request because of the attribute mapping settings of the app is to map the Azure Active Directory Attribute Not([IsSoftDeleted]) to active attribute in the app.
But it's not disabling the user it's deleting it.
The user resides in a on-premises Active Directory then synced to Azure AD.
All the information that I could find (like this) suggest that a SCIM Delete should only happened after 30 days when a user is hard deleted and not when AccountEnabled=false so I guess it may be another factor at play.
So, how do I stop Azure AD from issuing Delete user for disabled users in my app?.
EDIT: I tested with a local user in Azure AD (not synced from the on-premises AD) and with that user when the user is disabled it triggers an update user not a delete. So it must be related with synced users only (I'm still troubleshooting)
Certain applications don't support soft deletes so the Azure AD provisioning service sends a delete in place of an update. What app are you using?
The attribute mapping blade allows you to de-select delete as an option, do the deletes stop when you do that?
I recommend keeping the attribute mappings as close to the default as possible.
Try removing the "not" function and using the default attribute mappings. The default mapping uses a switch statement to map false to true and true to false. It sends the request as a string rather than a boolean.
I am using AzureAD and Intune, I have joined Window 10 workstations to our AzureAD and users log in with their AzureAD account details.
How can I use InTune device policies to govern password complexities for AzureAD a specific group of users? I have attempted to use the password section of "Device Configuration" but that appears to only apply to local user account.
The policy we would like to create is:
Password change frequency - 30 days
Minimum password length - 10 characters
Complex (Uppercase, lowercase, alpha numeric and symbols)
Apply to a specific group of users.
You cannot have the intune device policy govern password requirements for azureAD. That's not how it works, intune would only govern settings for local accounts on either windows or mobiles. As AzureAD has its own password requirements that is set by Microsoft and cannot be changed. here are the Microsoft settings: https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-policy#password-policies-that-only-apply-to-cloud-user-accounts
If you had azureAD DS (Domain Services) you could set a password policy on that, which would accomplish what you want, however azure AD DS would need to be set up. and machines would need to be joined to it. https://learn.microsoft.com/en-us/azure/active-directory-domain-services/password-policy
I'm working on improving the user experience for our org when logging into snowflake. We have adfs sso enabled and are provisioning mapping users to roles using azure ad. I had a colleague attempt to sign in with SSO who didn't have a user account created in snowflake and they were greeted with
"The signed in user <user#email.com> is not assigned to a role for the application (Snowflake)".
My question is, is it possible to have users sign into snowflake without being mapped to a default role, perhaps only have the public role assigned, and without being synced with azure ad.
If it is, i'd appreciate any pointers to documentation i can reference. The goal is to get all users that can SSO, to by default be able to login
AD group syncing occurs every 40 minutes in Microsoft, and I don't believe it's possible to force a sync or change this time frame. In addition, like the OP mentioned Snowflake cannot connect to an on-prem ADFS server so all users must be in Azure AD.
AD group syncing is somewhat configurable via the "Scope" (see Step 15 of this tutorial)
If your Scope is set to "Sync only assigned users and groups", you can either
Change the scope to "Sync all users and groups" (may cause issues if you don't want to import all this data into Snowflake)
or
Confirm that your desired users' AD group is one of those assigned to be synced to Snowflake (requires manually assigning these users, or that all of these users are part of the same AD group that you choose to sync to Snowflake).
By seeing the error its not allowing user who don't have appropriate role for the application.
In these why can't we create generic stored procedure to assign default role and instance to new user based on the group they belong to.! Each time if we add any new user then we have to run stored procedure to assign default role and object prior to his login to snowflake.
I have a multitenant ASP.NET application using OpenIdConnect and Azure AD as an Identity provider for Office 365. When the user is authenticated I receive my claims in ClaimsPrincipal.Current.
I wanted to identify a user and store this id reference in my database. I asked this question.
It was replied that
When trying to identify a user uniquely [NameIdentifier] should be your go-to choice.
But it seems that the NameIdentifier claim, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
depends on the application. Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user. Keep in mind that the we may have to create another Azure AD manifest (because we could need other scopes) and we should be able to find back the same end-users.
Meanwhile, I remarked another claim: ObjectIdentifier http://schemas.microsoft.com/identity/claims/objectidentifier
It seems that ObjectIdentifier, is the same for all Azure AD-secured application for a given Office 365 user.
Can you explain precisely the difference between those two claims? And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user.
I made a quick test as following:
Register a multi-tenant-webapp and single-tenant-webapp in AD Contoso.
Log in with user1#contoso.onmicrosoft.com and get the name identifier in both web applications, it turns out the name identifier are the same in both applications. So the name identifier should be able to identify users cross applications, but it can not be used to identify the user in Azure AD.
For the object identifier, it is a GUID which you can used to identify a user in Azure AD. For example, you can use object identifier to query the user in Azure AD.
Powershell:
$msolcred = get-credential
connect-msolservice -credential $msolcred
get-msoluser -ObjectId "{guid:object_identifier}"
And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Based on my understanding, the object identifier is a GUID which can identify for a user in Office 365 subscriptions.
Or to put it another way:
The NameIdentifier is the GUID of the Application which is registered in Azure AD. This won't change whether it's a single or multi-tenant application. It won't matter if you are using client credentials (i.e. AppId and AppSecret) to authenticate AS the application or using logging using real user credentials (i.e. delegated), the NameIdentifier will remain the same.
The ObjectIdentifier is the User Principal Name (UPN) for the user when using delegation or Service Principal Name (SPN) of the application when using client creds.
The reason you see different ObjectIdentifier values when an application is multi-tenant is that there is a separate and unique SPN in EACH TENANT which points back to the ApplicationGUID in the tenant where the application is registered. This SPN is used to assign rights to the application against resources in each tenant.