enrollment sAMAccountName move O365

[Martijn Loenhout van]

We have a customer that has enrolled to Secure Hub with the SAMAccountname.

Now the mailboxes need to move to Office365.

Does this require a re-enrollment to Secure Hub, or can we create an extra 'exchange device policy' for the migrated users ?

(by extra 'exchange device policy' we mean a modified policy that passes the UPN to Office365 in stead of the samaccountname)

[David Egan1709157332]

Hi there,

 

Whilst Secure Hub is enrolled on XenMobile Server by using sAMAccountName, this does not necessarily mean that Secure Mail is also using sAMAccountName.

The authentication of Secure Mail can be handled separately and independently of the authentication used by Secure Hub.

Likewise, the same advice applies for when you are configuring an Exchange Account Policy (in other words, you can have this Exchange Account Policy use yet another authentication method, if required).

As such, there should be no need for Secure Hub to be re-enrolled because of the mailboxes moving.

Rather, it is only those policies (either the MDX Policies for Secure Mail, if used, or alternatively the settings found inside of the Exchange device policy) which would need to be updated.

Neither of these require that Secure Hub no longer uses sAMAccountName and so there should be no need to re-enroll Secure Hub.

This is something that you should test on a few user account to begin with before making any changes that would impact upon a large number of users.

 

Many thanks,
David

[Martijn Loenhout van]

Thanks for your quick response.

 

This realy looks promising, will look into it further.

There was some confusion internally that re-enroll was required anyway.

[John Francis1709160537]

On 2/14/2018 at 8:18 AM, David Egan1709157332 said:

Hi there,

 

Whilst Secure Hub is enrolled on XenMobile Server by using sAMAccountName, this does not necessarily mean that Secure Mail is also using sAMAccountName.

The authentication of Secure Mail can be handled separately and independently of the authentication used by Secure Hub.

Likewise, the same advice applies for when you are configuring an Exchange Account Policy (in other words, you can have this Exchange Account Policy use yet another authentication method, if required).

As such, there should be no need for Secure Hub to be re-enrolled because of the mailboxes moving.

Rather, it is only those policies (either the MDX Policies for Secure Mail, if used, or alternatively the settings found inside of the Exchange device policy) which would need to be updated.

Neither of these require that Secure Hub no longer uses sAMAccountName and so there should be no need to re-enroll Secure Hub.

This is something that you should test on a few user account to begin with before making any changes that would impact upon a large number of users.

 

Many thanks,
David

 

Hi David,

 

Thanks for the info, I was looking for the same information. We have our LDAP as SAMAccountName and we want to test few users with UPN. How would we be able to achieve this? Can we use some form of policies to test for few users to login to SecureHub with UPN name and also SecureMail. Currently, we are using SAMAccountName. 

 

Is this only possible by globally changing it to UPN in LDAP settings?

[David Egan1709157332]

For a single domain name, the setting for sAMAccountName or UPN is a global setting. Although it is possible to configure multiple LDAP connectors (for example, one LDAP connector for sAMAccountName and another LDAP connector for UPN), this method only works for 'different' domain names. In other words, for any given single domain name, the choice of 'sAMAccountName or UPN' is a global setting.

Other than the LDAP connector on XenMobile Server, there is also the NetScaler Gateway configuration (found under 'Settings' on XenMobile Server). Inside here you will find that a single entry exists for a single Gateway. Again, this Gateway vServer will allow for 'only' a choice between sAMAccountName and UPN. It is not possible to configure multiple options here either unfortunately.