best practices for designing a secure active directory ...hosteddocs.ittoolbox.com/ds031204.pdf ·...

®

written byDmitry Sotnikov,Aelita Software

White Paper

Best Practices for Designinga Secure Active Directory:

Multi-Org Exchange Edition

AELITA SOFTWARE CORPORATION

Phone: 614-336-92231-800-263-0036

Fax: 614-761-9620

Email: [email protected]: www.aelita.com

6500 Emerald Parkway Suite 400Columbus, Ohio 43016,

This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. However, because of the possibility of human or mechanical errors, Aelita Software does not guarantee the accuracy, adequacy, or completeness of any information in this publication, and is not responsible for any errors or omissions or the results obtained from use of such information.

Unless otherwise noted, the example companies, organizations, products, people, and events depicted herein are fictitious. No association with any real company, organization, product, person, or event is intended or should be inferred.

Aelita Software does not endorse or accept any responsibility for the content or usage of links and references to non-Aelita Web sites or technical documentation.

No part of this document may be reproduced, stored or transmitted in any form, by any means, or for any purpose, without the express written permission of Aelita Software Corporation.

Aelita, Aelita Software, the Aelita Software Corporation logo, and all Aelita product names and slogans are either registered trademarks or trademarks of Aelita Software Corporation. Other product or company names mentioned herein may be trademarks of their respective owners. Copyright © 1997-2004, Aelita Software Corporation. All rights reserved. Last revised February 19, 2004

Abstract This paper discusses how to select the optimal design for Active Directory that meets your company's requirements and maintains a balance between administrative and support costs, ease of collaboration, and the desired level of security and isolation.

mailto:[email protected]

http://www.aelita.com

CONTENTS

INTRODUCTION ........................................................................................................ 5 DEFINING ACTIVE DIRECTORY SECURITY BOUNDARIES ........................ 6 SINGLE FOREST/SINGLE ORGANIZATION ...................................................... 8

Security Considerations ............................................................................................... 9 Messaging and Collaboration ...................................................................................... 9 Data Replication and Synchronization ......................................................................... 9 Administration .......................................................................................................... 10

MULTIPLE FORESTS/SINGLE ORGANIZATION ................................................ 11 Security Considerations ............................................................................................. 12 Messaging and Collaboration .................................................................................... 13 Data Replication and Synchronization ....................................................................... 14 Administration .......................................................................................................... 14

MULTIPLE FOREST/MULTIPLE ORGANIZATION ................................................ 15 Security Considerations ............................................................................................. 16 Messaging and Collaboration .................................................................................... 17 Data Replication and Synchronization ....................................................................... 17 Administration .......................................................................................................... 18

SUMMARY ................................................................................................................... 19 Aelita Solutions ......................................................................................................... 20

GLOSSARY .................................................................................................................. 21 ADDITIONAL INFORMATION ............................................................................. 24 ABOUT AELITA SOFTWARE CORPORATION................................................. 25

Best Practices For Designing A Secure Active Directory: Multi-Org Exchange Edition 3

INTRODUCTION

This paper discusses best practices for Active Directory and Exchange 2000/2003 design. A single Active Directory forest design is compared to multi-forest designs with a focus on security and operational efficiency. Changing the Active Directory design after it is deployed might become a big administrative challenge. Thus, security and efficiency should be considered when planning Active Directory.

A single Active Directory forest design is the simplest design, where there is only one forest for the whole corporate network: it is the simplest to administer, provides lower support costs, and offers the best messaging and collaboration environment for a whole company using Exchange 2000/2003. However, a single forest might not provide the level of security and isolation required by some companies.

In a multi-forest Active Directory design, the corporate network is separated into several forests. This design carries higher administrative and support costs, and complicates collaboration and messaging. However, it offers the highest level of security isolation. In addition, a multi-forest design is considered by some companies because of organizational structure issues (e.g., autonomous business units and decentralized IT departments), business policy, or legal and regulatory requirements.

Optimal design depends on specific company requirements and should represent a balance between administrative and support costs, ease of collaboration, and the desired level of security and isolation.


DEFINING ACTIVE DIRECTORY SECURITY BOUNDARIES

Active Directory allows administrators to organize the elements of a network, such as users, computers, and devices, into a hierarchical, tree-like structure based on the concept of containership. The top level Active Directory container is called a forest. Within forests, there are domains. Within domains there are organizational units (OUs).

Although Active Directory provides for granular delegation of administrative rights at the domain and the OU levels, neither domains nor OUs can provide proper security isolation. A domain in Windows 2000/2003 Active Directory cannot be considered a security boundary. Every domain controller (DC) in a forest holds a writable copy of the schema and configuration. A domain administrator or somebody with physical access to a DC can potentially disrupt the forest by attempting to circumvent Windows security or by editing the Active Directory database, with the changes being propagated to all domains in the forest. In addition, a domain cannot prevent Domain Trust attacks by service administrators who can potentially elevate their privileges beyond a domain boundary. In fact, anyone who has administrative or backup/restore rights on any domain controller or physical access to any domain controller can potentially gain full control over the whole forest to which the domain belongs. This particular vulnerability was announced in January 2002 by Microsoft. For more information on this Active Directory forest security vulnerability, please see the Protecting Active Directory from Domain Trust Vulnerability white paper at http://www.aelita.com/ADSecurity.

Microsoft recommends that the forest must be considered the security boundary in Active Directory design. All network elements that require security isolation need to have their separate Active Directory forests. This design is referred to as a multi-forest Active Directory design.

6 Best Practices For Designing A Secure Active Directory: Multi-Org Exchange Edition

http://www.aelita.com/ADSecurity

A multi-forest Active Directory design provides the security and isolation required by some enterprises, but it also introduces the need for inter-forest collaboration solutions. The most important among them is the Exchange 2000/2003 messaging system. The main decision in the multi-forest Active Directory deployment is whether to have separate Exchange organizations for each Active Directory forest or for the forests to share a single common Exchange organization.

The following configurations are the main ones to be considered:

• Single Active Directory Forest/Single Exchange Organization (SF/SO)

• Multiple Active Directory Forest/Single Exchange Organization (MF/SO)

• Multiple Active Directory Forest/Multiple Exchange Organization (MF/MO)

This document describes these configurations in detail.


SINGLE FOREST/SINGLE ORGANIZATION

The simplest Active Directory configuration is a single forest with a single Exchange organization. This is the configuration most companies selected during early Active Directory deployments.

AD Forest

ExchangeOrganization

The main advantages of the SF/SO model are:

• Administration is the least complicated of the three designs.

• Replication is handled by native Active Directory/Exchange mechanisms.

• There is no need for synchronization between forests and Exchange orgs.

• Messaging and collaboration with all network users is intrinsic.

This configuration has the following drawbacks:

• There is no means of separating network elements that are required, either legally (regulations) or because of business policies (autonomous business units), to be completely isolated and secure.

• The absence of security boundaries within the forest leaves domains vulnerable to rogue administrators.

This design can be used in smaller companies that do not need to isolate any parts of their networks and that have a limited number of people with domain administrative rights. However, due to security, business policy, or regulatory reasons, this configuration might not suit medium- and large-size enterprises.


Security Considerations

This model is the weakest from a security perspective. As stated earlier, in Active Directory a forest is the only security boundary that can offer full security isolation and protection from possible security breaches. A single-forest Active Directory configuration, therefore, has no such secure boundaries.

Anyone who has either administrative or backup/restore rights on any domain controller or physical access to any domain controller can potentially gain full control over the whole forest.

This means that a company must completely trust all administrators in all domains of the forest and ensure that all domain controllers are located in safe and secure places.

Other means of risk mitigation might include deploying administrative software for Active Directory auditing and security, as well as for secure “rules & roles” Active Directory and Exchange management.

However, if security isolation is a legally mandatory requirement, a single forest solution cannot be used.

Messaging and Collaboration

In a single forest, all users have mailboxes in the same Exchange 2000/2003 organization, which gives them full collaboration capabilities with no additional administrative costs. They see all of their colleagues in the Global Address List (GAL); they can exchange mail, schedule meetings, and view each other’s free/busy information; and they can access documents in the same public folders.

Data Replication and Synchronization

In this model, the entire company is using a single Active Directory forest and Exchange organization. This means that all data can be replicated by native Active Directory and Exchange mechanisms. In addition, this design uses one company-wide global catalog infrastructure, which speeds searches and enables Exchange 2000/2003 to generate one GAL for all users.


Administration

The main advantage of this Active Directory design is its administrative simplicity. This configuration represents the least possible administrative overhead.

• Trusts. Active Directory automatically manages inter-domain trusts within a forest.

• Unified administrative model. A single service administration group can manage Active Directory service issues, while data administrators from particular domains and OUs can set security in their containers.

• Products exist from both Microsoft and third parties to permit the movement of certain types of objects, such as user or computer accounts, from one domain to another in the same forest.

Having Exchange set up in the same forest where the user accounts are located is another important administrative advantage of the model. Active Directory and Exchange share the same directory. Each user account has a mailbox associated with it, so little additional Exchange administration is required. For example, user properties, such as name, phone numbers, and e-mail addresses, are set only once.


MULTIPLE FORESTS/SINGLE ORGANIZATION

A multiple forest design is the only option whenever security isolation is required. If a company chooses a multiple forest model, the main question that arises is the messaging system setup.

Under the MF/SO model, while user accounts are split into multiple Active Directory forests, all mailboxes are located within a single Exchange 2000/2003 organization. This configuration is similar to the traditional Windows NT/Exchange 5.5 model, when separate directories were used for accounts and the messaging system.

Exchange Forest

Account Forest Account Forest

Account Forest

The model’s advantages are:

• Multiple forests provide directory-level security boundaries.

• A single Exchange organization provides for a single GAL and full Exchange collaboration capabilities.

• Native Exchange data replication is used, lowering administrative overhead.

• All Exchange administration is done within a single organization.

This model’s drawbacks are:

• Each forest needs separate service administration, raising administrative overhead.

• Trusts between the forests have to be set up and managed manually. This issue is mitigated by the inter-forest trusts available in Windows Server 2003 forest functional mode.


• The separate directories maintained for user accounts and the messaging system need to be continually synchronized.

• A single messaging system might not fulfill security, business policy, or legal requirements, just as is the case with a single forest design.

This model provides directory isolation, so it can be used in medium- and large-size companies. However, its use involves more administrative effort and requires directory synchronization/ provisioning between the forests.


Security is the main reason for using the multiple forest design. An Active Directory forest can be used as a security boundary in the corporate directory. However, security does not come automatically; to be effective, the boundaries need to be properly set up.

Trust relationships are required between the account forests and the Exchange forest. The Exchange forest needs to trust the account forests; otherwise users will not be able to get access to their mailboxes.

You might also have to set up trusts between the account forests if users need to access to any shared resources in other forests.

Exchange Forest

Account Forest Account Forest

Trust withSID Filtering

Trusts are a potential security exposure through which a malicious user might circumvent the security boundary. To prevent this, you must make sure that security ID (SID) filtering is set up on each trust relationship between forests. With this feature enabled, malicious users can not insert forged administrative SIDs into other Active Directory forests.


When setting up group membership, you should make sure that the administrative groups from one forest do not include accounts from the other forests. Users from other forests should not be included in any of the following groups:

• Groups responsible for service management, or groups that can manage the membership of service administrator groups

• Groups with administrative control over computers that store protected data

• Groups that have access to protected data, or groups responsible for the management of users or group objects that have access to protected data

If users from another forest are included in any of these groups, then a breach of the other forest might lead to a breach of the isolated forest and to a security risk for protected data.

Within the forests it is still recommended that security precautions including the ones listed for SF/SO design are implemented.

If provisioning/synchronization/metadirectory solutions are used to automate the multi-forest administration and account management, it is important that these solutions are evaluated from security standpoint.

If security or legal requirements demand that certain parts of an organization have totally isolated messaging systems, this model cannot be used; the organization must have multiple, separate Exchange organizations.


A single Exchange organization shared by the whole directory is ideal for the messaging system setup. All users have their mailboxes within the same organization. They have all their colleagues in their GAL; they can schedule meetings and use other Exchange intra-org collaboration capabilities.

Also a single Exchange directory simplifies Exchange administration:

• All mailboxes are within the same Exchange organization so no additional third-party tools are required for their intra-org collaboration.

• Exchange data is replicated by the native Exchange mechanisms.

• The Exchange administration team has its own separate Exchange directory much like they had in Exchange 5.5, which reduces the required learning curve.



Having a separate forest dedicated to the Exchange directory raises a new directory synchronization challenge. Basically, each user account in an account forest has a corresponding disabled account and mailbox in the Exchange forest. This means that two accounts exist for each user. The account properties should also be synchronized between the account forests and the Exchange forest. Provisioning and deprovisioning should be accomplished when new user accounts are created or removed.

This directory synchronization and provisioning is a difficult task that needs to be continually executed. Performing synchronization manually is complicated and requires much administrative time and effort. Moreover, it cannot be performed just by native Active Directory mechanisms.

Administration

As with any multiple forest configuration, the main disadvantage of this model is the increased directory structure complexity. This leads to an increased administration burden:

• Each forest needs separate service administration.


• The Exchange organization is located in a separate forest, so its directory also needs to be administered

Another issue is that each user is represented by two objects: a user account in the account forest and a disabled mailbox account in the Exchange forest. This means that additional administration and directory synchronization software should be used to manage these duplicate directories.


MULTIPLE FOREST/MULTIPLE ORGANIZATION

In the MF/MO model, the directory is split into separate Active Directory forests, with each of the forests having its own Exchange organization.

Forest withExchange Organization



This model provides several advantages:

• Multiple forests provide security boundaries between the directories.

• Each Exchange organization/Active Directory forest pair shares the same directory.

• This design provides for full security isolation of both directory and messaging systems.

The model’s drawbacks include the following:

• Each forest needs separate service administration.


• Each forest has its own administration teams (including service administration, such as schema management).

• The messaging system is split, so additional software is required to enable collaboration between users in different Exchange organizations.


This model provides the best possible options for security isolation of directory and messaging system segments. It can be used in medium- and large-size companies wherever security boundaries are required. However, the model’s implementation requires directory and data replication between the Active Directory forests and Exchange organizations for inter-forest user collaboration.


As a multi-forest model, this approach is safe because it maintains security boundaries between directories. Each forest is administrated separately and can be protected from possible attacks from other forests.

Some of the same security considerations that were listed in the MF/SO apply to this model as well:

• Each forest needs separate service administration, raising administrative overhead.

• The separate directories need to be continually synchronized.

However, MF/MO model is safer, because it lets the administrators isolate messaging system segments as well as the directory forests. Each forest has its own Exchange organization for the accounts in the forest.

Trusts between the forests are:

• Required for shared resource usage

• Possibly required for data synchronization software that provides for inter-forest user collaboration

The trusts and data replication between the forests should be set up with the proper security consideration in mind. (Refer to Multiple Forests/Single Organization - Security Considerations on page 5.)

If any inter-forest synchronization/identity management/metadirectory solutions are put in place, special considerations should be given to the security aspects. Many of these solutions have requirements that violate forest security isolations, including the following:

• Might require using service accounts from other forests

• Might have a single installation that manages account and other information in several forests


In the worst case, administrators of the synchronization software installed in just one of the forests could effectively get control over data and accounts in all the forests being synchronized. Thus the software ruins the security isolation and administrative autonomy that were the drivers for multi-forest deployment.


Inside each forest, user collaboration is provided by the Exchange organization installed in the forest. However, the messaging system and, therefore, collaboration are fractured since each forest has its own Exchange organization.

This means that additional work is required to minimize the impact on users. This requires additional software and administrative effort to establish data replication and synchronization of both Exchange and Active Directory data between the forests.


The main replication and synchronization challenges for this model arise from the Exchange organization being split between two or more forests and the subsequent interruption in collaboration. Employees of any company would surely like to have a unified messaging system. At a minimum, they would like to see their colleagues in their global address lists. This makes directory synchronization necessary.

Companies that choose the MF/MO model have to decide what data needs to be synchronized and how tightly the collaboration capabilities should be synchronized between the forests. For example, GAL synchronization lets users exchange e-mail. However, if they need to be able to use calendaring (e.g., schedule meetings and phone calls), then at least their calendar free/busy information should be made available across the forests.

Unfortunately, no native Active Directory or Exchange tools can perform this synchronization. Third-party tools or a collection of tools from Microsoft including Microsoft Identity Integration Server (MIIS) are required to implement Exchange data and directory synchronization when deploying the MF/MO model.


Administration

Within each of the forests, the MF/MO model offers the Exchange administration simplicity of the SF/SO model. Exchange and Active Directory share the same directory. No separate Active Directory accounts should be set up for Exchange mailboxes.

On the other hand, as with any multiple forest model, this configuration increases directory administration complexity:

• Each forest needs a separate service administration.

• Synchronization of Exchange data and Active Directory between the forests would also require additional administrative effort.


SUMMARY

Many medium- and large-size companies are considering a multi-forest Active Directory deployment for security, business policy, or legal reasons, or because of autonomous business units. Depending on the messaging system deployment, two multi-forest models are available.

In a MF/SO model, a single Exchange forest is established with information being shared by users from the other forests. The separate Exchange forest and the various account forests require directory synchronization between them.

In a MF/MO model, each forest has its own Exchange organization. Multiple Exchange organizations hinder user collaboration and require Exchange data to be replicated between the organizations.

The table below summarizes the advantages and drawbacks of each model:

SF/SO MF/SO MF/MO

Security boundaries

No Between forests Between forests and Exchange organizations

Messaging and collaboration

The same Exchange 2000/2003 organization for all users

The same Exchange 2000/2003 organization for all users

The messaging system is split between multiple Exchange organizations

Required synchronization

All synchronization and replication handled by native Exchange/Active Directory mechanisms

Directory synchronization required between the account forests and the Exchange forest

Directory and data synchronization is required between the separate forests

Administration Simplest to administer

Increased administration burden

Increased administration burden

Companies should spend considerable time researching and evaluating these three design alternatives; transitioning from one model to another after implementing an Active Directory/Exchange solution can be complex. Furthermore, multi-forest designs cannot be fully implemented with the native Active Directory and Exchange mechanisms and require third party tools for ongoing management and synchronization.


Aelita Solutions

Aelita's exclusive focus is to provide the most innovative, customer-focused solutions for migration, administration, security, and recovery of Windows systems, Active Directory, and Exchange. Our products include:

Aelita Enterprise Migration Manager

Whether your changing world dictates simple "pruning & grafting" or more extensive Active Directory redesign, Aelita Enterprise Migration Manager offers a complete, ZeroIMPACT™ solution to your restructuring needs. Enterprise Migration Manager's flexibility makes it ideally suited to meet the technical requirements associated with Active Directory restructuring projects. Your organization will save both time and money as the project is shortened through automated migrations and parallel processing. Organizations will save time with scalability designed to meet the demands of the largest organizations.

Aelita Enterprise Directory Manager

Aelita Enterprise Directory Manager provides a secure “rules & roles” management platform that facilitates secure administration of Active Directory and Exchange. It can integrate with HR applications and other enterprise directories to streamline account and resource provisioning and overall identity management. Enterprise Directory Manager provides a secure “rules & roles” management platform that facilitates secure administration of Active Directory and Exchange. The software can be used both within one forest and in multi-forest environments.

Aelita Collaboration Services for Exchange

Secure by design, Aelita Collaboration Services for Exchange provides global address list and free/busy synchronization while maintaining security isolation between organizations. Administrators of multi-forest Active Directory deployments can optimize the power of synchronization yet maintain regulatory compliance and administrative autonomy. Administrators can eliminate the manual tasks of duplicating contacts in several address books. Users can stop maintaining complex personal address lists and sending multiple emails to find available meeting times.


GLOSSARY

Account Forest

In MF/SO design, an Active Directory forest that hosts user accounts. Users from an account forest use mailboxes located in the Exchange forest.

Active Directory

The directory service that stores information about objects on a network and makes this information available to users and network administrators.

Data Administration

Managing the objects in the directory and setting permissions on them. This includes managing computers, users, groups, organizational units, and Group Policy settings.

Domain

In Active Directory, the container within a forest that represents an administrative and replication boundary. Domains are normally created for geographical or organizational reasons, mainly to separate administration and/or reduce replication.

Domain Controller

In a Windows domain environment, a computer running Active Directory that manages user access to a network, which includes logging on, authentication, and access to the directory and shared resources.

Domain Trust Vulnerability

The security issue in Windows NT/2000/2003 trust relationships that allows for elevation of privilege attacks.

Exchange Forest

In MF/SO design, the Active Directory forest that hosts the Exchange organization that contains mailboxes for all user accounts in all the account forests.

Exchange Organization (Org)

A set of computers running Microsoft Exchange Server that provide messaging and collaboration services within a business, association, or group. In Active Directory, only one Exchange organization can exist per Active Directory forest.

Forest

In Active Directory, the highest level container. A forest is a collection of one or more Windows domains that share a common schema, configuration, and global catalog and that are linked with two-way transitive trusts.


Global Address List (GAL)

A list of all Exchange users, contacts, groups, conferencing resources, and public folders in an organization. This list is retrieved from the global catalog servers in Active Directory and is used by Outlook clients to address messages or find information about recipients within the organization.

Global Catalog

The server that holds a complete replica of the configuration and schema naming contexts for the forest, a complete replica of the domain naming context in which the server is installed, and a partial replica of all other domains in the forest. The global catalog is the central repository for information about objects in the forest.

Multi-Forest Design

An Active Directory configuration in which the corporate directory is split into multiple separate forests.

Multiple Forests/Multiple Organizations (MF/MO)

An Active Directory configuration in which each forest has its own Exchange organization.

Multiple Forests/Single Organization (MF/SO)

An Active Directory configuration in which a single dedicated Exchange forest is set up as the common messaging and collaboration system for the corporate directory, which is split among several forests.

Organizational Unit (OU)

An Active Directory container object used within domains. An organizational unit is a logical container into which users, groups, computers, and other organizational units are placed.

Replication

The process of updating the directories of all servers within and between sites.

Schema

A description of the object classes and attributes stored in Active Directory. For each object class, the schema defines the attributes that the object class must have, the additional attributes it may have, and the object class that can be its parent.


Security ID (SID)

A data structure of variable length that identifies user, group, and computer accounts. Every account on a network is issued a unique SID when the account is created. Internal processes in Windows refer to an account’s SID rather than the account's user, group, or computer name.

Service Administration

Tasks completed by the administrator to deliver the directory service, administer domains, own the domain controllers, and manage the configuration of the directory.

SID Filtering

A mechanism set on trust relationships to prevent inter-forest attacks.

SIDHistory

An account attribute that can optionally hold SIDs from the account’s previous domains in case it took part in account migration.

Single Forest Design

An Active Directory model in which the corporate directory consists of a single Active Directory forest.

Single Forest/Single Organization (SF/SO)

An Active Directory model which has a single forest with a single Exchange organization.

Synchronization

The process required to update data in multiple directories/Exchange organizations so that users can share common resources.

Transitive Trust

The standard trust relationship between Windows domains in a domain tree or forest. When a domain joins an existing forest or domain tree, a transitive trust is automatically established. Transitive trusts are always two-way relationships. This series of trusts between parent and child domains in a domain tree and between root domains of domain trees in a forest allows all domains in a forest to trust each other for the purposes of authentication. For example, if domain A trusts domain B and domain B trusts domain C, then domain A trusts domain C.


ADDITIONAL INFORMATION

“Active Directory and the Domain Trust Vulnerability”:


Microsoft: “Using Security Identifier (SID) Filtering to Prevent Elevation of Privilege Attacks”

http://www.microsoft.com/windows2000/techinfo/administration/security/sidfilter.asp

Microsoft White Paper: “Design Considerations for Delegation of Administration in Active Directory”

http://www.microsoft.com/windows2000/docs/addeladmin.doc

Microsoft: “Best Practice Active Directory Design for Managing Windows Networks”

http://www.microsoft.com/WINDOWS2000/techinfo/planning/activedirectory/bpaddsgn.asp



http://www.microsoft.com/windows2000/techinfo/administration/security/sidfilter.asp

http://www.microsoft.com/windows2000/docs/addeladmin.doc

http://www.microsoft.com/WINDOWS2000/techinfo/planning/activedirectory/bpaddsgn.asp

ABOUT AELITA SOFTWARE CORPORATION

Aelita Software provides systems management solutions to organizations that rely on Microsoft Windows technologies. Aelita’s proven expertise with Active Directory and Exchange helps customers improve productivity, system availability and security. IT professionals choose Aelita solutions to administer, migrate, recover and audit these critical systems. The company’s customers and partners include Bristol-Myers Squibb, HMS Host (formerly known as Host Marriott Services), Kmart Corporation, Pitney Bowes, Textron, Inc., Hewlett-Packard and Microsoft. Aelita is a global organization with headquarters in Columbus, Ohio. Contact Aelita at 800.263.0036 or visit www.aelita.com

Contacting Aelita Software Corporation:

Web: www.aelita.com Technical Support: [email protected] Sales: [email protected] General Inquiries: [email protected]

Phone: 614-336-9223 1-800-263-0036 Fax: 614-761-9620

Aelita Software Corporation

6500 Emerald Parkway Suite 400 Columbus, Ohio 43016 USA


http://www.aelita.com/

http://www.aelita.com/




best practices for designing a secure active directory ...hosteddocs.ittoolbox.com/ds031204.pdf ·...

Documents