|
Introduction
When creating a directory service it's not always obvious that there are probably
many other people tracking the same data in many random ways for different
purposes. A Directory Server should be a central place to consolidate this
information so that it can be kept updated and managed in a single place.
This doesn't always happen because the need for the data is unique for each
user set, and as a result, a central repository lacks key pieces of data that
would enable this capability. Providing a data model that allows data sharing
to happen will go a long way to eliminating out of date data being used for
critical business operations.
Some larger corporations have looked only to find thousands of replications
of the same general data, in various states of update and rarely consistent
with any other list. Even small companies end up with common data managed in a
random fashion by their staff, with each person having their own unique and
out of date copy.
Its not hard to understand why this happens. Some of the main reasons are:
- Each person has a copy on their Laptop PC - contact information needs to
be available when they travel. Same may happen if they have a Pocket PC or a
Palm OS device - A need exist for a copy of the current contact list.
- Some people or applications use this data for business solutions - it
may be for an Excel spreadsheet, A customer mailing list or an application
that monitors usage of resources with the company. People tend to copy data
and update it as they see fit. If these people are away on vacation, or
leave the company, the possiblity exists that the person taking over their
task will have to re-create this data set.
- The list of data needs to fit a certain format for a unique need. It may
be that the more common way of storing this data doesn't provide fast enough
access, or requires a very specific organization. It may also be that people
see it, but don't know how to leverage the data, and rather than try to fit
the available format, they prefer to have their own data set.
There are hundreds of other reasons, however the issue
becomes that of data management and how to consolidate the common core of data
and allow it to exist in a consistent fashion across the enterprise, no matter
the size of the enterprise.
These are some of the things that directory architecture addresses. If you
can solve these sorts of issues, your Return On Investment (ROI) for
establishing a directory service will be quickly realized.
The best part is that you can, and should, start in smaller steps and build
out the infrastructure to solve your business needs. All of these steps should
be definable and measurable.
As part of your long term business strategy, your directory services should
be utilized as a corporate resource - in the long run, better data control can
be placed on solutions and the information that drives your initiatives will
be consistent across your organization. This becomes more important if you
have multiple sites, and partners that you share some data with.
In all cases, keeping your company data secure and immune to virus and
hacker attacks should be a top priority.
Back to top
Solving the Basics
The minimal application of a directory server tends
to be tied to managing peoples contact information. Centralizing this solves
immediate business needs, and opens up the doors for advanced services.
Back to top
Corporate White Pages
People need to be able to communicate with the
other people in the company. White Pages are nothing more than an automated
address book function. As simple as this sounds, making it available, and
allowing users to update things (such as phone numbers, pager numbers, Cell
phone numbers, office location information) will make it easier for your
operation to work together. This is a critical first step.
The data that originates the White Pages entries should be provided by a
source of data that is the reference site - most often there is a tie in to
Human Resources (HR). They typically provide common data (but never secured
data) to the directory service - how often this update occurs is dependent on
how the data is to be used. HR would also be the record of source for removals
of employee directory entries. Doing this keeps your White Pages in sync and
clearly defines who works there and who doesn't - this is critical if you want
to use advanced services that allow controlled access to your Intranet.
Additionally, you will need to address a way to add people that are not
employees. These might be part time workers, vendors, trusted partners and
contractors. You will be listing phone numbers, including those that are
associated with rooms - these are not people; this also holds true for shared
resources such as Fax machines and other conferencing devices.
At this point, to implement this service you will need to work with your HR
department for employees and define policies for non-employee entries. This
could be critical as it may affect your liability at some later date relative
to non-employees being represented within the same system. The HR databases
will never be the same as your Corporate White Pages directory - there are too
many legal ramifications; getting HR to work with you can be a challenge and
will require written business justification as well as agreed upon operational
policies. HR should 'own' any employee entry - they are responsible, however,
there may be push back if HR is not involved in the effort from the beginning.
Back to top
E-mail Services
Many e-mail services utilize directory servers to manage
their users. Examples of this are Microsoft Exchange/2000, OpenWave Intermail,
Novell NDS/GroupWare and iPlanets Unified Messaging solutions. When creating
an e-mail account, you create a directory entry.
It is in your best interests to tie these entries into the White Pages
solution (the above listed solution providers/systems allow for this) to
eliminate duplication of entries in more databases than necessary. All new
employees need an e-mail address, so utilizing these directories that are
already in place and populated by HR to create the e-mail application is the
proper start point.
Keep in mind that 10% or more of your e-mail users will not want to use
their HR 'official' name. Often they will want to use a shortened version (for
example: Mike instead of Michael, or Kim instead of Kimberly), or their middle
name instead of their first name. HR data is often tied to official government
naming/identification, so you usually cannot ask HR to change their data, but,
within the directory, you can provide a way to use the desired name along with
the HR official name.
Back to top
Single Sign On
It would be better for your internal security if your
users only had to remember a single password for their accounts anywhere
within the company. There have been many attempts at this in the past, and it
is usually solvable if everyone is using the same platform/operating system
for everything. The problem is, this is rarely possible. Many Environments
offer Single Sign On (SSO) in one form or another, and using it allows for
simplified account management.
Computing systems are moving to put this sort of SSO data into directories
in the form of authentication. At the high end of the scale this might involve
digital certificates (PKI) and at the low end simple passwords. Its hard to
come up with a universal solution since there are too many types of devices
that have vastly differing capabilities that may need to authenticate. Initial
solutions have focused on an internal user connected to the company's
Intranet; most are platform specific, but do reduce the amount of passwords to
remember if you are all using the same devices. What if you are not?
Examples:
- The average cell phone often has form of highly limited Web browser and
it also has data entry keys (dialing keyboard) that can be used to 'type
data' with. It doesn't lend itself to many applications, however it is an
exceptional notification device - many events could be triggered to call a
user, once the user has told the corporate systems that they want to be
informed about sets of events - it may occur as a result of a policy defined
and established at their corporate directory server. They may be able to
customize these notifications from their cell phones.
- A GPS systems can track where it currently is and report back to a
central system. There is often no human intervention at all during the
process, but each device needs to be able to uniquely identify itself. There
may be thousands of these to track and they may need to send a status as a
part of them 'checking in' to the corporate site.
- Users, while in the office, might need different capabilities than the
same user accessing the same systems remotely. There may need to be 2 or
more completely different models. In the case where a laptop is being used,
if it is lost or stolen, the capabilities of that system may need to be shut
down very quickly, as well as prevent it from doing any more damage than
necessary until it can be recovered or disabled. Even though the user has an
Intranet connection at the office, their capabilities as a remote access
user may need to be diminished, or customized.
- Access should be limited to approved resources. Most Intranets go
everywhere and allow access to all devices and systems. Unless you have a
systems administrator or network staff that can manage the routing of
access to specific devices or internal routes, you may want to associate policies based on
business need or departmental access. Many security problems in a company
come from within - centralized control of resource access can minimize the
effects.
- Web pages that might be shared with customers or internal users who are
at remote sites. Restricting access as is appropriate, or granting
capabilities that normally can only be done internally. Applications such as
'Netegrity' store operational policies into a directory server - allowing
highly customized and secure Web page/data access.
- Provisioning systems access - internal and external access.
Single Sign On means a lot of different things to different people. The
area of Wireless access creates many new security issues to deal with. Simple
platform solutions (for example, Kerbros basedSSO under Microsoft Active
Directory and NFS - Network File System/ NIS - Network Information Service
solutions under Unix) work for many cases, but they may not effectively model
the long term needs of your organization; these simple solutions fall flat
once you attempt to push them beyond their initial solution focus.
Back to top
Security Past Desktops
Desktop systems connected by internal TCP/IP
networks have become the standard access method to internal systems. These
typically would be running Microsoft Windows, Linux or some other flavor of
Unix. The back end systems either have hard coded a specific systems TCP/IP
address, or they are using Dynamic Host Configuration Protocol (DHCP) to
allocate TCP/IP addresses as needed.
Many companies have given laptops to their management and higher level
people to use during the day, often moving these to different locations in
multiple buildings, potentially anywhere in the world. These system may
connect to TCP/IP ports via a cable, or possibly by a wireless network card in
the laptop. The issue here is that these users often have access to critical
company data and because they travel, you cannot lock down where they might be
at any given moment.
It is possible a similar group of people might have other non-PC devices
(RIM BlackBerry, Pocket PC or Palm OS) that are used for various on site and
off site functions.
Some of these will sync data wirelessly, others will need to occasionally
connect to the Intranet to get their data, but all will need to be able to
utilize the Corporate White Pages to function within the organization. They
may need to know schedules, corporate events/calendar information as well as
contact lists of internal employees, contractors and vendors. This is not the
type of data that you want to hand out casually to the Internet for access -
many of these things are critical to your business and may be trade secrets.
The Corporate White Pages and various services that connect to it will be the
central focal point of access to this data.
Policies need to be
in place to manage this information, and it would be a good idea to secure
this data in some way. Some of it may be done by utilizing tools on the end
devices, others will be done by controlled access by the devices on a network
or thru the unsecured Internet.
Some devices, such as cell phones, while they have the ability to access
the network and return data into a minimal web browser, often lack the ability
to send data via a secure mechanism. In cases such as this, they can still be
useful tools, but it is critical not to overwhelm these devices beyond their
limitations or give them access that is not appropriate for the device.
Back to top
Other Databases and Data Sources
Directory Servers are wonderful for
managing data and application operational policies, but they are typically not
the best way to manage all types of corporate data. Relational databases (Such
as Oracle, IBM DB2, SQL Server, Sybase, Postgress, MySQL, and others) are
better suited for transactional data using SQL or ODBC to manipulate it.
Access to this relational database information is controlled by application
software. This software usually has its own security method and users
typically log into it to access the data.
Newer relational database services are beginning to leverage the Corporate
White Pages to determine who is and who isn't allowed to access the data, and
in many cases, when the can access it, determining what data sets are
available. This is often determined by a directory based policy where different
users are associated to a policy based on job level, department, or the
services that a user needs to do their job. This reliance on the base set of
data in the Corporate White Pages means that it needs to be up to date and
accurately defines what capabilities are associated with the each user.
The area of Meta
directories is a way of combining distinct corporate Databases into what
appears to be a uniform data store. Meta directories take a lot of planning
and internal agreements to operate successfully, however the operational
policies, and how they are associated with a given user, or class of user are
typically placed into the same Corporate White Pages directory that people use
to keep track of contacts.
Back to top
LDAP, XML, SQL and Other Data access methods
The right way to
represent data has been a challenge since the beginning of computer systems.
Todays standards simplify things somewhat, but in reality, there is no single
'right' way to format data for all data requests.
If you end up implementing a meta-directory solution, all of these access
methods will become blurred into a larger single view of the world. The
challenge will be to find how they relate and then define the methods required
to join them. The goal of 'Write Once - Replicate Everywhere' becomes
possible with a little planning and cooperation among data centers.
It is likely that you will need to access applications, databases and other
networks using these protocols. In all cases, using a standards based
communication method will shorten development times and in the long term
create a more manageable system.
Back to top
LDAP
LDAP (Light Weight Directory Access Protocol) is not a type of
database, it is a protocol by which you access the data.
LDAP deals in data objects. Typically, these do not map well into
relational database models, and are implemented as Object Oriented Databases.
It is possible to do this using a relational database, however, the end result
will often not be accessible in an intelligent way using SQL or ODBC - the
data will be best accessed using LDAP.
Data objects may or may not be multi-valued and their individual content
depends on the object classes that they inherit when they are created or
updated. Objects are placed in trees and similar/related objects are often
grouped together based on business need rather than general relationships. It
is possible to create elements in the same tree structure that are vastly
different than other objects in the tree.
LDAP allows you to easily traverse the tree and find the objects that you
have been granted access to (access control is typically associated with
individual authentication, group controls or directory based policies).
LDAP Directories are best suited for mostly read-only access. They are also
typically used to secure access to other systems because of their ability to
associate complex data objects to general entries.
Back to top
XML
Extensible Markup Language (XML) is a method/protocol by which
unique data can be disseminated to different systems and have that data be
utilized in a consistent fashion. This is a tall order for any protocol to
accomplish, however it allows data to be represented once and then allow any
device to be able to translate that to a format that is meaningful to it. It
manages this by considering each XML transaction as a document, and these
documents can be formatted as needed using DTD's or other document
descriptions.
There are no XML databases, but most databases can return their data in an
XML format. This format may vary depending on who or what asked for it. In the
case of wireless devices, such as a cell phone, almost every model has unique
characteristics and it is far better to be able to create a single XML adapter
for that device than trying to create a general formatting tool to handle all
of the potential variations.
Other systems that use XML create a translation table to map the XML
document to a format that means something to that system. While this is
verbose and apparently inefficient in some ways, it actually provides a
'Rosetta Stone' method by which any data can be shared with any other system.
This allows data that was previously very difficult to access become a
commodity data source. There are still many issues about XML that will not
become obvious until you try to implement a solution, however, the problems
are not unsolvable and they are more scalable in the long run.
Back to top
SQL/ODBC
LDAP directories use an object oriented model to store their
data in. For many applications, this is not an optimal choice. Relational
databases provide solutions that have been successfully deployed and remain
critical to operations.
Access to most Relational databases is via SQL and ODBC. These are
standardized to the point where it is fairly easy to create queries against it
to locate data. There are also many external applications that can make
requests using dynamic SQL or ODBC (Excel, Access, etc.).
Back to top
Triggered events
SQL databases provide triggers - these are data
sensitive actions that cause other events to occur as the result of a
transaction completion, or a business rule that has been met. LDAP has no
concept of this logic, however, that does not mean that it is not a valuable
function to provide.
Currently, the only way to set up triggers in an LDAP directory server is
to capture the actual LDAP request and test to see if it will be doing
something that you are interested in. If it is, then you will have to cause
the triggered event to occur. Some directory servers allow you to build that
into the LDAP engine, others do not.
If you are using your directory server to manage an application, putting
the trigger logic into the directory server (as its done with relational
databases) makes good data management sense.
Back to top
Operational Policies
First and foremost, all data elements need to be
defined in the context of an access/usage policy. These are general guidelines
about what is available and how it may be used. All applications and services
must register how they will use this data and be held accountable for it.
Another type of policy is where the
directory itself manages how data is used and/or how an application interacts
with other operations internally or externally.
Back to top
Scalability
Directories can handle many entries - they are databases
and have been used to make available data about people, places or things. The
number of entries that you have will depend on how you want to manage your
resources.
Once you have White Pages in place, it becomes a simple task to add asset
management and associate those assets to a person, place, or thing. For
example, many organizations assign a badge to a user; that badge number may be
listed as a part of a persons entry. That person may have a desktop PC and a
laptop PC - these assets can also be associated with the user. In reality,
since these additional attributes can be hidden in a way that White Pages
functions can't see them, a large amount of common data is often kept in the
directory structure about a user. These profiles can be associated with
operational policies as well.
Directory servers are designed to scale to very large numbers of entries
containing an ever increasing number of unique attributes that describe
interrelated data in ways that were not easily done before. The same structure
used for 50 people will work for 100,000 people.
Back to top
Availability
Directory servers that handle your security model (Single
Sign On, Applications Access, etc.) will become central to your operations.
Your business security model will often migrate into the directory server as a
function of applications that use it, and to leverage the capabilities and
licensing of your software.
Once your Directory Server is up and available, it needs to stay up and
available. Any design that you put in place must not be sensitive to:
- Network outages - you must have one or more alternate systems and your
applications need to know how to use all possible paths.
- General maintenance - There must be a way to allow the systems to be
serviced, upgraded or reorganized.
- Excessive use - Connections to a directory server use TCP/IP sockets - a
poorly designed LDAP application connects, then never releases when it's
done. Over time (often a very short period), the directory server could be
rendered un-usable by a simple application. You need to provide more than one
access point to your system, and manage all testing in an area that will not
affect production utilization.
- Remote access - Some data needs to be consistent across the network,
while other parts may be segmented into functional areas. Many locations
need unique data, others require a very limited subset of common data. If
these servers are critical to operations, they must also be replicated with
the same data model.
Back to top
Directory Synchronization
All directory servers synchronize to other
like directory servers. If your data is consistently defined at all
sites, this remains simple. In many cases you may be able to sync a subset of
the data, but again, only to a like directory server.
It is likely that you will need to create a custom sync function that
allows you to sync any portion of the Directory data, in any format, to any
database server (could be via XML or SQL) in your network. In a sense, your
master directory will contain too much data and you have to share it on a
business need basis.
It is also likely that you will want to push data into to your directory
server from external sources. This may because your data is from a different
type of database, or the data source is not under your direct control.
Anything that sends to your system, should never do so directly if the data
originates outside of your local Intranet. Your directory may become the hub
of your business - security of your data should be a top priority.
Back to top
Other issues to resolve
Directory Redundancy
- Locations
- Disaster Recovery Issues
- Backups
- Intranet/Extranet issues
Sharing access to the outside world
- Policies
- Encryption
- Laws relating to data transfer
Data Sources
- Internal
- External
- ASP
- Other
Applications
- Messaging
- Org Charts
- Trouble Ticket Tracking
- Network Management
E-Services
- Collaboration
- Scheduling
- Calendaring
- B2B
- B2C
- P2P
Back to top
Questions? Comments? Contact Engineering
|
