Está en la página 1de 73

Why AD??

Scenario 1
You create a company, Microsoft
Employ 60 people
Everybody is provided a workstation to work
They get divided into 3 teams, of 20 ppl each
Everybody comes to office > works on their computers and stores data
on their assigned computers.
Since 20 people work in a team to develop a software, they need to
collaborate, share/review each others work.

Without AD

Users use a local user account on their computer to login and work on it. They
are the only ones knowing the password for this local account.

Nobody else can login to his computer when the workstation owner is OOF
nor can they get access to his work?

if all member in the 20 person team need to have access to every members
computer i.e. login or access resources stored locally or shared on the
computers -> we need to create 20 user account with separate passwords on
all 20 computers, which makes it 400 users account to create and maintain
per team of 20, i.e 20 user account per person and now he had to remember
20 different passwords.
if you keep the same user account on all with same password, its like letting
all door open, no security, no auditing etc.

Its difficult to manage share data between us


- users store data in there local workstation, and share it.
- difficult to manage - access control and audit
- fear of loss of data if a user computer goes bad or user deletes it by
mistake.

All team members can store their work and resources in a common location,
possibly a fileserver.
- If you have to keep all data and resources on a central server, local
accounts have to be created and maintained on fileserver for all users.

Information about the user also needs to be maintained in some master


database, like emp IP, Phone, Email, department etc.

If a user is allowed to use any machine in the company, he may want that his
user configuration and data in his profile roams with him. With local users its
not possible.

The company may needs server security policies applied on all computers
and for all users who use them. Since we are dealing with local user accounts
and workgroup computers, we would have to apply security policy and other
configuration individually on all computers.

out of the 20 member in team, 1 leaves the company and joins Google. After
the user has left, if the local accounts created for that user has not been
deleted from all computers, he may still be able to hack-in and access
resources.

**Active Directory**
Microsoft implements AD :

Create user account for all users in the company.


Common / central store that maintains user / computer accounts.
This common store is referenced every time the user wants to
authenticate and access resources.
No local users accounts need to be created on workstations to logon
interactively.
users can access shares on a fileserver using domain user credentials, no
local user need to be created on fileserver.
These user accounts not only contains username, password used to
authenticate the user but can also store a lot of information like email,
phone, department, designation etc.
Security related configuration can be made on the user accounts too
like logon to, login hrs, user cannot change password etc.
These users account can be made part of domains groups whose scope is
much wider that the local groups.
We can also manage the user accounts easier like password
change/disable/deletion. Any change in the domain account affects the
user login, resource access etc.
Roaming profile can be configured for user.

Joins computers account used by these users to domain.


By joining computers account in domain, you bring all computers with a

Security setting and configuration can be deployed to the user and computers
Software can be deployed to the user/computers
Users can be restricted to use selected software.
Features on application and OS can be turned on/off.

AD provides a central store where users and computer details are stored - you
can take backup of the database. Disaster recovery is easy.

AD also acts like a authenticating authority. Supports much secure


authentication protocols like Kerberos.

An IT admins can be delegated control to manage user, computers and


services within a domain.

OU structure can be designed to organise User and computers as per process,


location, roles etc.
Delegation of control can be given at OU level. GPOs can be deployed at OU
level. Searches can be done keeping OUs DN as the base for the search etc.

Stand-alone (Workgroup)
Authentication
The identity store is the security accounts
manager (SAM) database on the Windows system
No shared identity store
Multiple user accounts
Management of passwords is challenging

Active Directory Domains: Trusted


Identity Store

Centralized identity store


trusted by all domain
members
Centralized authentication
service
Hosted by a server
performing the role of an
Active Directory Domain
Services (AD DS) domain
controller

Organizations can use Active Directory Domain Services


(AD DS) in Windows Server 2008 to simplify user and resource
management while creating scalable, secure, and manageable
infrastructures:
1. Centralized directory - hierarchical database
Stores information about user objects, computers, and
services (such as an e-mail address).
2. Stores this information in a secure database and provides the
tools and interfaces for managing and searching the
directory.
3. Allows you to manage all network user accounts and
resources in single location and apply policies to the directory
objects to ensure that all are managed consistently.
4. Delegation of control for administration.
5. Helps in Auditing resource access
6. Multiple DCs in a domain, load balance AD services and make
them highly available too.
7. Authenticates user and computer objects. Also helps provide
Single Sign On.
8. Scalability - DCs, objects can be scaled up.
9. Extensibility The structure of the Active Directory database (the
schema) can be expanded to allow customized types of
information.

AD DS objects and attributes

Active Directory Schema


The Active Directory schema defines objects that can be stored in Active
Directory. The schema is a list of definitions that determines the kinds of
objects and the types of information about those objects that can be stored
in Active Directory.
The schema is defined by two types of objects:
schema class objects (also referred to as schema classes) and
schema attribute objects (also referred to as schema attributes).
This Schema can be extended to add new classes and attributes.
Additions to AD Schema cannot be removed, but can only be disabled.
Schema can be modified on just 1 DC in forest, with Schema Master role on
it.

Active Directory FOREST


Forests A forest is a grouping or hierarchical arrangement of one or
more separate, completely independent domain trees. As such,
forests have the following characteristics:

Forest can have one or more domains.


All domains in a forest share a common schema.
All domains in a forest share a common global catalog.
All domains in a forest are linked by implicit two-way transitive
trusts.
Trees in a forest have different naming structures, according to
their domains.
Domains in a forest operate independently, but the forest enables
communication across the entire organization.

A Domain is a logical grouping of AD DS objects, and it is the most basic


building
block in the AD DS model.
Each domain must have at least one domain controller installed. In fact, you
create a domain by installing the first domain controller in the domain, and you
remove a domain by removing the last domain controller in the domain.
Single domain model
Multiple domain model
A single domain model is the easiest
regional
to administer and the least
groups /logical divisions in org
expensive to maintain. It consists of
Reduce Replication traffic
a forest that contains a single
Increase administrative complexities
domain. This domain is the forest
Needs to plan GC placement
root domain, and it contains all of
Better delegation of control.
the user and group accounts in the
The regional domain model consists of a
forest.
forest root domain and one or more regional
A single domain forest model
domains. Creating a regional domain model
reduces administrative complexity
design involves identifying what domain is the
by providing the following
forest root domain and determining the
number of additional domains that are
advantages:

Any domain controller can


authenticate any user in the forest.
All domain controllers can be global
catalogs, so you do not need to plan
for global catalog server placement.

In a single domain forest, all


directory data is replicated to all
geographic locations that host

required to meet your replication


requirements.
**If your organization includes groups that
require data isolation or service isolation from
other groups in the organization, create a
separate forest for these groups. Domains do
not provide data isolation or service isolation.

Domains and Tree


Forest Root Domain
Separate Tree

treyresearch.net
proseware.com
Child domain

antarctica.treyresearch.net

Designing AD Infrastructure
Scenario 2:
company name: Tatamotors.com
line of business: automobile manufacturer
factory in 1 place, head office in the other, retails outlets in 5 places.
1000 employees
- 600 in factory Gujrat
- 150 in head office Bangalore
- 50 in each retail outlet - 1 in GJ, 1 in Bangalore, 1 in Hubli and 2
Maharastra
Solution: Stage 1
Lets start with datacentre in the same physical location as the factory.
We start by building FOREST named Tatamotors.com
Root Domain Tatamotors.com
For a domain to be created we should have atleast 1 DC - we promote it.
Created 1000 users and add computer accounts for all users.

LAB1:
Create a forest, domain by promoting the 1st DC in the forest.
Create 2 user accounts under one OU
Create 2 security groups
Add 1 users to the 1 groups, do it for both users.

Requirements for Joining a


Computer to the Domain
A computer object must exist in the
directory service
You must have permissions to the
computer object that allow you to
join a computer to it
You must be a member of the local
Administrators group on the
computer to change its domain or
workgroup membership

Join a Computer to the


From the System Properties dialog box or
Domain
window

Prompted for domain credentials


Requires restart

Problem statement
All 1000 users querying and authenticating against one servers, adds to
much load on the server.
slower response
NO response because the server may have become unresponsive.

Business impact when the single DC is rebooting or is down for maintenance


or is permanently offline.

Solution: Stage 2
1000 users and 1000 computers may be too much load for 1 DC, so you
decide to add 1 more DCs to support user authentication, ldap queries etc.
High availability of Active Directory services. 2nd DC available if one of the DC
is down.
New DCs should have the same data as the 1st one, hence AD replication
was born.
Now any DC can authenticate users, service ldap or lsa request. This makes
the DCs in a domain to share load, NLB NOT reqd. to do load balancing.
LAB2
Promote 2nd DC in same domain
Create user in DC 1 and see how it replicates to 2nd DC
Change a user attribute on DC 2, and see how that change gets replicated to
DC 1
Disconnect one DC, and check if we are still able to authenticate.

Domain Controllers
Servers that perform the AD DS role
Host the Active Directory database (NTDS.DIT)
and SYSVOL
Replicated between domain controllers
Kerberos Key Distribution Center (KDC) service:
authentication
Other Active Directory services
Best practices
Available: at least two in a domain
Secure: Server Core, Read-only domain
controllers (RODCs)

The Active Directory Data Store


%systemroot%\NTDS\ntds.dit
Logical partitions

Domain naming context


Schema
Configuration
Global catalog (aka Partial Attribute Set)
DNS (application partitions)

SYSVOL
%systemroot%\SYSVOL
Logon scripts
Policies
NTDS.DIT

Schema
Schema
Configuration
Configuration
*Domain*
*Domain*
DNS
DNS
PAS
PAS

Replication
Multimaster replication
Objects and attributes in the database
Contents of SYSVOL are replicated

Several components work to create an efficient


and robust replication topology and to replicate
granular changes to AD
The Configuration partition of the database
stores information about sites, network topology,
DC1
DC3
and replication
DC2

Functional Level
Domain functional levels
Forest functional levels
New functionality requires that domain controllers are
running a particular version of Windows
Windows 2000
Windows Server 2003
Windows Server 2008

Cannot raise functional level


while DCs are running previous
versions of Windows
Cannot add DCs running
previous versions of Windows
after raising functional level

Group Type
Distribution groups
Used only with e-mail applications
Not security-enabled (no SID);
cannot be given permissions

Security groups
Security principal with a SID;
can be given permissions
Can also be e-mail enabled

Group Scope
Four group scopes
Local
Global
Domain Local
Universal

Characteristics that distinguish each scope


Replication. Where are the group and its membership
stored?
Membership. What types of objects, from which domains,
can be members of the group?
Availability (Scope). Where can the group be used? In
what scopes of groups can the group be a member? Can
the group be added to an ACL?

Problem Statement
All DCs are in datacentre in Gujarat.
users in the same physical site factory - see faster user authentication, group
policy application, file server access.
users in offices in Karnataka and Maharashtra see slow responses from DCs,
this is purely because of network latency. The head office and retails outlets
are connected to the datacentre using slow link.
All account management request needs to be sent to the head office like
user creation, password reset, unlocking the account, configuring security
policy for computer in one office etc.

To solve this issue, we can do the following:


Create the logical topology in AD to match the physical topology.
Create 3 AD sites - Gujarat, Bangalore, Mumbai
Move the 3 DCs to 3 different sites.
Now in order to direct the computers in Bangalore head office to the dc in
Bangalore site, you add the details of the network subnets in Bangalore
office in AD > associate the subnet to the Bangalore site.
This configuration tells AD and the domain computers, to which AD site the
computer belongs and makes the computer send most of its auth and ldap
request to the DC in its associated site.
Now users do not face delay is authentication, GPO access and ldap queries.
2 physical sites in karnataka but just one logical AD site in bangalore - u can
make the subnets in hubli and bangalore to map to bangalore site, this will
make the bangalore and hubli computers utilize DC in bangalore and not go
to far of DCs in Gujrat and Mumbai.
In case the local site DC if offline the auth and other request will be sent to
other DCs in domain.

The sites are connected to each other using site links.


Cost associated to sitelink to tell AD and domain services the best possible
route to take for authentication and resource access.

Scenario 3
A business may start with just automobiles business.
2 wheeler business
4 wheeler business
Domain structure:
Contoso.com (root domain)
Bikes.contoso.com - child domain - contains all users,
workstation and server accounts that are a part of 2 wheelers
auto business division under this company.
Cars.contoso.com - child domain - contains all users,
workstation and server accounts that are a part of the 4 wheelers
auto business division under this company.

Company decides to start a new Steel business, they may want to give it
a different brand name and not use the same contoso.com namespace.
- New Domain Tree in the same forest: Contososteel.net

All the above domains since are in the same forest have a 2-way
transitive trust with each other.

Then the Contoso groups decided to acquire a new finance company Finserve.com
Since this business is not closely related to the automobiles business, they
may decide to keep its IT infra separate. This may also happen that the
finance company already had a successfully running business and we do not
want to loose their Goodwill.
We keep the forest structure on the finance company as it, but just created a
TRUST between the finserve.com forest and contoso.com forest. This trust
helps us to access resources across each other.

Trust Relationships

Extends concept of trusted identity store to another domain


Trusting domain (with the resource) trusts the identity store and
authentication services of the trusted domain
A trusted user can authenticate to, and be given access to resources in, the
trusting domain
Within a forest, each domain trusts all other domains
Trust relationships can be established with external domains
Trust

Trusts enable users to:


Access resources in domains other than the domain where their user
account is configured.
Log on to computers that are members of domains other than the domain
where the user account is configured.

Trusted domain

Trusting domain

Shortcut trust A shortcut trust must be explicitly created by a systems


administrator between two domains in a forest. This trust is used to improve user
logon times, which can be slow when two domains are logically distant from each
other in a forest or tree hierarchy. The trust is transitive and can be one-way or
two-way.
External trust An external trust must be explicitly created by a systems
administrator between Windows Server 2003 domains that are in different forests,
or between a Windows Server 2003 domain and a domain whose domain controller
is running Windows NT 4 or earlier. This trust is used when users need access to
resources located in a Windows NT 4 domain or in a domain located within a
separate forest, which cannot be joined by a forest trust. The trust is nontransitive
and can be one- or two-way.

Forest trust A forest trust must be explicitly created by a systems


administrator between two forest root domains. This trust allows all domains in
one forest to transitively trust all domains in another forest. A forest trust is not
transitive across three or more forests. For example, forest A trusts forest B and
forest B trusts forest C. There is no trust relationship between forest A and forest
C. The trust is transitive between two forests only and can be one-way or two-way.
Forest trusts are only available when the forest is at the Windows Server 2003
functional level.

Realm trust A realm trust must be explicitly created by a systems


administrator between a nonWindows Kerberos realm and a Windows Server
2003 domain. This trust provides interoperability between the Windows Server

Understand the Global Catalog

Schema
Schema
Configuration
Configuration
Domain
Domain AA

Schema
Schema

Global catalog hosts a


partial attribute set
(PAS) for other
domains in the forest
Supports queries for
objects throughout the
forest

Configuration
Configuration
Schema
Schema

Domain
Domain A
A

Configuration
Configuration

Domain
Domain B
B

Domain
Domain B
B

Global
Global Catalog
Catalog
Server
Server
Schema
Schema
Configuration
Configuration
Domain
Domain B
B

Global Catalog Functions


It enables a user to log on to a network by providing universal
group membership information to a domain controller when a logon
process is initiated.
It enables finding directory information regardless of which domain
in the forest actually contains the data.

Operations Master Roles


Forest-wide
Domain naming: adds/removes domains to/from the forest
Schema: makes changes to the schema

Domain-wide
RID: provides pools of RIDs to DCs, which use them for SIDs
Infrastructure: tracks changes to objects in other domains that
are members of groups in this domain
PDC: plays several very important roles

Emulates a Primary Domain Controller (PDC): compatibility


Special password update handling
Default target for Group Policy updates
Master time source for domain
Domain master browser

Identify Operations Masters


User interface tools
PDC Emulator: Active Directory Users And Computers
RID: Active Directory Users And Computers
Infrastructure: Active Directory Users And Computers
Schema: Active Directory Schema
Domain Naming: Active Directory Domains and Trusts

Command line tools


NTDSUtil
DCDiag
netdom query fsmo

LAB3

Create a new child domain, with one DC only


Explore the trust between the domain
Check for FSMO roles, move PDC to a different DC in domain.
Promote it as Global Catalog

Authentication and Authorization

Authentication
Authentication
Authentication is
is the
the process
process that
that verifies
verifies a
a users
users identity
identity

Credentials: at least two components required


Username

Secret, for example, password

Two types of authentication


Local (interactive) Logon
authentication for logon to the
local computer

Remote (network) logon


authentication for access to
resources on another
computer

Authentication and
Authorization
The
A
The system
system creates
creates a
a
A user
user presents
presents credentials
credentials
that
that are
are authenticated
authenticated
using
using the
the information
information
stored
stored with
with
the
the users
users
identity
identity

security
security token
token that
that
represents
represents the
the user
user with
with the
the
users
users SID
SID and
and all
all related
related
group
group SIDs
SIDs

A
A resource
resource is
is secured
secured with
with
an
an access
access control
control list
list (ACL):
(ACL):
permissions
permissions that
that pair
pair a
a SID
SID
with
with a
a level
level of
of access
access

The
The users
users security
security token
token is
is
compared
compared with
with the
the ACL
ACL of
of
the
the resource
resource to
to authorize
authorize aa
requested
requested level
level of
of access
access

Access Tokens
Users
Users Access
Access Token
Token
User SID
Member Group
SIDs
Privileges
(user rights)
Other access
information

Security Descriptors, ACLs and ACEs

Security
Security Descriptor
System ACL
(SACL)
Discretionary ACL
(DACL or ACL)
ACE
Trustee (SID)
Access Mask
ACE
Trustee (SID)
Access Mask

Access Management Without


Groups

Identity

Access Management

Resource

Groups Add Manageability

Identity

Group
Access Management

Resource

Few important features of Kerberos authentication


- Tickets based authentication protocol
- Provides SSO, Credential entered by user only once
- Prevents man in the middle attack, by preventing replay of credential
- Ensures only the resource for which the ticket can consume the ticket and
nobody else

NTLM
1. (Interactive authentication only) A user accesses a client computer and provides
a domain name, user name, and password. The client computes a cryptographic
hash of the password and discards the actual password.
2. The client sends the user name to the server (in plaintext).
3. The server generates a 16-byte random number, called a challenge or nonce,
and sends it to the client.
4. The client encrypts this challenge with the hash of the user's password and
returns the result to the server. This is called the response.
5. The server sends the following three items to the domain controller:
User name
Challenge sent to the client
Response received from the client

6. The domain controller uses the user name to retrieve the hash of the user's
password from the Security Account Manager database. It uses this password
hash to encrypt the challenge.
7. The domain controller compares the encrypted challenge it computed (in step 6)
to the response computed by the client (in step 4). If they are identical,
authentication is successful.

Problem statement:
Company wants to have a common location for all the policy / design
documents etc.
They need to give all users read access to the data but the management
team also needs write access.
You also want to audit who is accessing the data and check if some manager
is deleting important content too.

Solution: Stage 3
Make one domain joined server as Fileserver
Share data on it and grant access as per requirements.

LAB2
Make one of the domain joined servers as fileserver.
Share a data folder
Give read access to one group and full control to the other groups
Deny to one user
Access share as all the 3 users and observe behaviour
Demo
Netmon trace showing kerberos authentication and authorization.

Group Policy
Infrastructure

Module Overview

Understand Group Policy


Implement GPOs
A Deeper Look at Settings and
GPOs
Manage Group Policy Scope
Group Policy Processing
Troubleshoot Policy Application
Delegate the Support of
Computers

Understand Group Policy


What is Configuration Management?
Policy Settings (Also Known as
Policies)
Group Policy Objects
GPO Scope
Group Policy Refresh

What Is Configuration Management?


A centralized approach to applying one or more changes
to one or more users or computers
Setting: Definition of a change or configuration
Scope: Definition of the user(s) or computer(s) to which
the change applies
Application: A mechanism that applies the setting to users
and computers within the scope
Group Policy: The framework for configuration
management in an AD DS domain
Setting
Scope
Application
Tools for management, configuration, and troubleshooting

Policy Settings (Also Known as


Policies)
The granular definition of a change or configuration
Prevent access to registry-editing tools
Rename the Administrator account

Divided between
User Configuration ("user policies")
Computer Configuration
("computer policies")

Define a setting
Not configured (default)
Enabled
Disabled

Read explanatory text


Test all settings

Group Policy Objects


The container for one or more policy
settings
Managed with the Group Policy
Management console
(GPMC)
Group Policy Objects container

Edited with the Group Policy


Management Editor
(GPME)

GPO Scope
Scope. Definition of objects (users or computers) to
which GPO applies
GPO link. GPO can be linked to site, domain, or
organizational unit (OU) (SDOU)
GPO can be linked to multiple site(s) or OU(s)
GPO link(s) define maximum scope of GPO

Security group filtering


Apply or deny application of GPO to members of global security
group
Filter application of scope of GPO within its link scope

WMI filtering
Refine scope of GPO within link based on WMI query

Preference targeting

Group Policy Refresh


When GPOs and their settings are applied
Computer Configuration
Startup
Every 90-120 minutes
Triggered: GPUpdate command

User Configuration
Logon
Every 90-120 minutes
Triggered: GPUpdate command

Implement GPOs
Local GPOs
Domain-Based GPOs
Demonstration: Create, Link, and Edit
GPOs
GPO Storage
Demonstration: Policy Settings

Local GPOs
Apply before domain-based GPOs
Any setting specified by a domain-based GPO will
override the setting specified by the local GPOs.

Local GPO
One local GPO in Windows 2000, Windows XP,
Windows Server 2003
Multiple local GPOs in Windows Vista and later
Local GPO: Computer settings and settings for all users
Administrators GPO: Settings for users in
Administrators
Non-administrators GPO: Settings for users not in
Admins
Per-user GPO: Settings for a specific user

If domain members can be centrally


managed using domain-linked GPOs, in what
scenarios might local GPOs be used?

Domain-Based GPOs
Created in Active Directory, stored on
domain controllers
Two default GPOs
Default Domain Policy
Define account policies for the domain:
Password, account lockout, and Kerberos
policies

Default Domain Controllers Policy


Define auditing policies for domain
controllers and Active Directory

Group Policy Processing Order


GPO1
GPO1
Local
Local Group
Group

GPO2
GPO2
Sit
e
GPO3
GPO3
GPO4
GPO4
Doma
in
GPO5
GPO5
OU

OU
OU

OU
OU

Lab Group Policy


Create an OU called Test and move one
Windows 7 client machine to that OU.
Open Group Policy Management Console
and create a GPO (ControlPanelGPO) and
link it to the Test OU.
Edit the GPO and enable the setting to
remove control panel from the start menu.
Log on to the Windows 7 client machine
and check the start menu. MAGIC!!

AD Certificate Services
Certificates

Different Types of certificates.


Self Signed certificates

Certificate Signed by an internal


Enterprise CA

Certificate Signed by a Public CA

Signed by a CA which is internal to your


Organisation / AD forest and trusted by the Signed by a Public CA who is a trusted authority
Signed by itself i.e. you are saying to
identities in the forest i.e. you are saying to known to all over the internet i.e. you are saying
your clients "trust me - I am who I say I your clients "trust me - Enterprise CA agrees, to your clients "trust me - Verisign agrees, I am
am."
I am who I say I am."
who I say I am."
By default, Not trusted by all clients.
All trusted identities within the AD forest
All Windows computers with regular updates and
Certificate has to be explicitly added to automatically trust the certificate signed my internet connectivity will trust the certificates
the trusted certificate store.
Enterprise CA
issues by well known public CA
Certificate can be revoked and CRL published Certificate can be revoked and information about
NO way to revoke certificate, hence if
in AD store or webserver, accessible
the revoked certificate is published over the
compromised may cause issues
internally from corpnet.
internet.

certificates can be created using


utilities Makecert.exe or Apps like IIS

Client certificate can be requested using


MMC, Web enrollment, Autoenrollment,
Using .req file etc.

Public Key infrastructure need to be setup


Public Key infrastructure not required and managed by the Domain/CA admins. The
but very difficult to manage large
CAs, CRL publishing, certificate issuance and
number of self signed certificates
revokation to me managed by CA admins.
Used for testing

Used for Intranet scenarios

Client certificate can be requested using request


file or providing details to the Public CA about
the Certificate we want issued.

PKI not managed by domain admins but


managed by the Public CA vendor
used for services exposed to the internet

Usage of certificates:

- Encrypted File system


- SSL / TLS communication i.e. Securing communication
with a HTTPS website, Server Authentication
- Smart Card logon
- Client authentication
- IPSEC

AD Federation Service
An enterprise claims provider for claims-based applications
Provide an SSO experience across multiple claims-aware applications.
Provide access to a claims-aware application to users in the same or
other organizations.
Across forest with no forest trust
Across identity stores via another 3rd party STS.
Reduce concern about developers of custom applications making
processor-intensive authentication requests that unexpectedly burden
an organizations directory services.
Reduces the need for duplicate accounts and other credential
management overhead by enabling federated SSO across organizations,
platforms, and applications.
Active Directory Federation Services (AD FS) Overview
http://
social.technet.microsoft.com/wiki/contents/articles/1011.active-directory-f
ederation-services-ad-fs-overview.aspx

ADFS Scenario:

A manufacturer comes up with a webportal using which a wholesaler / retailer


company can place orders.

Before a purchasers from different company can place orders on the


manufacturing website, they have to authenticate.
If the purchasers are to be given a SSO experience when accessing the
manufacturing webportal. Manufacturer need to create users account with the
same name and password as in purchasers own domain.
- Maintaining the users across different forest every difficult.
Both companies do not want the forest to Trust each other, and expose their
forest to the other.
Solution:
ADFS needed on both the manufacturing and purchasers side.
A federation trust required between the ADFS servers based on certificate,
one time setup. NO communication required between the ADFS servers.
Now purchasers can access the manufacturing portal, using their local
domain credentials. The purchasers are authenticated by their local DCs only.
Once setup, very easy to setup and manage.
**Most of the cloud solutions available, use ADFS like service to provide
authetication and SSO experience.

ADFS With Office 365:

También podría gustarte