Directory Enabled Networking
with Active Directory
Austin Wilson
Microsoft Corporation
What is Directory Enabled
Networking?
 Policy-based management of network
resources and provisioning of services
 Directory is central as it serves to bind
information about users, applications and
network infrastructure
 It is the comprehensive term that includes all
technologies needed to make directorybased control of networks a reality
 Directory enabled networking and policybased networking are synonymous
DEN vs. Directory Enabled
Networking
 DEN - the standard - is distinct from
directory enabled networking
 Directory enabled networking is more
than just DEN
 DEN provides a foundation
 Information model
 Directory schema (LDAP)
 Many implementation issues and other
standards for directory-enabled
networking are outside the scope of DEN
Overview
Vision of Directory Enabled Networking
 Harness the power of directory services
for network management and services
 Policy-based networking: simpler quality
of service, configuration, and security
administration
 Common information model and schema
for network elements and services
 Interoperable network services and
management solutions
Overview
Vision of Directory Enabled Networking
Management
App B
Management
App A
Directory
Service
Management
App C
Interoperability provided via Directory Service
Overview
Vision of Directory Enabled Networking
Directory
Service
Server
Switch
Firewall
ERP DB
Overview
Directory Enabled Networks
 Logical division of labor
 Directory provides point of resource
discovery and defines bindings
 Networks provide end-to-end connectivity
 Policy-based network management
 Enables unification of network services
and management applications
 Defines and distributes policy and
bindings
 Enables personalized network services
Standards
DEN Progress Report
 DEN Ad Hoc Working Group formed: Dec 97
 DEN spec finished and submitted to DMTF
for further development: Sep 98
 DEN framework is an integral part of
Common Information Model (CIM)
 DEN spec incorporated into CIM model in
phases
 Physical model integrated in CIM v2.1: Oct 98
(application, device, system and physical)
 Logical model integrated in CIM v2.2: Jun 99
(network and services)
 Policy model: work-in-progress jointly between
DMTF/IETF
Applications
Dir Enabled Networking at Work
 Physical infrastructure management
 Static configuration of network devices
 Asset tracking
 Device and topology discovery
 Performance and fault management
 Network service management
 Quality of Service (QoS)
 Remote access and VPN
 IP security
 IP address management
 Firewalls
QoS (with RSVP and DiffServ)
NetMeeting
Client
Policy: “Yes, you may have Priority Gold”
or “No, you may not have Priority now”
Service Level Agreement:
PHB = EF; TokenBucket = TB2
(e.g. equiv to virtual leased line)
Data Store
RSVP-enabled
campus network
Policy
server
Differentiated
service
network(s)
RSVP-enabled
campus network
NetMeeting
Client
Client: “May I have Priority, Please”
VPN (L2TP/IPSec Voluntary Tunnel)
Win2000
MS Active
Directory
Server
Internet
Auth/Authz
Server
NAS
Edge
Router
Edge
Router
Radius
proxy
Legend:
IPSec
L2TP
MS IAS
Server
MS Active
Directory
Server
Architecture
Policy-based Networking
Policy
Repository
LDAP
Directory
Policy
Management
Console
LDAP
Policy
Proxy
SNMP
Policy
Decision
Point
COPS
Policy Enforcement Points
Policy
Decision
Point
Architecture Components
Directory
 Directory stores a variety of information
 User data
 Authentication and access rights
 User profiles
 Infrastructure data
 Static/start-up configuration for devices (e.g.,
routers, switches)
 Server information (e.g., name server)
 Policies
 Conditions, actions, policy rules
Architecture Components
Policy Management Console
 Policies express business rules
 Discipline-specific, perhaps even device-specific
 QoS policies, remote access policies, IP security
policies, firewall policies, etc.
 Policy console
 Provides an abstraction of rules to create policies
 Used to define and edit policies
 Validates policies
 When appropriate, the policy UI is unified with the
UI that manages the entities that are the subjects
of the policy (e.g., users, computers, devices)
Architecture Components
Policy Decision Point
 PDP generally takes the form of policy servers
 Makes policy selection, gets policy from directory
 Makes policy decisions
 Detects and resolves policy conflicts
 Distributes policy actions based on its decision to
enforcement points



Access/deny
Traffic shaping parameters for a QoS policy
Address filters for a firewall policy
 May propagate policies to other servers
 Monitors usage and effectiveness of policy
enforcement
Architecture Components
Policy Enforcement Point
 Network node in the direct path of traffic
flow (router, switch, remote access
server, firewall)
 Policy enforcement point
 Requests policy-based decisions
 Optionally caches policy decisions for
future use
 Processes traffic per policy decision
 Relays events to policy decision point
Architecture Variations
Two-tiered Architecture
Policy
Repository
LDAP
Directory
LDAP
Packets in
Packets out
Policy Decision Point &
Policy Enforcement Point
Policy
Management
Console
Architecture Variations
Two-tiered Architecture
 Device considerations
 Requires smarter network devices (LDAP enabled)
 Direct LDAP interactions with directory
 Firewall/security
 LDAP typically not allowed across firewall
 Need for encryption on some attributes can force
large number of SSL/TLS connections
 Global knowledge
 Lacks global view of network state to make
decisions like simultaneous usage control
 Loading
 Increased directory load
 Faster decision making and traffic processing
Architecture Variations
Three-tiered Architecture
Policy
Repository
LDAP
Directory
LDAP
Policy
Server
COPS
Packets in
Packets out
Policy Enforcement Point
Policy
Management
Console
Architecture Variations
Three-tiered Architecture
 Device considerations
 Network devices can be simple
 Devices can be schema independent
 Firewall/security
 Servers typically in data center, can be secured
 Existing PEP-PDP protocols are “firewall friendly”
(DHCP, RADIUS, COPS)
 Global knowledge
 Has global view of network state to make decisions
like simultaneous usage control
 Loading
 Lower directory load – less servers than devices
 Slower remoted decision making
Architecture
Additional Considerations
 Policy distribution protocols (SNMP, COPS,
RADIUS)
 Support for legacy devices
 Use policy proxy to translate policy actions for
legacy devices
 End-host participation
 Dynamic state information
 Need data store for volatile information
 Missing LDAP features
 Change notification
 Multiple-object transactions
Active Directory
Data and Policy Store
 Salient features:
 LDAP v3: for interoperability
 Tightly integrated security (Kerberos)
 DNS: backbone, integrated
 Hierarchical namespace
 Multi-master replication and updates
 Dynamically extensible schema
 Global Catalog for efficient search
 Directory synch services
 Scale: millions of objects
 Programming and scripting API (ADSI)
Microsoft Active Directory
Windows Users
• Account info
• Privileges
• Profiles
• Policy
Other
Directories
• White pages
• E-Commerce
Other NOS
• User registry
• Security
• Policy
E-Mail Servers
• Mailbox info
• Address book
Active
Directory
Windows Clients
• Mgmt profile
• Network info
• Policy
Windows Servers
• Mgmt profile
• Network info
• Services
• Printers
• File shares
• Policy
Network Devices
• Configuration
• QoS policy
• Security policy
Management
Focal Point For:
• Users & resources
• Security
• Delegation
• Policy
Applications
• Server config
• Single Sign-On
• App-specific
directory info
• Policy
Internet
Firewall Services
• Configuration
• Security Policy
• VPN policy
Group Policy
Policy Decision Point
 Group Policy
 Extensible policy framework to apply policy to
groups of computers/users
 Policies stored in Group Policy Object (GPO) in
Active Directory
 GPO can be bound to AD containers: Sites,
Domains, OUs


Inheritance order: S,D,OU
Scope further filtered by security groups
 APIs for services to invoke policy selection
process (GetGPOList)
 Can be used to push device configurations
from Active Directory
Policy Enforcement Point
 Alternatives
 Host network gear on Windows 2000 when
possible to take advantage of full platform
functionality
 PBX devices, VoIP gateway/gatekeeper
 Use embedded Windows 2000 as control
OS on devices if possible
 Implement secure LDAP client in device
OS starting from Open Source version
Summary
 DEN specification from the DMTF is not
yet final – standards are a lengthy and
laborious process
 Active Directory services are available
and can be leveraged for addressing
network management needs today
 Compelling value proposition for endcustomers – manageability and reduced
TCO of network infrastructures
 Enterprises are planning for deployment
of directory-enabled networks. Integrate
with Active Directory services now!