I have changed the authentication type for my domain (in google and office) from managed to federated authentication, in order to enable single sign on with third party.
I want to create new users in (office/google) with normal authentication. Is it possible?
No, change to Managed mode, add users and then change back to Federated.
The reason why MSFT doesn't allow this because,
If we enable Federated mode, that mean the users are living in on-prem (at your company security domain).
If we enable Managed mode, that mean the users are living in AzureAD domain.
So that's the reason, MSFT doesn't allow user creation when in Federated mode.
Cmdlets goes like this:
$dom = "example.com"
Set-MsolDomainAuthentication –DomainName $domain -FederationBrandName $dom -Authentication Managed
<Add Users>
Set-MsolDomainAuthentication –DomainName $domain -FederationBrandName $dom -Authentication Federated
Related
We have a federation between with our ADFS and the other company Azure AD using the "Claim Provider Trusts". We use the Azure AD to perform the authentication, but our ADFS/AD is sending some claims to our "Relying Party Trusts".
The problem I'm facing is if a user is disabled/expired in our local AD, it is still possible to authenticate and access the applications, because the user is not disabled/expired in the Azure AD. I can't manage the Azure AD and it is a valid situation where the user is disabled/expired in our AD, but still working on the Azure AD.
How can I figure this out to prevent disabled/expired user from my local AD to access my apps?
Thanks!
In Azure AD you need to go to the user's profile and block the user's sign in under the user's profile > Edit > Settings
You do need to have at least the User Administrator role in Azure, so if you don't have access to the Azure AD you will need to ask an admin to do this.
You can also use Graph API to set accountEnabled to false.
PATCH https://graph.windows.net/myorganization/users/{user_id}?api-version
Body:
{
"accountEnabled": false
}
Otherwise you can delete the user in Azure or ask the admin to do that.
For federation, the user should either be in your AD or in the other parties AAD.
(If you use AAD Connect, the user status is synched up to a shadow account).
Otherwise, you end up with this problem.
Is there a reason you have them in both?
Is there a way to match the AAD and the AD user?
If so, you can have a claims rule to get the status of the matching AD user and then deny access if disabled.
Update
You should read up on AAD Connect. It has filters e.g. groups so you can control who is synched up. Once that's working, if they are disabled in AD, then they will be disabled in AAD as well.
You should also look at the application report as it shows apps that can easily be moved to AAD and provides scripts to do so. There's a number of tools.
You could use the claims rules to find the enabled status of the user and then set a claim if disabled and then use the Access Contol Policies tab to deny access if this claim exists.
There have been a few changes in our environment recently. No when going to the Office 365 login page, when we click to sigh in it redirects us to GoDaddy SSO home page and then will not accept the ADFS credentials to log in. We use GoDaddy for external DNS
The recent changes have been:
Autodiscover pointing to outlook.office365.com instead of on premises
ADFS proxy changed to use WAP servers instead of using the Netscaler for proxy
Azure MFA enabled o ADFS
POP and IMAP disabled for all user mailboxes.
We simply want to be able to sign into the office 365 portal like everyone else does.
Any assistance would be great.
Thanks
This is not a DNS problems. It has more to do with Federation. When you try to logon to the Office 365 portal it would require you to provide your username and password and any MFA prompt if already setup. The O365 system will check the UPN suffix of your username and redirect you to https://login.microsoftonline.com/common endpoint which will further try to find out about your domain. It will check whether the domain's authentication is managed or federated. In case of managed it means the system is federated with Microsoft federation system and the authentication is managed in the cloud. If it is federated , it can be federate to your own federation service like on-premise ADFS or OKTA , auth0 etc. or it can be federated with any O365 syndicate Network (O365 through godaddy , dell etc.) .
In your case if you are getting redirected to Godaddy SSO then it seems you are using the Office 365 mail plans by godaddy. It is not possible to federate to this system and you will have to buy a license directly from Microsoft and migrate your federation setup completely to Microsoft Office 365 in order to get that kind of control because godaddy does not allow you to go to Office 365 management portal and they provide their own O365 management portal which does not allow multiple management operations.
If you want to federate it with your on-premise ADFS you would need to move the users and the email domain to a new Microsoft O365 tenant. And you can then federate your domain with your ADFS environment. You will need to buy Office 365 directly through Microsoft or via any CSP and in this case it will provide you complete control on the O365 tenant instance unlike godaddy. Godaddy Office365 offering was not designed keeping the on-premise federation in mind. It was mainly designed for small businesses who just required email-on-the-go along with a domain name with some features of Office365. I am not an expert of the same but this is what I understand of it with the experience I have had in the past going through a few of these scenarios.
You need to create a new tenant and buy same office 365 licenses directly from Microsoft. You would need to create all your users in your new tenant . Have the users to export their Mailboxes and create PST files. You can use third party O365 migration tools or do it manually . This method will require some downtime but with careful planning you can minimize it .
Use this Office 365 article to export PST of user mailboxes .
When you buy Office365 through godaddy, the Godaddy system creates a tenant which is named something as NETORGxxxxx.onmicrosoft.com where xxxxxx denotes an alphanumeric serial number. And your email domain which you bought with godaddy will be associated with this tenant . You will need to move this domain to another new tenant in order to use it with your on-prem ADFS . You can call godaddy support to dissociate your domain from the godaddy tenant and they can do it for you . But if you want to do it yourself without calling them you can follow the following steps. In this case you will need to find the admin user for your godaddy tenant. In order to do that please follow the steps below.
Have the user who set godaddy Office365 system first time , logon to the Azure portal . https://portal.azure.com .
Once you logon to the Azure portal you must be able to find the Azure active directory blade .
Click on the same and open Azure Active directory >> Users >>
Try to find the admin user here the account should look something like admin#NETORGxxxxxx.onmicrosoft.com .
Please reset the password for this account admin#NETORGxxxxxx.onmicrosoft.com .
This is the account which we will use to convert our godaddy email domain for managed authentication from Godaddy SSO .
Alternatively you can promote another account to global Admin role but I have not tested it in the past whether that will work or not .
Now please install the Powershell Module MSonline on your system . Or AzureAD powershell module. Please see linked article for the same. Also the PowerShell cmdlets sometimes can take longer depending upon number of users in your tenants and other factors so give it enough time.
After this logon to the Office 365 instance by following cmdlets.
Connect-Msolservice
Connect-ExchangeOnline
Now you require to enable Organization customization .
Enable-OrganizationCustomization
After this use the admin user account for which you reset the password and run the below cmdlet for that user.
New-ManagementRoleAssignment -Role "ApplicationImpersonation" -User "admin#NETORGxxxxxx.onmicrosoft.com"
you can now check the domain name which we want to change authentication method for .
Get-MsolDomain
The above command will list all the domains associated with your tenant . In case of godaddy it should be one which will appear as federated.
Now we will run the following command to remove the federation.
Set-MsolDomainAuthentication -DomainName "<your org domain name>" -Authentication Managed
To check whether it has been completed , you can run Get-MsolDomain again and check the status of domain. It should be managed.
Now you can remove the domain from here and take it to another tenant without a problem.
Once this is done. By this time you must already have your users created on the new domain and you may need to import the mailboxes of the users to your new tenant. You can use this one for importing the PST files to users mailboxes.
Once done you can federate the Office 365 domain from your on-premise ADFS server as you had done before and it would work without an issue. I understand it is not a simple process but Godady Office 365 Offering does not allow federation with any other system than godaddy SSO . So if you would like to change it to your on-premise ADFS system you may need to move to a new tenant completely . It is a cumbersome process but many small businesses who are on a growth path like to have more control do migrate out of godaddy as their business grows and needs change.
I am trying to do SSO using Azure AD. I have setup my application on azure AD but on domains tab under my domain name, in field Single Sign on i get value as Not Available. How can I make it available ?
You need to prepare your AAD for SSOor for o365 apps. Check this KB on how to prepare, setup and troubleshoot AAD SSO issues: https://support.microsoft.com/en-us/kb/2530569
Hope this helps.
Yes. Generally we need to setup SSO for a domain to see the status for "Single Sign-On).
See my page. For me it shows "Configured" (Because I have ADFS SSO setup) and Not planned (for Managed Domains).
For onmicrosoft.com domains, it will show "Not Available" and it is by Design logically since onmicrosoft.com is provided to you by Microsoft and we cannot do any type of SSO with that domain.
I'm customizing an ACS home realm discovery page and want to accommodate users who have either a "microsoft account" (aka LiveID/Passport) or a Office365/Azure Active Directory account.
In this situation, it's possible for the following workflow to happen (as far as I understand it)
User logs in using ACS custom page
User selects "Microsoft Account"
User types in their company / corporate ID
The HRD process at http://portal.microsoftonline.com redirects them to their ADFS server
Their ADFS server redirects them to their company.
Once sign-in passes (or fails) the login would cascade back to the ACS page.
What is the most efficient way (for the end user) to integrate Azure ACS, with Azure Active Directory / Office 365, with a custom HRD page that I create?
Or more plainly, is there a JSON web service that I can query to determine if a given domain or account exists within the "Microsoft Account/LiveID" world, and also check AzureAD for the same thing.
You cannot treat "microsoft accounts" (Windows Live ID / Outlook.com / hotmail / xbox /etc) the same as WAAD accounts when using ACS. When you set up your identity providers in ACS you will need to enable a Windows Live IDP and one IDP for each WAAD instance you are going to allow users to authenticate with. One thing that is not clear to me from your question is if you are needing for you users to be able to authenticate against a single WAAD tenant or from multiple. If one then you only need to configure one WAAD tenant in ACS. If you need to allow users to authenticate against multiple WAAD tenants then you will need to set up and IDP for each in ACS. For example if your web app is a SAAS application with users from companies "Contoso" and "Northwind" and you want them to be able to authenticate against their company's on-premise active directory then you will need two WAAD tenants setup. Each WAAD tenant will need to have federation configured with their given on-premise active directory. Each WAAD tenant in turn would need to be configured in ACS as an IDP. You could name those IDPs distinctly in ACS something like "Contoso WAAD" and "Northwind WAAD". Then in your custom implementation of the HRD page you can either just list all the IDPs and let the user choose, or if you want to be fancier you could parse the JSON results from the ACS endpoint that lists IDP and present them to the user (or just redirect them) based on some other selection they had made.
I'm sorry if this is a stupid question. I've read many articles about ADFS setup and what-not, but what I'm failing to understand (since this is not my primary area of work or interest) is if its actually capable of handling what I need handled.
That is: I have a Sharepoint server on domain "domainA". Now, I've been told that using ADFS, I can "delegate" permissions to other external AD's. The way I'm understanding it is, that I can say this other company using "domainB" is allowed to login to my sharepoint server? Is this at all correct? So users of both "domainA" and "domainB" is allowed to login, and I can set sharepoint permissions with users of both AD's?
ADFS is an instance of a Security Token System (STS).
SP 2010 has its own STS which can be federated with an instance of ADFS in Domain A which allows users to authenticate via the Domain A AD. These users are configured to receive a set of claims from the Domain A AD which SP 2010 uses as permissions (i.e. authorisation).
If you have another domain - Domain B - the normal practice is to install another instance of ADFS on that domain and then federate the two ADFS. These users will also receive a set of claims.
Now users in Domain A authenticate on the Domain A AD and users in Domain B authenticate on the Domain B AD and both have access to the SP2010 application.
To decide where to authenticate, the user will be presented with a Home Realm Discovery screen which will ask them where they want to authenticate. This is out-of-the-box behaviour.
For anything ADFS related, look here.