ADSync - Process Descriptionx

wheatauditorSoftware and s/w Development

Oct 30, 2013 (3 years and 7 months ago)

144 views


ADS
YNC


A

TOOL FOR REGISTERING

ACTIVE
DIRECTORY USERS WITH

LOTUS DOMINO
AND THE VENTURE INFO
RMATION
CATALOGUE


A

PROCESS
O
VERVIEW AND
T
ECHNICAL
D
ESCRIPTION








Version
1.0

1
8
th

December 2012



Flare Solutions Limited

View House, 9 Meadow View,
Marlow Bottom

Buckinghamshire, England, SL7 3PA


Tel:


+44 1628 482750

Fax:



+44 870 460 2543

E
-
mail:


enquiries@flare
-
solutions.com

Document Control


Document information

Title

ADSync


A Process Description

Project

NCOC Venture Information Catalog
ue

Client

NCOC

Target
Audience

NCOC ICT Administrators
; NCOC ICT Managers

Flare
Administrators

Document Ref.



A
pproval

Prepared by

Chris Armstrong

(Flare)

Reviewed by


Approved by



Version
s and amendments

Version

Date

Author

Reason for
Issue/Summary of Changes

Status

1.0

07/12/2012

CJA

Initial version

Final



























References

Document Title

Identification/Location

Source













ADSync


A Process Description

Table of Contents

Document Control

................................
................................
................................
........................

2

Introduction

................................
................................
................................
................................
.

4

1.

Theory & Work
flow

................................
................................
................................
...............

4

The current situation & the way ahead

................................
................................
...................

4

Features, Restrictions and Future Development

................................
................................
......

5

2.

A Technical Description of the
ADSync Workflow

................................
................................
....

6

Introduction
................................
................................
................................
..........................

6

Security

................................
................................
................................
................................

6

Lotus ADSync Options
................................
................................
................................
............

6

Notes Synchronization Options:
................................
................................
..........................

7

Notes Settings:

................................
................................
................................
..................

8

Field Mappings:

................................
................................
................................
.................

8

Group Mappings

and Container Mappings:

................................
................................
.........

9

Registering Users Workflow

................................
................................
................................
.

10

The ADSyncPostProcess Agent
................................
................................
..........................

10

Synchronising an existing user

................................
................................
..........................

1
3

Enabling / Disabling the Agent

................................
................................
..........................

13

3.

Appendix A: Field Mappings

................................
................................
................................
.

15

AD to Domino Directory:
................................
................................
................................
......

15

Domino Directory to the Café:
................................
................................
..............................

16

Domino Directory to the RDS Person database:
................................
................................
.....

17






Introduction

This document provides
a
description of how the ADSync tool synchronises data between Active
Directory and Lotus Domino, and thence into the Venture Information Catalogue.

It is
split into three
sections, the first is a higher
-
level overview of the
theory, workflows and tools depl
oyed to improve
a fr
equently
-
used procedure; the second part is a more detailed, technical description of how
ADSync and its associated Domino agent works, and the third is an appendix of related material.

1.

Theory &
Workflow

The current situation & the way
ahead

Currently, new users are added to Active Directory, and are made members of the AD Venture
Restricted group, and then they require access to the Venture Information Catalogue. This is a
manual process that requires an administrator to add them to AD
,

then that user needs to be
created in the Lotus Domino environment (a process known as Registration), then created in the
administration database of the VIC (known as the Café), their presence needs to be added to the
Reference Data System (RDS) within th
e VIC, and they should be added to the NCOC Users group
within Domino, so they have appropriate access to the many databases that constitute the VIC.

The ADSync tool, combined with a new agent process within Domino, serves to automate that
process to an ex
tent, and reduce the workload to a series of button clicks. This will reduce the delay
between a user being created in AD and them having access to the VIC, and should also eliminate
errors introduced by human error when creating users in multiple database
s.


ADSync is a tool supplied by IBM as part of the Lotus Domino Administrator software. It requires
installing and configuring on a Windows workstation, and sits between the AD Domain Controller
and the Lotus Domino Server, although it can be installed
on either of those servers if required.

It
provides the ability to register an existing Active Directory user directly with Lotus Domino using the
Microsoft Management Console (MMC) Active Directory Users and Computers snap
-
in.

Features,
Restrictions

and F
uture Development

ADSync’s primary function is to ease the burden on administrators who have to grant access to new
users to the VIC, but it can also be used to synchronise data between users who already exist in both
AD and Domino, and are already valid u
sers of the VIC. Such data would include, but not be limited
to, job title, office location, telephone numbers, department, and company.

It should be noted that it is not a process that can be completely automated. It requires an
administrator to select us
ers from within AD and to click the appropriate button to register or
synchronise them using the MMC Active Directory Users and Computers snap
-
in. It also highlights
the need for the administrators to be completely accurate when creating users in AD, as an
y
mistakes in user’s information will be passed through to Domino and the VIC. This is particularly
important with users who have multi
-
part surnames, such as “Van Der …” or “De La …”.

Currently the procedures have been designed for registering new users
and synchronising existing
users. Future work would involve developing procedures regarding users leaving the Venture
completely, or moving out of the Venture Restricted group to other activities, and simultaneous
creation of users in AD and Domino (curren
tly the user is created first in AD and then, as a separate
action, is registered with Domino).



2.

A Technical Description of the ADSync Workflow


Introduction

ADSync is included with the IBM Lotus Domino Administrator client as an installation option. It i
sn’t
installed by default, but is available as one of the optional program files, so you must select it during
installation
.
Once installed, ADSync consists of one DLL file (nadsync.dll) along with a help file
(adsynch.chm
). Installation registers ADSync
as a Microsoft Management Console (MMC) snap
-
in,
which makes it available in the Active Directory Users and Computers tool.


Security

There is a bi
-
directional aspect to the security associated with ADSync.
Active Directory
administrators need administrat
ive access to the appropriate Domino Directory, and appropriate
Active Directory access.

As part of their normal role as administrators, they would have the
necessary AD access, but to grant appropriate access to the Domino databases, a new Domino
Adminis
trator has been created, called
ADSync Admin/ncoc
. The password for this user will be
supplied in a separate email, along with the location of the user’s Notes ID file. This user has been
added to the
LocalDomainAdmins

and
NCOC Admin

groups in Domino on nc
oasdmov01, and so has
all the necessary ACL rights to access the required databases.

Lotus ADSync Options

The first time the MMC snap
-
in is started in a session, the ADSync tool needs to be initialised. This is
done by doubling
-
clicking on “Domino Director
y Synchronization”, or right
-
clicking on it and
choosing “Options”, or when an attempt is made to register the first AD user in a session. Initialising
ADSync requires the password to the ADSync Admin/ncoc user, and to select the correct Domino
server to c
onnect to, in this case ncoasdmov01. Once ADSync is initialised, the Options can be
examined (right click on “Domino Directory Synchronization” and choose Options):


This opens a dialog box with five tabs:


Notes Synchronization Options:

The default
behaviour is to have “Enable all synchronization operations”

selected
, but this needs
changing as in this situation it is not desirable to set a common password on user synchronization,
as
authentication for the users when they connect to the VIC (i.e. Dom
ino) is done by Single
-
Sign
-
On,
using their Windows user password. Also it is recommended to not tick the Recertify users on
rename option, as renaming of users should remain a task carried out manually until the ADSync
procedures for this task have been f
urther investigated and tested.

Notes Settings:


Here the Domino Administration user is set, the Domino server defined and the certifier is specified
which will be used to certify all new users registered in Domino. Nothing should be changed on this
tab,
except that when ADSync is initialised (when MMC is started for the first time in a session) the
Default Explicit Policy should be changed from {none] to /ADSync User Addition.

Field Mappings:

This tab controls the mapping between AD attributes and Domino

Directory attributes. Many are set
by default,
some are fixed and not visible here, and five other mappings need to be added manually
after ADSync is initialised. See Appendix A for more information about field mappings.


Group Mappings and Container
Mappings:


No changes are made to
the default
options in either of these tabs currently.

Registering Users Workflow

The actual procedure for registering new AD users with Domino is covered in a separate document
(“ADSync


A Work Instruction”) but the ov
erall workflow can be summarised in this diagram:


The ADSync process takes the selected user’s information


First name, last name, email address, AD
user name, and other fields defined by the Field Mappings tab in the Lotus ADSync Options window


and r
egisters a new user with that information in the Domino Directory on the server specified in
the Notes Settings tab of the Options window, using the Domino administration user ADSync
Admin/ncoc.

The ADSyncPostProcess Agent

An unusual but important field i
n
the
Domino
Directory
which is populated from AD is PhotoURL.
The AD user’s first name is put into this field by ADSync, to be used as a trigger when
the

new agent
runs to process the new Domino Directory
document(s)
. It runs once an hour, starting when t
he
server starts. It scans the Domino Directory database for a record with where the PhotoURL field
matches the FirstName field, and identifies that record as having been created by ADSync. It
processes the document’s User Name field into a format that is

required by the VIC for the single
-
sign
-
on to work
:

Before:





After:


It adds the user to the NCOC Users group in the Domino Directory, so the user acquires the right
permissions t
o access appropriate databases:



Next it creates a “profile docum
ent” in the VIC administration database (the “Café”)

for that user:


F
inally it creates a document for the user in the Reference Data System (RDS) which will be used to
control their access to other applications with the VIC, and to add the user’s name to picklists in
dialog b
oxes in the VIC:



The additional information su
ch as telephone numbers, department, job title and company name
would be passed from the Domino Directory to the RDS document by the agent. Finally, to show
that this record has been processed by the agent, the PhotoURL value is changed from the user’s
fi
rst name to the word “ADSynced”. This has the added benefit of allowing a simple search of the
Domino Directory to reveal which users have been created or synced by ADSync.


Synchronising an existing user

If a user already exists in AD and in Domino, and
therefore in the Café and the RDS, their extra
information can be synchronised between AD and Domino by ADSync and once it is in the Domino
Directory, the agent can pass that extra information to the RDS database.

Enabling / Disabling the Agent

This agent
is enabled in the NCOC Café database, under the System
-
> General
-
> Links tab:


These options set the replica ID of the Domino Directory that the agent scans for new or synced
users, and which Domino group(s) new users should be added to. The agent will
run on the server
specified in the “Administration Server” field of the Basics tab on that General Settings page:







3.

Appendix A: Field Mappings

AD to Domino Directory:

If no mappings are set at all between AD and Domino in the Field Mappings tab of the

Lotus ADSync
Options window, then this diagram shows what standard mappings are made that are fixed and
beyond the control of the administrator:


The following table shows the default mappings that are set when ADSync is initialised:

AD Attribute

Domino Directory Attribute

businessCategory

businessCategory

c

OfficeCountry

carLicense

carLicense

departmentNumber

departmentNumber

description

Comment

destinationIndicator

destinationIndicator

employeeNumber

employeeNumber

employeeType

employeeType

facsimileTelephoneNumber

OfficeFAXPhoneNumber

generationQualifier

Suffix

homePhone

PhoneNumber

internationalISDNNumber

internationaliSDNNumber

l

OfficeCity

labeledURI

labeledURI

mail

InternetAddress

manager

Manager

mobile

CellPhoneNumber

pager

PhoneNumber_6

personalTitle

Title

physicalDeliveryOfficeName

OfficeNumber

postalAddress

PostalAddress

postalCode

OfficeZip

preferredDeliveryMethod

preferredDeliveryMethod

preferredLanguage

preferredLanguage

registeredAddress

registeredAddress

roomNumber

roomNumber

secretary

Assistant

seeAlso

seeAlso

st

OfficeState

telephoneNumber

OfficePhoneNumber

telexNumber

telexNumber

title

JobTitle

uid

ShortName

url

WebSite

userCertificate

UserCertificate

x121Address

x121Address

x500uniqueIdentifier

x500uniqueIdentifier



In addition to these, the following bespoke mappings must be
made when ADSync is initialised:


AD field name

Domino Directory Attribute

company

CompanyName

Department

Department

givenName

PhotoURL

sAMAccountName

EmployeeID

street

OfficeStreetAddress


Domino Directory to the Café:

The only mapping is the person’s User name, which is mapped from the first line of the user name
field in the Domino Directory field to

the User name field in the Café user document:



Domino Directory to the RDS Person database:

Currently the User name in Domino is mapped to the Display name in the person’s document in the
RDS:



NB: This behaviour will change imminently so the
Display Name will be in the format “Lastname, First
initial”, for example: “Eledu, C”, and other permutations of the name will be stored in the Unique
Alias field, such as “Chris Eledu” and “Eledu, Chris”. The user’s NC number will also be stored in the
Un
ique Alias field.

The additional information passed from AD to the Domino Directory is mapped as follows to the RDS
Person document “Additional” tab: