Active Directory Application Mode Introduction And Usage Scenarios

Active Directory Application Mode: Introduction And Usage Scenarios

Agenda l l l Need for ADAM Usage scenarios Architecture Tech drilldown Summary

Active Directory, Circa 1997 Active Directory Centralized management LDAP, Kerberos HR/ERP application Automated provisioning Policy-based admin, single-sign-on, for Windows-based resources l “Enterprise directory” + “NOS directory” Ø Ø Repository of consolidated information Centralized management, provisioning Single-sign-on Data re-used by many applications Portal application Generic app usinglesign-on Whitepages/ GAL

Where We Are Today Centralized management (Non-existent) Ad-hoc sync LDAP e. Directory LDAP HR/ERP app Database Generic dump Portal application Generic LDAP-based app i. Planet LDAP Whitepages i. Planet Policy and SSO for Windows MAPI Active Directory l l Directories deployed per-app; little re-use Provisioning, sync are ad-hoc Outlook/ Exchange

The Solution DS-enabled app Third-party DS Centralized identity management UDDI Web Service DS App DS HR/ERP app MIIS 2003 ADAM App DS DS-enabled app Database Metadirectory access sync l ADAM App DS Active Directory Infrastructure Directory Integrated product suite for full range of usage scenarios DS-enabled app

Agenda l l Need for ADAM Usage scenarios 1. App-specific local directory n 2. 3. l l l DEMO Developer prototyping DS-enabled app Supporting legacy applications Architecture Tech drilldown Summary

ADAM Usage Scenarios 1. App-specific local directory Web portal Store/ retrieve data ADAM Authentication Client Server l Example: Web portal with personalization Ø Ø Infrastructure Active Directory Store personalization info in ADAM Use AD for authentication

Demo l l l Install ADAM Extend schema Import data Take well-behaved LDAP app and retarget to ADAM Retrieve data imported Easy to install, configure and use

ADAM Usage Scenarios App-specific local directory – factoring identity Web portal Store/ retrieve data User (right) and “shadow” (left) AD/AM Client Server Data specific to portal app l l Infrastructure Directory Data shared by multiple apps Store app data without extending infrastructure directory App data keyed off identifier from infra directory

ADAM Usage Scenarios App-specific local directory – arbitrary catalog Web portal Store/ retrieve data MIIS 2003 (optional) AD/AM Client Server l MIIS 2003 optional, for provisioning Ø Ø Ø l Infrastructure Directory Provision objects in ADAM as objects added/removed from infrastructure AD Publish select data from ADAM objects into infrastructure AD Create aggregate view of object in AD/AM Abstract infrastructure environment (domains, forests) from developer

ADAM Usage Scenarios App-specific local directory – domain independent LDAP Web portal Client MUD (Authentication) RD RD RD Windows NT 4. 0 domains Can be used before Infrastructure AD deployed Ø Ø l MUD ADAM Server l MUD Just need Windows® security infrastructure Can be NT 4. 0 domains, or local security database on a workgroup machine Peace of mind for app developer Ø App deployment not blocked

ADAM Usage Scenarios Developer Prototyping DEA l Very low barrier to entry Ø Ø l Install ADAM on Windows XP® No server or domain controller required No OS reinstall required to wipe schema Multiple instances means easy to follow different design paths while prototyping When done experimenting, app easily ported to Active Directory™ Ø Ø Ø Port to domain partition/global catalog Port to application partition (WS 2003) … or just leave it as an ADAM app

ADAM Usage Scenarios Supporting legacy applications Store/ retrieve data Legacy LDAP app MIIS 2003 (transform data) ADAM Auth. N Infrastructure Active Directory l l MIIS 2003 can transform data in representation expected by legacy app Examples Ø Ø O=, C= naming Specific OU structure expected by app

What ADAM Is Not l Not usable by Exchange 2000 Ø Ø Ø l Not a Windows logon server Ø l Exchange requires security principals Exchange requires MAPI protocol support Factoring application data and infrastructure data is part of philosophy for next generation Not a KDC (although can Kerberos authenticate if pass creds of AD-based user) AD/AM does not diminish the need for NOS Active directory!

When To Use ADAM l Database versus Directory Ø Ø l AD versus ADAM Ø l AD – for identity management, security enabled apps (Exchange) AD App partitions versus ADAM Ø Ø l Highly volatile, transactional data -> Database Store once and retrieve many times ->Directory Globally interesting data versus local data Central Management versus autonomy App forest versus ADAM Ø Ø Users need network presence, constrained delegation – App forest Simple authentication support – ADAM

Agenda l l l Need for ADAM Usage scenarios Architecture Ø Ø Ø l l Components Capabilities Platforms support Tech drilldown Summary

Architecture Infrastructure Active Directory in Application Mode LSASS ADAM LDAP MAPI REPL KDC Lanman SAM DSA dependencies DNS l l LDAP REPL DSA (traditional AD minus infrastructure mgmt) FRS Same code as Active Directory in WS 2003 – just a new mode Programming model, admin tools virtually identical to Infrastructure AD – familiarity means skill sets easily transferable

Just A New Mode ! l l l Same programming model as AD Replication and Administration model similar to AD Same store as in AD – same storage management too Ø l DIT file and Log file layout is same Same as WS 2003 AD in every other way except Ø Ø No locator via DNS SRV records – instead uses Service Connection Points No MAPI protocol support

New Capabilities l Simple install and setup Ø Ø Ø l l No DCPROMO Wizard with defaults, just “Next” through Does not turn machine into DC Restart or reinstall without reboot Multiple instances on single machine Each instance with own schema X. 500 -style O=, C= naming

Platforms Support l Windows Server 2003 Ø l Windows XP Ø l Standard, Enterprise and Datacenter Professional 32 -bit and 64 -bit support

Agenda l l Need for ADAM Usage scenarios Architecture Tech drilldown Ø Ø Ø l New concepts Default configuration Security Replication Administration experience Summary

New Concepts l Instance Ø Ø Identified by name and ports Name ties the files, service, registry and ports together Ports: configurable LDAP and SSL port Event log § l One per instance for application data; uses the shared security log for security logging Configuration set Ø collection of instances that replicate with one another – they share Configuration and schema partitions

Default Configuration Schema, partitions and root. DSE l Fully extensible schema Ø Ø Default schema much smaller (~30 objects and <200 attributes) Ships LDIF files to extend schema for § Ø l Ø App partitions created via setup or later Any object class and naming scheme root. DSE changes Ø l Auxiliary classes, schema activation and deactivation same as AD Configuration and schema partitions only Ø l RFC compliance, e. g. , Inet. Org. Person support Domain attributes pruned, token. Groups added supported. Capabilities Ø New OID for ADAM: 1. 2. 840. 113556. 1. 4. 1851

Security Authentication l Windows security principals Ø Ø l ADAM security principals Ø Ø l SASL binds; simple binds through proxy Authentication: get token on bind from Windows and augmented with ADAM groups the Windows principal (SID) is a member of, in all NCs Users and groups Built-in groups (administrators, readers, users) Scope limited to application partition ADAM users: any class, have SID, Simple Bind only, account and password policy Windows principal needed to be admin in config container

Security Bind proxy to Windows principals 1. Pass flat string 2. Get DN Web 3. Bind as DN, pwd portal 4. Access object data AD/AM Bind calls redirected Client Infrastructure Directory Server l Scenario benefits from consolidation of identities – only windows identity is used; ADAM DN is just a manifestation of Windows identity

Security Bind proxy to Windows principals l Proxy object in ADAM Ø Ø l Redirect bind calls to Windows Ø Ø l local manifestation of Windows object augmented with app-specific local data Single password experience by consolidating identity in AD - password not stored in ADAM Decommissioning is automatic No changes needed to the app Abstract infrastructure environment from developer (domains, forests) Works with any trusted domains and forests

Security Authorization l l Default ACLs made simple Authorization for ADAM objects same as AD Ø Ø l ACLs have SIDs from ADAM or Windows Tokens matched against ACLs to grant or deny access Applications can implement their own authorization scheme, same as with AD

Replication l Multi master replication Ø Ø l l Concept of sites, KCC same as AD Schedules can be set independent of other instances Ø Ø l l Same as AD Fully functional, updateable replicas Set replication schedules in ADSIEdit Repadmin tool available Replicas can host any subset of application partitions Can replicate between instances regardless of domain/workgroup or trusts

Administration Experience Tools l l Administration model similar to AD - familiar tools to do familiar tasks GUI tools Ø Ø Ø l l LDP ADSIEdit - new functionality to manage replication schedules Schema Manager Snap-in Command Line tools - Ntdsutil, LDIFDE, Dcdiag, Dsacls, Repadmin equivalents Backup and restore through ntbackup Ø Ø Ø Snapshot writer based backups System state backup not needed – store only Auth Restore, Create replica from media available

Administration Experience Centralized management l Easy to setup and manage “ADAM Farms” centrally much like SQL Server Ø Ø Installation, configuration geared for this Server consolidation § l l multiple instances and multiple partitions support Control services centrally through SMS Controlled deployment Ø Ø Ø ADAM registers SCP in AD (optional) DNS for load balancing with referrals Group policy controlled § service accounts, bind options can be controlled

Agenda l l l Need for ADAM Usage Scenarios Architecture Tech Drilldown Summary

ADAM As App Directory l l l Dedicated store for app data Standalone or replicated Independent of domain setup Local control and autonomy Schema and naming flexibility Everyone can have many!

Benefits Summary l Ease of deployment Ø Ø l Reduced infrastructure costs Ø Ø l Integration with Windows principals Increased flexibility Ø l Single directory technology Same admin model Increased security Ø l Install, reinstall, remove. NET Server and XP Pro platforms Install anywhere without affecting AD Reliability and scalability Ø Same as AD

© 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.