I have to implement Single Sign on with following user case:
We have three kinds of users:
1) Corporate employees [Stored in Active directory]
2) Clients can access our application
3) We have hosted separate application for each client and clients employees can access this application [hosted on our server] and number of employees can be have million.
So we cannot store use credentials in active directory because we need per user license to use.
Please help me to find better solutions
ADFS only works with AD. The next version of ADFS will work against LDAP so that's a possibility.
I would look at Azure Active Directory (you could use something like AAD Sync. to migrate your existing AD users) or something like OpenAM or PingFederate (both of which are Java based) which you have to pay for or something like shibboleth (Java based but open source). These all support LDAP.
Or if you want to go the SQL Server route, look at thinktecture's identityserver.
Related
My problem is that we have 2 On-Premises Active Directory domains:
mycompany.com
mycompany-dev.com
Some people are present in both of these AD-s. I want to sync them with Azure Active Directory so that they are all represented once, and all have the #mycompany.com suffix (instead of #mycompany.onmicrosoft.com). I also don't want some users to have #mycompany-dev.com in their azure AD account login name, so I want to do some sort of mapping I guess.
Is this possible with Azure AD Connect, or do I have to implement a synchronization method manually?
You can sync multiple on-premises domain to Azure AD. Kindly check the link and you will get a detailed information about different topologies supported
I'm currently in the process of moving into a properly hybrid on-prem/Azure setup. I have a test group of machines that are registered as hybrid joined, I have my AD connector going to Azure AD for users and systems. And I have write back setup. So - if a user logs into their Office 365 account, they can change their password, and it's immediately reflected for their email and attached SSO services. However, if their machine is off premises, their new password will not work to log them into their system.
This, I know, is because the system is looking for the on-premise domain controller, but I'm at a loss as to where to begin with telling the systems to authenticate against Azure components. I've recently read Moskowitz's book on MDM, Intune, Azure, but I feel like I've missed something in that book that covers this very thing. Any help on this would be helpful, since I feel like I'm missing something really obvious here.
Your machines need to be Azure AD Joined.
More detailed assessment and planning documents are provided at
How to: Plan your Azure AD join implementation
We are using a third-party IT provider that handles our network administration and domain accounts, but as part of moving to a different office and setting up new infrastructure, we are considering dropping that and using Azure Active Directory only.
Researching the topic online seems to indicate that Azure AD is not a complete replacement for on-premises Active Directory, as things like local resource access and group policies outside of Azure would be missing. However, we are moving towards using Azure for most things (file storage, etc), so that should be fine if we still have that functionality there.
Before finalizing the decision to go in that direction, we just need to be certain of a few things:
1) Is there a way to create a new account in Azure AD so that it can be used to login from any machine in the office, without having to create it locally first and then connect the two?
2) Is there a way to sync user data, such as user/desktop files, across any devices the account is used to log into?
3) Is it possible to have an office printer configured in Azure so that it can be used with an Azure AD login, completely independent on any on-premises setup (i.e, not Hybrid Cloud Print, which seems to require an on-premises network/AD to be joined with Azure AD)?
The goal is to be able to log in and work from any internet-connected device, whether in the office or at home, without needing to use a VPN and/or remote desktop, and forego on-premises AD administration.
This is possible as long as the device is joined to Azure AD. Once the device is joined to Azure AD, then newly created cloud-only users can also login to the devices.
Ref: https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-azure-ad-join
Enterprise state roaming should help in this aspect. It might not cover everything you are looking for but the important app-specific data and user settings are synced.
Ref: https://learn.microsoft.com/en-us/azure/active-directory/devices/enterprise-state-roaming-overview
There is no direct solution from Microsoft for pure cloud scenarios. There are few 3rd party services offered for this.
Ref: https://appsource.microsoft.com/en-us/product/azure/printix.64182edf-4951-40d5-91c8-733e1c896b70
Hope this helps.
I found it's possible to sync users/groups from Azure AD to local App though SCIM. But it seems not available in local AD, and seems not available in ADFS.
How I can sync from local AD, or is there any tools I can use?
You would need a SCIM Product which you can create yourself or Purchase from several vendors.
Assuming you wish to take entries out of your local Microsoft Active Directory and "SCIM Them" into something else, you would probably want a SCIM Client and then put them into your SCIM Service Provider.
You would need to use something to get the entries out of Microsoft Active Directory and then use SCIM to put them into ???.
You could also use the Microsoft DirSync Control using LDAP
There are many IDM vendors that create product with this functionality.
What is the difference/relation between ADAM, Active Directory, LDAP, ADFS, Windows Identity, cardspace and which server (Windows 2003, Windows 2008) uses what?
Active Directory is a server component for administrating windows domains and storing related informations like details about users. It provides implementations of the network protocols LDAP, DNS, CIFS and Kerberos. It's part of Windows Server 2003 as well as Windows Server 2008 with some modifications in the latter case.
ADAM was somewhat like the little brother of Active Directory. It only contained an implementation of LDAP. With Windows Server 2008 it was renamed to LDS, Lightweight Directory Services. ADAM/LDS can also be installed on non-server versions of Windows.
LDAP is a protocol for administrating the data of a directory service. Data within a directory services are stored in a hierarchical manner, a tree. Entries within that tree can contain a set of attributes where each has a name and a value. They are mostly used for storing user related informations like usernames, passwords, email addresses and so on, as there are standardized schemas for this purpose and it's widely supported by applications.
ADFS is a technology which enables Single Sign-On for users of web applications within an Identity Federation. In a very short form: Imagine two organizations which have their user data stored within an active directory. Now each organization wants to give the users of the other organization access to its web applications, but with the restriction that the user data itself should neither be copied nor be fully accessible to the other organization. Thats the kind of problem ADFS can solve. May require an hour of reading & researching before fully understood.
Just to fill in the gaps above:
ADFS is an example of a STS (Security Token Service). STS's can be configured to have a trust relationship with each other. Imagine you have a company which only has internal users and they want to expand to external users. That means that all external users have to register, get a user name, password etc. Perhaps the company doesn't want to store all this stuff. They realise that most of their external users already have an OpenId account. So they federate (trust) their ADFS with an STS that accepts OpenId credentials.
When an external user wants to access the company website, they are asked what kind of user they are via a drop down. They select OpenID. They are then taken to the OpenId site where they authenticate. The user is then redirected back to the company ADFS with a signed token which states that OpenId has authenticated the user. Since there is a trust relationship, the ADFS accepts the authentication and allows the user access to the web site.
None of the OpenId credentials are stored by the company.
Effectively, you have outsourced authentication.
ADFS currently runs on Windows Server 2008 R2.
For Windows Identity (in the context of ADFS) I assume you are asking about Windows Identity Foundation (WIF). This is essentially a set of .NET classes that are added to a project using VS that makes the application "claims aware". There is a VS tool called FedUtil that maps an application to a STS and describes the claims that will be provided. (A claim is an attribute e.g. name, DOB etc.) When a user accesses the application, WIF redirects the user to the mapped STS where the user logs in. WIF then provides the application with a set of claims. Based on these, the application can alter flows based on the user claims. E.g. only users with a claim type of Role with a value of Editor can alter pages.
WIF can also act as an Access Manager E.g. only Editors can access this page. Other users simply receive an error.
In WIF, an application is referred to as a "Relying Party" (RP).
WIF inside VS requires Vista or Windows 7.
Since STS's can be federated with each other, each STS can provide a group of claims.
E.g. in the example above, the OpenId STS can provide the user's name while the company ADFS can provide information not pertinent to OpenId e.g role in the company.
Cardspace is a mechanism to authenticate via a digital identity e.g. an enabled application can ask you to login by selecting one of your "cards", one of which might be e.g. your personal X509 certificate. The application would then check this against the credentials it has stored.
In February 2011, Microsoft announced that they would no longer be developing the Windows CardSpace product.