Im kinda new to Windows server, but have been checking out Microsoft Azure and like the IaaS.
Just a question about SSO verse Azure Active Directory Sync.
Im moving my infrastructure into Azure, my base is a AD server, "dirsync" or AD FS server and a few web servers etc. We use Google Apps for Email, Calendar and Drive.
So I see that there are two ways to keep my AD directory and Azure directory in sync. SSO and Azure Active Directory Sync.
If I use Azure Active Directory Sync and not setup AD FS on a server with SSO, will I still be able to use SSO with my Azure Directory to Apps the Microsoft have in the Azure portal?
The only reason I would need a AD FS server if I had Apps/Services on site that I wanted to use SSO with, correct?
I plan to run, kayako and CrashPlan in two VM's in Azure. Both will use LDAP/AD for usernames/password authentication. But would be cool to get SSO for both webapps so employees can sing-on via the myapps.microsoft.com portal.
The two ways are DirSync and AAD Sync. Refer: Synchronization Previews Now Available for Microsoft Azure Active Directory.
Sync = Same Sign On between on-premise and cloud
Sync + ADFS = Single Sign On between on-premise and cloud
Update
myapps.microsoft.com is for third-party vendors like SalesForce who have asked Microsoft to add them as a SaaS application to AAD. It's not for company specific apps.
For company specific apps., you need ADFS as above.
Having done that, if your user SSO's into your app. and then wants to use e.g. SalesForce, they won't have to login again.
Related
I have an Azure DevOps server on-premises and I have written a small application that simply queries its API to get information from the Azure server. There is no authentication at the user level, since the application only displays information and does not POST/PUT/DELETE.
To query the API, I have used my PAT (personal access token), but this is not ideal. I have read that on the cloud version of Azure, you can just register the application to do it, but I have not found the same functionality for the on-premises version.
Am I missing something? Is the only alternative creating a technical user on the LDAP and get a PAT for it?
Is the only alternative creating a technical user on the LDAP and get
a PAT for it?
Yes, you are right.
Authorize access to REST APIs with OAuth 2.0
So 'App auth' is only supported in Azure DevOps Services (VSTS), not supported in Azure DevOps server (TFS).
I need to test the pass through authentication connection of a new website using PowerShell.
The code that I have just creates the website.
New-WebApplication -Name DLTItemAnalysis -Site 'Default Web Site' -PhysicalPath C:\inetpub\wwwroot\ApplicationFolder\ApplicationFolder -ApplicationPool ApplicationPool
Set-WebConfiguration "/system.applicationHost/sites/site[#name='Default Web Site' and #id='1']/application[#path='/Application']/VirtualDirectory[#path='/']" -Value #{userName=$ServUserName ;password= $ServUserPassword}
Is there a way to also test the user connection like the GUI has?
I am not really sure what you are asking for here. for as documented:
It is an authentication bridge and a new powerful way of cloud authentication while still keeping your passwords on-premise. It securely validates user passwords with on-premise Active Directory without the need of extra on-premise infrastructure like ADFS. Azure Active Directory (Azure AD) Pass-through Authentication allows your users to sign in to both on-premises and cloud-based applications using the same passwords. This feature provides your users with a better experience - one less password to remember and reduces IT helpdesk costs because your users are less likely to forget how to sign in. When users sign in using Azure AD, this feature validates users' passwords directly against your on-premises Active Directory.
When a user types in his user name and password on office 365 portal https://portal.office.com, office 365 service encrypt this using public key and puts it in a queue for validation, one of lightweight agent makes an outbound call from your network to retrieve the user name and password and decrypts the password using organization’s private key and validate it against local AD. Local AD sends back the resulting success or failure and it goes back to Azure portal via an agent and the user is authenticated.
So, this is nothing more than a standard Windows Kerberos auth request being redirected. So, you are only require testing for normal Windows auth.
As noted above, PTA is a communications channel, not an auth type, like basic, integrated, Kerberos, Kerberos(required), etc. For a target to validate a specific auth type, the target has to be configured for it. There is not PTA auth type as noted above that you can configure on a target.
Microsoft's PTA Video
User sign-in with Azure Active Directory Pass-through Authentication
What is Azure Active Directory Pass-through Authentication? Azure
Active Directory (Azure AD) Pass-through Authentication allows your
users to sign in to both on-premises and cloud-based applications
using the same passwords. This feature provides your users a better
experience - one less password to remember, and reduces IT helpdesk
costs because your users are less likely to forget how to sign in.
When users sign in using Azure AD, this feature validates users'
passwords directly against your on-premises Active Directory
looking at "Authorize access to REST APIs with OAuth 2.0" at https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops
An Azure DevOps organization is connected to an Azure Active Directory tenant
-> let's call it 'devops-ad-tenant'.
A user has an Active Directory Home Tenant
-> let's call it 'user-ad-home-tenant'.
A user can be a guest user withing another Active Directory Tenant
-> let's call it 'user-ad-guest-tenant'.
If the 'devops-ad-tenant' is equal to the 'user-ad-home-tenant', everything works out fine.
If the 'devops-ad-tenant' is equal to the 'user-ad-guest-tenant', the OAuth flow succeeds, but the flow happens within the context of the 'user-ad-home-tenant' and this user is from a Azure DevOps perspective not the user from 'user-ad-guest-tenant'.
I am having trouble to use something like a "domain_hint" when initiating the OAuth flow.
Any thoughts?
This behavior of get the token is used for the home directory is by design since the customer may be as guest for multiple Azure Active Directories. And as the document you shared for the Azure DevOps OAuth authentication, currently there is no such option to choose which directory for the usage of token acquired.
If you want Azure DevOps support this feature, you can submit the feedback from Develop Community - Azure DevOps.
I managed to get along with a work around...
My application uses an Azure AD multi-tenant appRegistration for authentication.
When the user logs in at my application, the OAuth flow for Azure DevOps is started.
To set the Azure AD tenant for the OAuth flow for the Azure DevOps organization
use a clean browser session, no cookies etc.
log into https://aex.dev.azure.com and select the Azure AD tenant 'user-ad-guest-tenant' for Azure DevOps organization
duplicate that tab
enter the url for my application
the OAuth flow happens within the context of 'user-ad-guest-tenant'
this is really inconvenient... but a work around... besides I am still investigating why this is working...
After implementing the integration of Azure Active Directory and some other could applications like Salesforce, and syncing On-Premise Active Directory data by using Azure AD Connect, now I could auto login Salesforce and other cloud apps with Single Sign-On by using the credentials I used for desktop logon, but I still need to key in the credentials once when accessing Azure Applications page (Azure Portal).
Is there any configuration in Azure I can change to support auto-login by using the Windows credentials, so that once I log into my encrypted machine, I could auto login the Azure Applications page (the Azure portal) without key in password again? If Azure does not support no sign-on, what's the best way to do some development to support no sign-on?
Any post or suggestion will be appreciated!
You can always try to authorize users using Graph API. Maybe this will be helpfully: https://github.com/devkimchi/Graph-API-App-Only-Web-API-Sample
I had a similar issue when using ADFS for federated identity and the following article helped, not sure if it applies to Azure AD Connect but it might give you some useful info.
https://support.microsoft.com/en-us/kb/2535227
Thanks thedev and dawidr for your reply.
Finally I found a solution which might achieve the No Sign-On. AAD supports federation authentication, so just try to integrate the ADFS and AAD by using Azure AD Connect to implement the federation identify with On-Premise AD, then no more password key-in when accessing the Azure Applications. I don't have a proxy server with public IP so it's just a solution in my mind without verification.
I would like to find out what the best practices are for managing developers' access to a sub-set of resources on a client's subscription?
I've searched Google and the Azure documentation looking for definitive answers, but I have yet to come across an article that puts it all together. Because Azure is still developing so rapidly I often find it difficult to determine whether a particular article may still be relevant.
To sum up our situation:
I've been tasked with researching and implementing the Azure infrastructure for a web site our company is developing for a client. At the moment our manager and I have access to the client's entire subscription on the Azure Portal by means of the Service Administrator's credentials, even though we're managing only:
Azure Cloud Service running a Web-Role (2-instances with Production and Staging environments).
Azure SQL Database.
Azure Blob Storage for deployments, diagnostics etc.
We're now moving into a phase where more of the developers in the team will require access to perform maintenance type tasks such as performing a VIP swap, retrieving diagnostic info etc.
What is the proper way to manage developer's access on such a project?
The approach I've taken was to implement Role Based Access Control (https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/)
Move 1, 2, and 3 above into a new Resource Group according to http://blog.kloud.com.au/2015/03/24/moving-resources-between-azure-resource-groups/
Creating a new User Group for our company, say "GroupXYZ".
Adding the "GroupXYZ" to the Contributor role.
Adding the particular developer's company accounts to "GroupXYZ"
Motivation for taking the role-based approach
From what I understand giving everyone access as a Co-Administrator would mean that they have full access to every subscription in the portal.
Account-based authentication is preferable to certificate-based authentication due to the complexity added by managing the certificates.
What caused me to question my approach was the fact that I could not perform a VIP swap against the Cloud Service using PowerShell; I received an error message stating that a certificate could not be found.
Do such role-based accounts only have access to Azure by means of the Resource Manager Commandlets?
I had to switch PowerShell to the Azure Service Manager (ASM) Mode before having access to the Move-AzureDeployment commandlet.
Something else I'm not sure of is whether or not Visual Studio will have access to those resources (in the Resource Group) when using Role Based Access Control.
When you apply RBAC to Azure as you have or just in general, give access to an account via RBAC, then those accounts can only access Azure via the Azure Resource Manager APIs, whether that's PowerShell, REST or VS.
VS 2015 can access Azure resources via RBAC when using the 2.7 SDK. VS 2013 will have support for it soon.