If a user logs in to their computer using a Single Sign-On system such as Active Directory, LDAP, or Kerberos, is it possible for applications they run to know who they are and what system they authenticated with? Can I get enough information out of these systems to verify their identity without requiring any additional user input?
Specifically, I would like to be able to check these things:
Did they log in via a single sign-on system at all, or are they just using a regular user account on this machine?
What system did they use?
Does the system have some URI that would distinguish it from any other directory?
What is the current user's distinguished name in that directory?
Can I get some information which I can pass to another host to prove to that host that the user is who they said they are? For example, a token that can be used to query the SSO system.
I'd assume all of these things should be possible, and in fact encouraged, but I am not positive. I'm sure the method of getting at this information is
SSO (at least with Kerberos which is used by ActiveDirectoy) is based on a token. As soon as the user requests access to a kerberized system the system queries for the token and checks its validity for accessing the system. It's as good as querying for username and password. when the user did not log in with an Kerberos-account there is no tiket so no automated access.
using the token you can get the users login- name and from that you can then use that to query the SSO-backend (typically LDAP) for more information on that user.
LDAP is not an SSO-system as it is simply a storage query protocol but it is often used as backend for SSO-systems.
The problem often is kerberizing an application. for Webapps that means you have to kerberize the webserver so that that one then can handle the authentication process with the SSO-service and then pass that information on to the unferlying webapp.
Hope that answers you questions.
for more information have a look around the web for kerberos
You are really asking about two things:
Authentication: Who are you?
Authorization: What are you allowed to do?
Kerberos really only answers the first question, you need a secondary system like LDAP or Active Directory ( which is both kerberos and ldap in a single server) to answer the second.
If your system is using kerberos correctly, any user login should have an associated kerberos ticket. With this ticket, you can request "service" tickets
to prove your identity to remote servers that support kerberos. The ticket
contains your principal identity in the realm ( user#DOMAIN.NET ) that can be
used to query authorization systems.
However, the details required to get all the moving parts in that sentence working together "on the same page" so to speak can be very complex. The remote service has to support accepting kerberos credentials, it has to be either in the same realm or have a cross realm trust relationship configured.... The list
gets pretty long. Depending on your exact application environment, using all these things can be fairly trivial, or it can be next to impossible.
Related
"Issue description copied..."
I'm building a partner connector, which relies on a user name and password to connect to database (very similar to the existing Postgres / MySQL connectors provided by Google). In order to verify the credentials, I also need the database host information to be present in addition to username and password and this is the base of my problem.
The Google build connectors conveniently are allowed to collect user credentials and the database related information at the same time. Unfortunately, that doesn't seem to be the case for partner connectors as stated in the requirements
Point 5 "Use appropriate authentication method in getAuthType(). Do not request credentials via getConfig()."
The authentication itself happens before any other configuration details are known (there is just a dialog for username and password) and there doesn't seem to be a way to request additional information on the authentication screen itself. Once the credentials have been entered, the verification also happens immediately, before the configuration is being shown in the next step.
Once credentials are validated successfully, Datastudio then assumes the schema and data can be requested.This excludes the option of a dummy confirmation, because there doesn't seem to be a way to tell credentials are invalid and need to be changed after checking the other configuration details on the next screen.
That makes me unsure, how to determine valid credentials in my use case as I need to know the variable endpoint to authenticate against. I definitely want to avoid storing any user credentials myself in an external database, because this opens up another can of worms.
Has anyone successfully solved a similar issue before and can provide guidance here?
This is a known limitation of the authentication methods for Community Connectors.
A workaround would be to use authtype NONE and then request the credentials and database information in the config. This is, however, not a recommended approach.
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.
Deploying the same HTTP based application on several web servers (srv1, srv2, etc). Protecting the application with SPNEGO auth. The servers are Linux and AD doesn't know of their existence, i.e. they are not joined to the domain. I've got the whole SPNEGO working smoothly on a single host. Now moving on to the subsequent hosts.
Most guides I've found will tell you that you need
An account in AD
A SPN
A keytab (generated on the AD server and then
moved to the Linux host)
While I believe that (2) + (3) will always need to be per-server, I'm somewhat uncertain about (1). Can I do with only one account? I would really like to not having all these accounts in AD if I can do with only one.
This blog has a good recipe for how it can be done: The first invocation of ktpass (for srv1) should be as described in the all the guides you find on the internet, however subsequent invocations (for srv2, srv3, etc) should be using the -setpass and -setupn options.
However I've found that when one uses the ktpass.exe tool the account's userPrincipalName attribute changes to become as given by princ argument from the last invocation of ktpass. So the name of the srv, e.g. srv3 is coded into the name and the name of the account will therefore basically change with each invocation of ktpass. When the web server performs the final step in the SPNEGO chain of events, which is to contact AD using the keytab as credentials, it will look for an account in AD with a userPrincipalName equal to the SPN and this step will therefore fail. (source, scroll to last post, list item 3). Contradicting this is that I'm using Tomcat and thereby JAAS and as far as I understand I can hardcode the principal name to use in my jaas.conf file thereby effectively ignoring the principal name from the keytab.
Can multiple app servers + single account in AD ever work and if so how?
In short, yes it will work and I will tell you how. First of all let's clarify some things and some statements not properly described in your question or the comments:
You have three machines which serve the same DNS name, this means that you either have a DNS round-robin: service.example.com will returned a shuffled list if IPs or a load-balancer (hard of sort) will only one IP for the A record depending on the load. For Kerberos, both setups are equal in the outcome.
Now, you cannot say that the AD does not know the existence of a service or a server if you require Kerberos authentication. It will and must know otherwise it cannot create service tickets for your clients which they pass on to the server. Additionally, Tomcat will not contact the KDC to accept the security context because the service ticket is encrypted with the account's long-term key.
Here is the approach: You have already figured out that one SPN can be bound to one machine, multiple bindings are not allowed. This is the case when you have the machine name bound to the machine account (srv1$, etc.). You need a service account. The service account is a regular account without password expiration, e.g., my-service#EXAMPLE.COM. For this account, you will bind your CNAME or A record. Have you Tomcat authenticator to accept all securty contexts with this service account and it will work.
How to create this magical service account on a Unix-like OS?
Use mskutil to
create the service account,
create a keytab for that service account,
bind your SPN to that service account and have the keytab updated.
After that you will have a keytab suitable for your use. Verify with an LDAP query (e.g., with Softerra's LDAP browser or else) that the account exists, the SPN (servicePrincipalName) is bound to that account and you are done.
Important: if any of your clients use MIT Kerberos or Heimdal, you must set rdns = false your your krb5.conf.
Godspeed!
I'm using Jespa to do transparent ntlm sign on. I want to be able to authenticate the users in multiple windows domains. I have it working with one domain. How do I add another?
Thanks
I asked this question to ioplex support. They gave me a good answer. Here it is:
"Only the first element in the chain can do SSO because once the HttpSecurityService challenges the browser with information for the first domain, the browser cannot start over for a different domain. At least not in the same request. Ideally it would be great if the browser submitted the name of it's own domain in the initial NTLM token. But unfortunately it simply does not.
We actually get this question quite a bit. The best way to handle this in our opinion is to create a custom Filter that creates multiple instances of the HttpSecurityService - one for each domain. Then you have a parallel list of network masks that can be used to match clients by remote IP address to the correct instance of the HttpSecurityService. Or you could identify clients using any method you want such as broswer signature. Or you could use a cookie to identify the ideal domain but in this case the user would have to do something to get the cookie (like login manually once). Do you understand what I mean?
Note that if the AD domains have trusts, SSO should work fine with only the one HttpSecurityService instance. The solution described above is only necessary if the domains do not have trust relationships."