Customer has moved into Azure AD and needs clarification on two behaviors he is seeing in order to broadly roll out to organization and get off prem.
1- Right now , they have “keep me signed” in configured in Azure AD, however they have shared devices - iPad – in retail stores where they don’t want that behavior and want people to log in every time for websites. Is there a way to set a subgroup of users that keep me signed in will not apply to? Right now they only see a policy setting to configure it on or off for entire organization.
2- Customer turned on self-service password reset portal, how they only see option to configure what options they have to authenticate to be across whole org. Can they set up different options for different groups of users on what is needed to reset password and confirm identity - retail does q&a - business does authentication, etc.
Answer to Q1:
KMSI is controlled via the company branding, and is not on a per-user, but on a "per-language" (because you can have different branding for different locales). In that sense KMSI cannot be controlled on a per-user basis.
Answer to Q2:
SSPR has 3 states - None, Selected, All. When you choose Selected you can chose a single security group for which SSPR will be enabled. All other users will not have SSPR enabled.
Related
I'm creating a set of hands-on lab users in my Azure AD for access to Azure Labs. We will reuse these user accounts (and reset the passwords after every lab session).
My challenge is that these users are being required to configure MFA. Which I THINK is called the Azure AD Interrupt Mode described here.
Is there a way to exclude these group of users from being required to set this up?
I think this can be disabled entirely by navigating to Azure AD - Default Directory - Properties - Manage Security Defaults (right at the bottom of the page) - Enable Security Defaults - set it to No.
If it's per user basis, then Navigate to Azure AD - All users - Per User MFA - this will list all the users and then you can select "n" number of them to either enable or disable MFA.
// Answering my own question and hope it helps someone.
The first and obvious step is to disable MFA. This is described in this link: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates
After this, however, you may still face the interrupt wizard as shared in the screenshot of the question above. This is due to Self-Service Password Reset (SSPR) being enabled. If SSPR is enabled, then MFA is still required for them to be able to do a password reset.
Solution 1: If you want SSPR enabled, then create a Conditional Access policy requiring MFA upon sign in.
This way, MFA is only triggered when user wants to do an SSPR.
For this lab user scenario, you will still have to set-up MFA one-time for each of the users (you may use the same contact details).
Extra note: I tried setting the MFA details by bulk using PowerShell. However, it is not possible to set an MSOL user object's StrongAuthenticationUserDetails property.
Solution 2: Disable SSPR or limit to selected users using AD groups
Don't include the lab users in the selected users group. Since SSPR is not allowed for these users, the extra MFA details won't be asked of these users anymore.
Drawback: The setting is to include user groups which should have SSPR. There's no option to exclude just the lab users.
Solution 2 works for me but may not work for everyone.
My team just "inherited" an Archer setup with 2 ADs and LDAP sync setup for each of them. The LDAP sync works fine individually; we are able to see the users/groups as per the LDAP configuration's filters. However, we have some groups in AD#1, that contain users from AD#2 and the LDAP sync is only showing/pulling users from 1 AD in Archer. I'm on Archer 6.4.
My question:
Is it possible at all in Archer to get the groups to show members from the 2 AD's?
Does the LDAP service account need any special permissions?
Anything else that I'm missing, or any viable workarounds?
I have looked at this question which talks about some possibilities but it's quite old so starting a new question. Any help is greatly appreciated.
The question you referenced is related to Archer v5.x and v6.x, so everything I mentioned there is still valid as of 2019-04-26.
Back to the questions you asked:
Is it possible at all in Archer to get the groups to show members from the 2 AD's?
The answer is "Yes", but not that simple.
If you check tables on the back end you can see that there are two type of groups:
Manually created groups by Archer admins. These groups are not part of any LDAP source and you can't synch these groups/users.
Groups created via LDAP Synch. These groups and users are synched with LDAP Synch configuration.
In your case, if you have two LDAP synchs configured then you will have two sets of LDAP groups and two sets of LDAP users, assuming LDAP synch is configured to add and synch groups and users using filters correctly.
Based on what you shared if you have group "ABC" in both LDAP sources you will have two groups added to Archer. On the back end in the table tblGroup they will have different "ldap_config_id" values, but same name.
Same applies for users - if you have user "User1" in both LDAP sources you will end up with two users with different domains and different "ldap_config_id".
Back to your question - Yes, if you have two LDAP sources with same group name you will end up with two groups with same name, each group should have users from corresponding LDAP assigned, if you configured both LDAP synchs to add and synch groups and users.
If this doesn't work this way for you, then review your LDAP synch configuration. Your may not have an option enabled to synch groups or don't have any filters in place to get them.
Does the LDAP service account need any special permissions?
In Archer - no, but in LDAP source (Active Directory) the account you specified in LDAP configuration should have access to query certain areas. The account you use for 2nd LDAP may not have access to query groups. I'm not an expert in AD security, you should talk to AD admin on this matter.
Anything else that I'm missing, or any viable workarounds?
See the old question/answer you referenced. LDAP synch principals in Archer v5 and v6 are the same as I know.
Best solution in my opinion is to establish "virtual link" or trust between both Active Directories. Third AD can be created with both AD#1 and AD#2 merged or linked. This way you can query AD#3 and have groups and users provided for you by using only one LDAP synch configuration/Domain. This is the simplest solution for you, but your AD admin will have to do some work.
You can check other options in the old question as well.
P.S: the instance I develop for had 2 LDAP sources, but I configured them to have unique group names and unique users. This way collisions don't occur.
Good luck!
Hahn, I'm uncertain how Archer handles users from two different AD's that members in the same group found in the first AD.
It's best to reach out to Archer support and pose the question to them.
I'm also seen a simlar question in RSA Partner Community. Support may respond to that post then here or other clients that have had the same issue.
Our application (referred to as "XYZ_App" below) is a multi-tenant SaaS application. We are in the process of making it available for Microsoft AppSource as a multi-tenanted "Web app / API" (referred to as "AppSourceXYZ_App" below).
We started our OpenID Connect implementation with endpoints pointing to “common” as per stated in the documentation when multi-tenancy is desired/required.
In XYZ_App, we added information in the system to know what AAD instance each XYZ_App tenant is associated with (using the GUID Microsoft assigned to this AAD instance, we are NOT using the "rename-safe.onmicrosoft.com" representation).
When using the “common” endpoints, we had to manually validate the issuer from the JWT to make sure it was the expected one: a user could access XYZ_App requesting access to XYZ_App’s tenant associated with contoso.onmicrosoft.com, get directed to “login.microsoftonline.com/common” to authenticate and then decide to authenticate with a user from another AAD instance (referred to as "anotherAADInstance.onmicrosoft.com" below). In this scenario, even though a user could successfully authenticate on anotherAADInstance.onmicrosoft.com, XYZ_App’s redirect URI must make sure the JWT issuer is the one from contoso.onmicrosoft.com. I’ll refer to this setup as Scenario_1.
With that scenario in mind, we thought about NOT using “common” and customize the requests going to login.microsoftonline.com on the fly; attempting to “jail” requests to be forced to authenticate against a specific AAD instance. We would still need to perform our validation in the redirect URI to make sure the issuer is the appropriate one, but we thought this approach might make our lives easier. I’ll refer to this setup as Scenario_2.
Do you envision Scenario_2 is viable in the long run or is it too short-sighted ? Based on my current knowledge of OpenID Connect, one limitation I can see with Scenario_2 is that it would become problematic to support “broker accounts” into our app.
Explanation of “broker accounts”: in our industry, some external users are allowed access to the system. Let’s say I have a company called “BrokerCo” (with their own brokerco.onmicrosoft.com AAD instance) who has 2 employees: Broker1 and Broker2. BOTH anotherAADInstance and contoso hired Broker1 and Broker2 to get broker services to perform tasks in XYZ_App; requiring XYZApp to grant them access. What is the ideal way for authentication from an OpenID Connect standpoint ? If XYZ_App were to use “login.microsoftonline.com/common” for authentication (like in Scenario_1; as opposed to “jailed” access like in Scenario_2), Broker1 and Broker2 could authenticate with brokerco.onmicrosoft.com (no AAD "External users" for anotherAADInstance nor contoso), but they would then get to redirect URI with an issuer that is different than what XYZ_App’s anotherAADInstance and contoso tenants are configured for... I feel like I’m back to square 1...
Do you have suggestions or pointers to solve this issue ?
Background context:
While playing with OpenID Connect issuers, I got the following error message:
AADSTS50020: User account 'testuser#anotherAADInstance.onmicrosoft.com' from identity provider 'https://sts.windows.net/XXXXXXXX-fake-GUID-9bZZ-XXXXxxxxXXXX/' does not exist in tenant 'XYZ Publisher' and cannot access the application 'YYYYYYYY-fake0-GUID-YYYYyyyyYYYY' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
Thanks in advance !
Your question has multiple layers, trying to address most of them:
AppSource is about trial experiences for new users: this mean that any corporate account around the globe can potentially be an user of your SaaS application - or at least to the trial experience of your application, therefore the first thing you need to think when integrating with AppSource is how easy it has to be for a potential user to experience your app for the first time.
With that in mind, AppSource recommends that the trial of application is build on such a way that allows any user from any organization to sign-in, and therefore a multi-tenant approach for your application is the recommended setup for any application.
The single-tenant approach requires more control on your side, and for a trial experience - it means that the user cannot try your application right away because the operation you have to do on your single-tenant application is to add the user to an Azure Active Directory tenant as a guest user. This guest account will need then to wait receiving an email to accept the invitation to join to this tenant you are adding the user to then sign-in to your application.
Therefore your scenario 1 is the best scenario thinking on a trial experience in general, and also in general require less management (as you'd not need to create/ manage each individual account that needs to access your application as guest users of your Azure AD instance).
However some concerns you listed - that this scenario bringing are valid: Because you are accepting the common endpoint, you are saying basically that any user can sign-in to any tenant to your application, and this may not be desirable. In addition, the scenario you listed that a user can generate a token for any application is also valid, however, you can add additional checks to make this more secure and that any token generated by another authentication is blocked:
You can validate the 'audience' claim to guarantee that the token was issued to your application
You can eventually check the 'tid'/'iss' claims against of a list of tenant Ids in your database to see if that the user's organization is a valid organization in your application -- this would be valid for non-trial users/ organizations.
More information in this article.
About scenario '2' and broker accounts:
This scenario could be interpreted in two different ways:
Broker accounts are guest accounts of a customers' Azure AD tenant
Broker accounts are third party accounts but are not actually added as a user of anotherAADInstance or contoso AD
If your case is '1' then you're right: if your application needs to authenticate guest users that belong to another Azure AD tenant, then common endpoint could not be used directly.
If your case is '2' then what you'd need to do is to continue using the common endpoint and somewhat after the user is authenticated ask them to choose the company. I am describing this on generic terms without fully understanding this scenario. Perhaps this is not simple as you want the remote company to control this and not the user - so some additional complexities may need to be handled here.
A note is that if your scenario is scenario 1. - in theory - you can still use an hybrid approach, where you'd ask user to type the username inside the application and the company that they want to sign-in, then check if you need to validate the user against common or tenant-id endpoint, preparing the request and then sending a login_hint argument when authenticating. More information here
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 am currently working on a AD installation where there are about 45,000 accounts and about 60+ global catalogue servers, some accounts are active some are disabled. Some active accounts are service account which don't appear to login as the lastlogondate is several months old.
If I disable some of the service accounts which do not login the application stops working so I know the application is authenticating to AD somehow.
My question is how can I determine which account have been used to authenticate but have not actually 'logged in'? Is there an attribute I can query or can I set it somehow that AD writes to the event log?
Simply speaking, lastLogonTimestamp is the right attribute to find inactive accounts.
See following link for descriptions on different related attributes:
http://social.technet.microsoft.com/wiki/contents/articles/22461.understanding-the-ad-account-attributes-lastlogon-lastlogontimestamp-and-lastlogondate.aspx
Just copied from above link, using PowerShell, you can get inactive users (inactive for AROUND 90 days, note lastLogonTimestamp is only an approx value) by calling:
Search-ADAccount -AccountInactive -DateTime ((get-date).adddays(-90)) -UsersOnly
For the last logon time from Hyena, I suspect it is inaccurate.
(I never use Hyena before, so just a guess.)
From the following link:
http://www.systemtools.com/HyenaHelp/index.htm#userlogoninfo.htm
Seems by default it only get the last logon info from one DC only. If they get this info from lastLogon attribute instead of lastLogonTimestamp (very likely, otherwise the "Check All Domain Controllers" option is meaningless), it will only get the logon time on this specific DC only. So if those service account are always using DC1 in recent authentications but you connect to DC2 to get the logon time, you will only get a very old time (or none if it never use DC2 to authenticate).
I don't know what function or technique you are using in Hyena to get the 'last logon' information, but as indicated by others, the AD attribute 'lastlogontimestamp' will get you a fairly accurate date/time (~within 10-day accuracy) of the last use of an account. This attribute can be added to any query in Hyena for all of your users. You can also export out the service information on all computers and servers, to see what accounts are being used.
If you need additional assistance, contact SystemTools Support - support#systemtools.com
We are always ready to support our customers.
(I am with SystemTools (Hyena) support)