Are you looking at Cloud options and wondering how and if you can get there from where you are? If you have Domino on premises and are considering Cloud then a good option is a hybrid architecture which maintains all your on premises configuration managed by your own administrators but adds Cloud client access managed by IBM. We will look at how simple it is to create this hybrid solution using Domino passthru servers and review how things like user and directory maintenance, client access and mail routing will then work. From Domino Admin to Domino Hybrid Admin in a few simple steps.
Boost Fertility New Invention Ups Success Rates.pdf
Setting Up a Hybrid Domino Environment to Ease your Way to the Cloud
1. Gabriella Davis - gabriella@turtlepartnership.com
IBM Lifetime Champion for Social Business
TheTurtle Partnership
1
SETTING UP A HYBRID DOMINO
ENVIRONMENT TO EASE YOUR
WAY TO THE CLOUD
3. THE GOAL
All users continue working together regardless of whether they are assigned to on premises or
cloud servers
Applications hosted on on premises servers can be accessed by any user
Administration continues to be handled by corporate Domino administrators
All users have access to Notes,Verse,Traveler, Connections, Sametime
3
5. HYBRID SERVER ROLES
Directory Server - synchronises directories into the cloud
Directories can be used to provision users or purely for lookups
Mail Hub server - all mail inbound for cloud users and mail between cloud and on premises users
is routed through the Mail Hub(s)
Passthru server - in an isolated domain. The Cloud servers connect to the Passthru server to
reach the Directory and Mail Hub
The passthru server(s) are often in the DMZ
5
6. 6
ON PREMISES TURTLE
DOMAIN
Mail Server1
Mail Server2
Mail Hub
Directory Server
CLOUD DOMAIN
Smartcloud Server1
Smartcloud Server2
ON PREMISES PASSTHRU
DOMAIN
Passthru Server
Assigned servers in IBM Cloud
These are managed for you
Mail Hub Server:All mail between on premises and cloud users route
through this server
Directory Server: Synchronising directories (and populating users) in the
cloud
Smartcloud servers connect to the Mail
Hub and Directory Servers via the
Passthru
7. ON PREMISES OPEN PORTS
Inbound
NRPC 1352 for service users to access on premises server applications
SMTP (25) if you have configured Smartcloud to route all outbound mail via on premises servers
Outbound
NRPC 1352 for Notes client to access Cloud servers
HTTPS 443 forTraveler, Connections
Instant Messaging 1533
7
8. PLANNING
How many Passthru, Directory and Mail Hub servers will you have
Servers are connected to from the Cloud, they do not connect to the Cloud
They are connected to in a failover, not load balanced, configuration
How will outbound mail route
By default IBM routes outbound mail sent by service users out through its own servers
You can configure your IBM Cloud account to sent outbound mail via your Mail Hub instead
Which users will be in the cloud vs on premises
8
9. DIRECTORY SYNCHRONISATION
What directories replicate to Smartcloud
Directories containing Smartcloud users must be replicated
Directories containing on premises users must be replicated if smart cloud users are going to schedule
meetings / work seamlessly with them
LDAP directories cannot be used in Smartcloud environments
Group and Policy names must be unique if you have multiple directories (that’s true regardless of
Smartcloud)
Multiple servers must use identical file names / paths for directories
9
10. MAIL ROUTING
Internal Users route internally via on premises servers
Smartcloud to On Premises routes via Passthru server(s) to Mail Hub
Smartcloud to extended directory users routes via Passthru to Mail Hub
On premises to Internet routes out via SMTP on internal network routing
Smartcloud to Internet routes directly out via IBM’s cloud servers by default
Customer SMTP routing is an optional alternative
10
11. DOMAINS
The passthru server should be in its own domain
A domain is separate from an organisational certifier
Servers can be in different domains but have the same certifier
Having a server in its own domain minimises the risk of exposing internal configuration details and
provides a layer of “opt in” security
11
12. CREATING AN OU CERTIFIER
The Cloud servers will be created by the IBM Smartcloud service and named automatically
They will use an OU certifier you create that must be separate from any other use in your
organisation
Must be a child of your organisational certifier
The server certifier used for the Smartcloud server must be a downstream OU, not a different O
The server ID can have a password but only one
The OU name must be at least 3 characters long
12
13. UNIQUENESS
Your Organisational certifier will be verified for uniqueness within the cloud service
Your top level certifier name must be unique within Smartcloud..
If there’s another “Turtle” out there then I have to use a different certifier for my cloud and
passthru servers.
13
14. BEFORE STARTING
Build your Passthru server(s) in its own domain
Build your mail hub and directory server(s) within your existing internal domain
Replicate the directories you want to use in the cloud to the directory server(s)
Create the OU certifier to be used by the cloud servers
Ensure the correct domain is defined in the Directory Profile (Actions - Edit Directory Profile)
14
17. 17
This is our starting point.We
have configured nothing.
We can keep coming back to this point
to check what needs to be done
next
18. 18
Flores/Turtle
We can add multiple
Domino directories to use
They don’t need to be configured
as directories on the Directory
sync server Each directory can have a
failover server but this doesn’t use
Domino clustering to failover
32. PROVISIONING USERS
Automatically from a directory
The Smartcloud servers connect to your Directory Servers to replicate the directory(ies)
You can configure multiple directories to be populated into Smartcloud
specifying “do not provision from this directory’ prevents the Smartcloud server creating user
accounts from person documents
32
33. USER PROVISIONING
Registered in a Directory synchronisation server
Creates a temporary mail file
User appears in the provisioning view once synchronisation is complete
33
34. 34
Users who are synchronised
and ready to be provisioned
All users
41. REPLICATION OF DIRECTORY
Pull
Person documents not including mail server and mail file name
Policies (not including organisational policies)
Groups
Rooms and Resources
Push
Mail file, server and SaasIdentityID fields in person documents (the last representing the Connections cloud account
Specific server groups used by Smartcloud
IDVault information for the Smartcloud vault
41
42. DUPLICATE NAMES
Domino directory takes priority of Extended Catalog
First person entry is the one used
Public key checking won’t work
42
43. RESERVED GROUPS AND ALL ENTRIES
Directory Synchronisation servers - Manager access including delete rights
Server Group “LLNServers” - Editor rights with roles [UserModifier] [GroupCreator] [GroupModifier]
LLNMailHubs is reserved for Smartcloud
Certifiers_ or SAAS are group prefixes used by Smartcloud
Server Group “SaaSLocalDomainServers” - Manager with delete rights
Wildcard naming in group names aren’t supported e.g */Turtle
43
44. POLICIES
On premise Domino administrators can use policies to manage both on premise and cloud users
Policies in a synchronised directory are applied to cloud users
Only explicit policies are recognised, organisational ones are ignored
Policy names should be unique across all directories
44
51. SUPPORTED LOGINS
Notes ID - Notes client access
Cloud Service Account - iNotes,Verse, Traveler, Sametime
Federated SAML Login - iNotes,Verse, Traveler for Android only
Application Passwords -Traveler, Sametime
51
52. USER LOGINS
IDVault
Syncing ID passwords when service passwords are changed
Password settings can be controlled by a security policy that applies to Cloud assigned users
52
54. FEDERATED LOGINS
SmartCloud Notes support SAML Federation
You must configure SAML in your on premises environment first then contact customer services to
provide them the information for the Smartcloud servers
If SAML is enabled then service login passwords are no longer used and application passwords must be
used instead
54
55. APPLICATION PASSWORDS
Application Passwords vs Service Passwords
Application passwords are 16 characters long and generated automatically on user request
they are shown to the user once
users can generate new ones or disable the existing one
Restricting access to the service for an ip range will most likely preventTraveler or mobile applications
from working and requires an application password
55