I’m looking for some guidance with respect to an issue with AAD B2B redemption page.
The below scenario sums up the problem, if you need more details please ask.
The application Admin adds a new user to the Application say xyz#abc.com (external users, not hybrid or from different tenant)
The user gets an invitation.
The user clicks the invitation and sets a password (sample screen shown below).
The user receives an invitation code to the email account mentioned above
The user enters the code and clicks next and receives an error as shown below.
When we traced it back with the help from the Azure support team we got to know that the password was not strong (for ex: contains part of user id), but the error information on the page or the password instructions (8-character minimum) does not clearly mention that. Below are the criteria we passed to the customer which we gathered as part of our conversations with the support team, but we are looking at onboarding ~500 users during the product launch and this is at high risk as we will not be able to pass this to all users or enforce
A strong password must be used. A strong password includes:
• A minimum of 8 characters and a maximum of 16 characters.
• Requires three out of four of the following:
o Lowercase characters. (a – z)
o Uppercase characters. (A – Z)
o Numbers (0-9).
o Symbols (see the previous password restrictions).
• Do not use a part of your user id in the password.
Microsoft enforces a strong password considering security for the cloud user. The password policy is the same as you said. For more details, you could read here.
but the error information on the page or the password instructions
(8-character minimum) does not clearly mention that
For this issue, you could get the support in the Azure AD feedback forum.
Related
Is it just me who's finding AD group is very complex? ;-(
I have a web service that only allows a certain number of role groups to have access. Say we allow people within role group 'rGroupA' to have access.
At some point, a user logs on to our web server, and we have the user name. However, we would not like to ask the user to type in the password.
Is it possible for us to know if this user belongs to 'rGroupA' somehow?
Currently, I could logon our LDAP server with my username and password and see the list of groups I am in. However, I could not search for the groups for my colleagues.
I have searched google for a while but haven't found the answer. It could be that I don't understand LDAP mechanism very well.
Many thanks!
I have an Azure B2C tenant with some identity providers (Facebook, LinkedIn, etc) and a custom claim where the user is able to choose a gender.
During the sing up with one of those, I'm able to get the gender's claim in the token, but this doesn't happen when the user signs in. I was wondering where is the right place to map/include this custom claim since I've been using the base custom policies: SocialAndLocalAccount
Any clue about where to get it? I have my custom claim inside the SelfAsserted-Social's Technical Profile but no luck during the sign in.
The SelfAsserted-Social technical profile will only be executed on the first time the user connects with his social account.
As you can see from the comments in the user journey
Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId).
You need to persist that claim if you want to reuse it as per comment here
If a claim is to be persisted in the directory after having been collected from the user, it needs to be added as a PersistedClaim in the ValidationTechnicalProfile referenced below
You then need to read it from AD in your AAD-UserRead... technical profiles
And output it in your Relaying Party's output claims.
Follow this guide https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-configure-user-input#add-a-claim-to-the-user-interface for the Social profiles where city in the examples is your gender claim.
Currently, I am facing a scenario, where I should differentiate whether a given user belongs to a Gmail account or a G Suite account.
I have the email id of the user. As of now, the only visible difference is that the email address has a different domain name for a G Suite account. For an normal Gmail account the domain name is "gmail.com".
I don't feel safe to rely on this. What is the recommended way to identify the account type of an user?
Thanks in advance.
This is safe to rely on, and many users have already used this technique successfully.
Emails addresses contain only one "#" sign, so in order to verify this you could use a simple function such as:
function isGSuite(email) {
return email.split("#")[1] != 'gmail.com';
}
In fact, there is no API or any other method you can use to check whether the account is actually a GSuite account. Given an e-mail address that is not gmail, there is no public way of determining whether it is part of a GSuite domain, since that could present security and privacy issues.
I have code that calls the Dynamics CRM Web API to get information about a Dynamics user. It doesn't know the user's internal Dynamics identifier ahead of time and thus relies on their Active Directory login as a key in queries.
I have a few doubts and questions about that :
domainname (i.e. user login) is a mandatory field when you create a user in Dynamics, but will it always be non-empty - even when you disable the user for instance?
I noticed that you can indifferently specify a login in the form domain\username and username#fulldomainname at user creation. Login seems to be kept intact inside Dynamics, so when you use the API you must be aware of the format it was entered in in the first place. For instance, searching for mydomain\bob won't give you a bob#mydomain user.
Are there any other possible formats for a user's login in Dynamics CRM or are we safe assuming that it will follow one of these 2 patterns?
Is domainname case-sensitive?
How do Dynamics modules or third party tools that somehow only have windows logins to start with manage to find users deterministically? For instance, we could have an external application that needs to access all the Leads owned by a particular user in Dynamics. Do they systematically try all different login formats and all combinations of cases? I think it would be pretty spooky.
The attribute domainname will not be emptied on disabling the user - this will only affect the state of the record.
It's true that you have to consider both variants if your authentication authority allows both variants (see last point) when using domainname as a query criteria.
I could not think of a real world 3rd variation that allows omitting the domain name.
The domain name is not case-sensitive.
Since there are basically 2 (real world) options for on-premise systems, it's not that spooky after all: You can either authenticate against IIS directly or SSO via STS/ADFS. Both impose the accepted login and use common windows authentication methods.
There's nothing special CRM needs to handle - it relies on users arriving with a valid authentication token.
I'm working on a free service web application where a user registers with username, email, password... standard user account stuff. There is a referral system where if the user refers three other users to sign up (using their referral code) the original user gets account upgrades.
There is incentive to game this by creating three other accounts using their referral code. Any ideas on how to prevent this? Could block IP or use a cookie but these seem like they are easily defeated. I want to make it easy for a user to create an account so I'd rather not do anything that requires extensive effort in account creation.
You could send them a text message and make them reply via text message or email from the mobile.