You invested in Office 365 for you users, but you don’t want to annoy them with prompts where they have to put their usernames and passwords in, certainly as you have domain joined devices. For Office 365 ProPlus License Activation utilizing the SSO capabilities, you either had to put in an ADFS infrastructure or.. available […]
When you want to enable MultiFactorAuthentication (MFA) for Azure / Intune / Office 365 / Dynamics 365 and you are using federated logins and want to have the MFA provider to be on-premises (integrated with ADFS/PingFed/other) integrated.. you might run into an issue where the Azure MFA page keeps popping-up and asking you to register […]
When you want to change the user UPN, in certain conditions, this UPN change will not be synchronized to AAD (Office365/Intune/other).. why?
When you have federated domains for Office 365, or rather AAD in general and you want to switch your users from one domain to another, you will notice that that object will replicate anymore to AAD (and thus Office 365). I noticed this a long time ago, and it seems Microsoft now also posted this as a known KB a few weeks ago..
In my previous post, I talked about the possibility of using Kerberos Constraint Delegation to avoid having passwords in AAD. However, sometime you want to have a few passwords in AAD-Domain Services to ensure that administrators can still login to the VM’s interactively (RDP) or users are able to use certain services that are not published with Kerberos or aren’t web services.
In this post we will look at editing the configuration of AAD-Connect to synchronize the passwords* of users that have an attribute in AD present so that some users (like administrators) will be able to login to VM’s joined to AAD-DS using their on-premises passwords.
* see note below
When migrating to Office 365 users must retain access to Outlook Web Access. While the guides for the OWA access are present, users see themselves being challenged for username and password multiple times. This is even worse when most users are located on Exchange 2007 in a mixed environment.
In order to cope with this problem TMG can be setup to only authenticate users once. Even more, users can also be authenticated already when they are sent to the Office365 OWA site and need to request a token from the ADFS server.
As we have seen, passive clients have a different connection scenario than active clients. As passive clients can actually input data, this can be used to configure the request for additional authentication data. When users are accessing Outlook Web Access they are redirected to the federation services to retrieve their token. This is where we can add the additional authentication hop. Users who reside within the internal network are not required to add additional information as their device and location are already in a trusted location. Therefore this authentication path is excempted from the picture below and described later.
Office 365 is booming.. everyday new companies decide to make the switch to easy online messaging and collaboration services on the cloud. While the cloud should make life easier for administrators, setting up the co-existence environment seems a bit harder. Although Microsoft has tons of help material available .This post is to clearify the interaction when settings up a co-existence environment with Office 365.
For this example I have added a TMG server to validate the requests. As many companies have additional firewalls in front of the TMG server, this is also displayed. And the TMG server serves another role to in the advanced setup, where we explain that it is possible to have OWA users use two-factor authentication while ActiveSync users can continue to authenticate against the federation server with their “passive” clients. (see the next post)