When you are using a cloud service, whether it be Office 365, Facebook, LinkedIn or Gmail you are using a user account, and these are also referred to as ‘identities’. Typically there are three types of identities in a cloud service: Cloud Identities, Synced Identities and Federated Identities.
- Cloud Identity – a Cloud Identity is a user account that’s created and managed in the cloud service. In case of Office 365 this account is created and managed in the Microsoft Online Portal. Important to note is that when you access an Office 365 service, authentication takes place against the Windows Azure Active Directory Domain Controllers.
In the Microsoft Online Portal these accounts are easily identifiable as Cloud Identities as can be seen in the following figure:
- Synced Identity – a Synced Identity is created and managed in your local Active Directory and synchronized with the Cloud service. In Office 365 you can opt to synchronize the passwords as well, although not the actual password is synchronized but a hash of the password. Like Cloud Identities authentication takes place against the Windows Azure Active Directory Domain Controllers. These accounts are identified in the Microsoft Online Portal as ‘Synced with Active Directory’ as shown in the following figure:
Although the username and password are identical in Office 365 and in the local Active Directory, this is not a Single Sign-On solution, but I always refer to this as a ‘Same Set of Credentials’ solution.
- Federated Identity – a Federated Identity is a user account that’s created and managed in your local Active Directory and that’s synchronized with Office 365. When the account is synchronized an account in Office 365 (Windows Azure Active Directory) is created. When a service in Office 365 is accessed, the user is not authenticated against the Windows Azure Active Directory Domain Controllers, but the authentication request is redirected to your local Active Directory and Domain Controllers. To achieve this an Active Directory Federation Service (ADFS) needs to be in place. Since there’s only one set of credentials (all authentication takes place against your local Domain Controllers!) this is referred to as ‘Single Sign-On’.
Continue reading Cloud identities, Linked Identities and Federated Identities
On March 17 Microsoft released the 8th Cumulative Update for Exchange Server 2013, 98 days after the release of CU7 which is nicely in line with the quarterly release cadence of Cumulative Updates. This Cumulative Update is called CU8, not a word about Service Pack 2, so SP1 still continues to be the officially supported Service Pack.
There are some new features in CU8 that are worth noticing.
- With CU8 there are improvements for mobile clients in a Hybrid Configuration. When a Mailbox is moved the Outlook client will automatically detect and reconfigure accordingly. This was not the case with Mobile clients. This behavior has changed in CU8. When a mobile client connects the local Exchange server and the Mailbox is moved to Exchange Online an additional check for the TargetOWAUrl on the Organization Relationship object is performed. This will return an HTTP/451 redirect to the mobile client which in turn will be redirected to this new URL. This feature will be available to all EAS compatible devices that can handle the HTTP/451 redirect option. Unfortunately this feature is only available for onboarding customers (i.e. to Office 365) and not for offboarding (from Office 365) customers.
- There an improved migration for Public Folders migration, now supporting batch migrations. This is faster (supports multiple jobs), more reliable and provides an easier migration management.
- CU8 supports viewing calendar and contact types of modern Public Folders in OWA
Continue reading Install Exchange 2013 Cumulative Update 8
Kemp recently released a free version of their virtual LoadMaster (VLM) load balancer solution. It is just like a regular VLM with some restrictions of course. There’s no High Availability support in the free LoadMaster, there’s only web-based support and you cannot update the firmware to a newer version for example. Also the bandwidth is limited to 20Mbit (L7) throughput with 50 transactions (TPS) 2K SSL keys.
However, it does support the nice features such as Global Server load balancing, the Application Firewall Pack and the Edge Security Pack. This makes it a perfect solution for small organizations, for lab environment or for regular test environments. It is possible though to upgrade the free LoadMaster to a regular device, making it also a perfect solution for a Proof-of-Concept. When finished the POC you an easily bring the LoadMaster to production by upgrading the license.
Continue reading Free Kemp LoadMaster
Some customers have an Active Directory domain in their DMZ (for management purposes) and the Exchange 2013 Edge Transport server can be a member of this domain as well.
Unfortunately starting with Exchange 2013 CU5 the Edge Transport server won’t install anymore when the server is a member of such a domain. Setup crashes with the following error message:
“Active Directory failed on localhost. This error is not retriable. Additional information: the parameter is incorrect.” And “Active Directory response: 00000057: LdapErr: DSID-0C090D8A, comment: Error in attribute conversion operation, data 0, v2580 —> System.DirectoryServices.Protocols.DirectoryOperationException: The requested attribute does not exist.”
At this moment (up to Exchange 2013 CU7) there’s no other workaround that to remove the Edge Transport server from the domain, install the Edge Transport server role (make sure you got the FQDN of the server correct!) and after installing rejoin the Active Directory domain. This works fine.
I noticed however that upgrading an Exchange 2013 CU6 Edge Transport server that’s domain joined to CU7 doesn’t hit this issue, there was no need to remove it from the domain before upgrading.
When creating user accounts and Mailboxes in Office 365 the default Microsoft password policy is applied, which means you have to change your password every 90 days.
While it is a best practice to change your password on a regular basis not every customer is too happy with this. I can think of one exception and that’s a service account, this makes sense to have the password set to never expire.
To change this option for user accounts in Office 365 you have to use the Windows Azure Active Directory PowerShell module to connect to Office 365 using the following commands:
$msolcred = get-credential
connect-msolservice -credential $msolcred
Continue reading Password never expire in Office 365