From donovanf's Office : AD

Active Directory Federation Services (ADFS) for ASP.NET 2.0 Developers

donovanf — Fri, 20 Jun 2008 01:48:00 GMT

This post is to inform you of a couple new screencasts on Channel9 hosted by Keith Brown. In these, Keith drills into the role AD FS can play in helping you architect/develop claims-based Web applications which offer their Internet users not only a Web SSO experience, but supports user access by federation partners as well. Both are much needed in today’s Web applications!

For some time now developers have built Web applications around a domain or application-based identity infrastructures to provide user access to their applications. In the domain-based Windows environment, Windows integrated authentication has worked its magic on the user’s behalf by extending their single, interactive authentication event to a host of applications and services providing the user with a single signon (SSO) experience. But, this has one catch, a domain-based identity infrastructure retains absolute authority over the identities within its domain and let’s no others in. It creates users and services and makes all the trust decisions for them within its borders, that is, within the firewall. However, as the business need for ubiquitous user access has evolved, the demand upon Web applications is to no longer only support users inside the firewall. Potentially, these same applications, or portions of them, need to now be accessed by vendors, partners or customers as well. How do you provide access for these users to applications built around the domain-based identity model? At the minimum, it infers additional user account management. Each one must have a domain-based identity inside the firewall. If this means hundreds or potentially thousands of additional user accounts, it’s a further burden on IT and helpdesk staff to manage password resets and provisioning/de-provisioning of accounts for those loosely affiliated with the organization.

Federation:

Active Directory Federation Services (AD FS), in Windows Server 2003 R2 and 2008, enables the cross-domain reach of your Web applications while preserving a Windows Integrated Authentication experience inside the firewall and providing a SSO experience across Web applications for those outside the firewall. Furthermore, AD FS makes additional user account management unnecessary because it provides an infrastructure for establishment of federation trust relationships with partner organizations. Due to the federation trust relationship, accounts from the partner’s domain can be trusted to have access to specific applications within your domain. Therefore, in a federated trust model, each organization continues to manage its own domain-based identities, but they can also securely project and accept these digital identities, including their associated access rights, into or from other partner organizations.

So what are the advantages of moving to this cross-domain, federation trust model for identities? First, from a SSO perspective, AD FS manages this for your AD FS enabled Web applications. AD FS maintains SSO for any Web application relying on it to broker authentication events via the pre-established federation trust relationships. After the user’s initial authentication, if they navigate to other AD FS enabled Web applications that are under the same federation trust, the user experiences SSO with these applications as well. Secondly, from an architect’s and developer’s perspective, with AD FS in the mix, you can design and build your applications with the intent that they may be accessed by anyone. Essentially, write the application once, but fully anticipate its use by users from multiple security domains – again, some from inside the firewall and others from outside. And, because AD FS is based on the open standard WS-Federation protocol, it can also broker access to your application from any non-Microsoft platform that implements WS-Federation. This further extends the reach of your federation-aware application.

The next logical question is, if you decouple the authentication event from the application, how does the application get the information it needs to make its access control decisions? As mentioned above, the cross-domain digital identities also can contain access rights, asserted in the form of claims that the application can consume. The application can use these claim values to enforce its internal access control decisions. A very handy technology for mapping access rights to roles is Windows Authorization Manager (AzMan). I’ve already discussed AzMan in previous blogs, but its role-based access control (RBAC) capabilities can be employed in the claims-based programming model that AD FS uses. Hence, the purpose of this blog. To introduce you to the Channel9 screencast series focusing on claims-based programming with AD FS, hosted by Keith Brown. Please follow the links below.

Enjoy!

Channel9 Screencasts:

Active Directory Federation Services (AD FS) Part 1 by Keith Brown
Active Directory Federation Services (AD FS) Part 2 by Keith Brown

.NET Programming with System.DirectoryServices.AccountManagement (SDS.AM)

donovanf — Thu, 15 May 2008 18:39:00 GMT

To fill out the trio of my System.DirectoryServices resource postings, I wanted to point you to an excellent MSDN Magazine article, "Look it Up: Managing Directory Security Principals in the .NET Framework 3.5," to learn about the System.DirectoryServices.AccountManagement namespace which is available in the .NET Framework 3.5. To whet your appetite, the authors, Joe Kaplan and Ethan Wilansky, state:

"This new namespace has three primary goals: to simplify principal management operations across the three directory platforms [Active Directory Domain Services (AD DS), Active Directory Lightweight Directory Services (AD LDS, formerly named ADAM) and the local Security Account Manager (SAM)], to make principal management operations consistent regardless of the underlying directory, and to provide reliable results for these operations so you are not required to know each and every one of the caveats and special cases.

By waiting a few years for the .NET landscape to gel, Microsoft has actually outdone its previous work in ADSI by providing an even better API for these features that takes advantage of .NET capabilities while also providing much better support for new directory platforms such as AD LDS."

Whereas SDS.P is for the pedal-to-metal LDAP developer and SDS.AD is for managing Active Directory components, SDS.AM is for the developer that needs to work with security principals, creating user accounts and groups, managing group memberships, simplified searching and more - this namespace is for you. A code sample accompanies the article so you can get right to work.

AzMan in Windows Vista? You bet! And “Longhorn” too!

donovanf — Thu, 05 Apr 2007 03:12:00 GMT

The fourth screencast in the AzMan series by Keith Brown is now available on Channel9. It is titled, “AzMan on Windows Server Code Name “Longhorn” and Windows Vista.” Yes, developers can continue to take advantage of a new featured AzMan on these next generation client and server platforms. The AzMan product group did a significant amount of work to bring you the following new features:

Support added for Microsoft SQL Server to also be a store for AzMan’s policy.
Support for business rule groups, that is, groups whose membership is determined at run-time by a script.
Support for custom object pickers, so that application administrators can use the AzMan MMC Snap-in for applications that use Active Directory Lightweight Directory Services (AD LDS, formerly named ADAM) or SQL user accounts.
Improvements were made to the API to simplify the programmer's need to perform commonly used queries and access checks.
LDAP queries no longer are limited to only user objects.
Additional events are recorded in the log if auditing is active.
Significant efficiencies were targeted and gained in this version of AzMan in relationship to loading the store, access check time and store creation time.

If you want to see the new AzMan in action, go to your Windows Vista machine, choose Run… and type azman.msc. Click on the Help icon in the Microsoft Management Console (MMC) for documentation on the above mentioned features. Keith highlights several of these enhancements in the screencast. For more resources on AzMan, please refer to my blog post "Windows Authorization Manager (AzMan): The Best Kept Secret..."

Enjoy!

.NET Programming with System.DirectoryServices.Protocols (SDS.P)

donovanf — Tue, 03 Apr 2007 01:27:00 GMT

In line with Ethan Wilansky’s previous white paper on System.DirectoryServices.ActiveDirectory (SDS.AD), I am pleased to announce his second white paper available on MSDN that highlights the .NET 2.0 System.DirectoryServices.Protocols (SDS.P) namespace. Also, as mentioned in my previous SDS.AD blog post, with the advent of SDS.AD and SDS.P in .NET 2.0, directory services programming for the managed code programmer has come of age. These rich programming APIs bring to the .NET platform the ability to manage a directory that previously was only available through Active Directory Services Interface (ADSI) scripting, C++ or the LDAP API. This white paper exposes some of the richness of the SDS.P programming model and its capabilities.

Staying true to the Directory Services namespaces design principles, SDS.P introduces a low barrier to entry and self documenting object model as well. SDS.P programmers will again see that they can learn the API quickly. The design goals for SDS.P were to target high performance, cover 100% of the scenarios and be easy to use. The object model is connection based with a request and response object. SDS.P is for server-side directory developers who seek the maximum control and power over the directory. SDS.P supports advanced directory operations like fast concurrent bind, certificate based authentication, transport layer security and much more. So don’t hesitate – read this exceptional paper and try out the sample code download.

Following are the scenarios exposed in the sample code: Enjoy!

Common management tasks
CreateUsers server_or_domain_name targetOu numUsers
AddObject server_or_domain_name dn dirClassType
AddAttribute server_or_domain_name dn attributeName attributeValue
AddAttribute2 server_or_domain_name dn attributeName attributeValue
AddAttributeUri server_or_domain_name dn attributeName attributeUriValue
AddMVAttribStrings server_or_domain_name dn attribName "attribVal1,...attribValN"
DeleteAttribute server_or_domain_name dn attributeName
EnableAccount server_or_domain_name dn
DeleteObject server_or_domain_name dn
MoveRenameObject server_or_domain_name originalDn newParentDn objectName
Search operations
SimpleSearch server_or_domain_name startingDn
AttributeSearch server_or_domain_name startingDn "attribName1,...attribNameN"
TokenGroupsSearch server_or_domain_name DnofUserAccount
PagedSearch server_or_domain_name startingDn numbericPageSize
AsyncSearch server_or_domain_name startingDn
Asq server_or_domain_name groupDn
Vlv server_or_domain_name startingDn maxNumberOfEntries nameToSearch
Advanced authentication operations
Sslbind fullyQualifiedHostName:sslPort userName password
FastConBind server_or_domain_name user1 pword1 user2 pword2 domainName
Tls fullyQualifiedHostName_or_domainName userName password domainName
cert fullyQualifiedHostName:sslPort clientCert certPassword

Windows Authorization Manager (AzMan): The Best Kept Secret…

donovanf — Thu, 08 Mar 2007 03:06:00 GMT

I don’t know how many times I’ve had someone say to me that has “discovered” AzMan that they feel it is one of the best kept secrets in Windows. However, since keeping it a secret has never been in the mind of the product team, it’s time to extend its press. Authorization Manager is a technology that essentially lets the application developer remove the hard-coded authorization policy from their application and “externalize” it in a form where it can be managed by an administrator. AzMan provides a tool for managing Role-Based Access Control (RBAC) policy in the form of a MMC Snap-in. This policy can be stored in an XML file or either Active Directory or Active Directory Application Mode. Using its API in your application, you then instantiate an AzMan context, bring in the policy and perform access checks at runtime for the various authorization decisions your application needs to make. The API can also be used for you to build your own custom management tools that may better fit with your application’s deployment needs or look-and-feel.

But, rather than drilling too deeply into things here, I’m going to use this as a jumping off point for “all things AzMan.” As with any technology there’s the potential for information saturation and then possibly ending up with less information than you needed. So although I can’t/won’t mention every resource, I’ll try and bubble up for architects and developers some of the key resources to get you going and you can dig deeper from there.

To get the ball rolling, I’m announcing here a new "Demystified Series" of screencasts on Channel9 for AzMan by Keith Brown. These should get you charged up and rolling on its concepts and programming techniques. Keith says that AzMan is, “…a hidden gem in Windows that can help you build Role-Based Access Control into your applications.” I hope you find this true as well.

Channel9 Screencasts:
    Getting Started with AzMan – Keith Brown
    Programming AzMan – Keith Brown (Code Sample)
    AzMan in the Enterprise – Keith Brown (Code Sample)

Case Studies:
ADAM and AzMan:
FileHold uses AzMan and ADAM in their product, FileHold '06 and '07.

AzMan:
Lighthouse International

Technical Material:
      Overviews:
           AzMan overview by Keith Brown
           ”The .NET Developer’s Guide to Identity” the Authorization section of Keith’s MSDN article

      Drill-downs:
           "RBAC for Multi-tier Applications Using Authorization Manager" by Dave McPherson
           "Developing Applications Using Windows Authorization Manager" a most comprehensive AzMan dev resource.

Blogs:
           AzMan Team Blog don't be without it!

Added additional screencast links - 03/08/07
Updated some links - 01/28/09

.NET Programming with System.DirectoryServices.ActiveDirectory (SDS.AD)

donovanf — Mon, 12 Feb 2007 09:56:00 GMT

I am so pleased to announce a new white paper on MSDN by Ethan Wilansky that provides an introduction to the .NET 2.0 System.DirectoryServices.ActiveDirectory (SDS.AD) namespace. With the advent SDS.AD and System.DirectoryServices.Protocols (SDS.P) in .NET 2.0, directory services programming for the managed code programmer has come of age. These rich programming APIs bring to the .NET platform the ability to manage a directory that previously was only available through Active Directory Services Interface (ADSI) scripting, C++ or the LDAP API. If by chance you have not yet read the book A .NET Developer’s Guide to Directory Services Programming by Joe Kaplan and Ryan Dunn, I highly recommend it to you. It definitively covers System.DirectoryServices (SDS) and programming using the DirectoryEntry and DirectorySearcher object model. Although Joe and Ryan touch on SDS.AD and SDS.P at various points in the book, their focus primarily was on SDS. Therefore, Ethan’s papers are an excellent complement to their book.

By way of introduction, one of the design principles for the Directory Services namespaces was to introduce a low barrier to entry and self documenting object model. The intent is that programmers can learn the APIs quickly due to their strong typing, easy navigation between types, sensible defaults, simple initialization, convenient overloads and simple and straightforward entry points. The design goals were to solve specialized problems by simplifying the process of common directory services tasks, such as: topology management, schema management, replication management and trust management.

This paper of Ethan’s focuses on SDS.AD, SDS.P is in publishing now and I'll anounce it as soon as it comes available on MSDN. As mentioned, the SDS.AD namespace’s object model is built around Active Directory service tasks and includes such concepts as forest, domain, site, subnet, partition and schema. Ethan’s paper provides both a description and practical guidance on how to begin programming with SDS. AD for some common scenarios. A code sample accompanies the paper and can be downloaded here. Once you download and unzip the file, open the DirectoryServices.ActiveDirectory solution in VS 2005. If you intend to exercise all the functionality for Active Directory you will need to create a test environment, possibly in a VPC. To execute the Console against an ADAM instance (see my blog, Step 1: Get ADAM installed) you will need to open the ADAMData class, find localhost and change it to the full machine name of the computer the ADAM instance is located on and the port of that instance. For example:
Change This Line of Code From:
      static string adamConnectionString = "localhost:50000";
To:
      static string adamConnectionString = "your_machine_name:your_port_number";

Now, build the console application, start a Command Prompt, cd to the bin directory and run DS.AD. Executed without any parameters the application will give you a list of its available commands. This coupled with the white paper should give you a great start with SDS.AD. Following are the scenarios exposed in the sample code: Enjoy!

• Forest, domain, and ADAM reporting tasks
GetDomainData
GetForestData
GetGcData
GetDcData
GetSchemaData
GetSchemaClassData className
GetSchemaPropertyData propertyName
GetAdamPartitions

• Schema reporting and management tasks
GetAdamSchemaData
GetAdamSchemaClassData
GetAdamSchemaPropertyData
AddSchemaClasstoAdam
AddSchemaAttributetoAdam

• Topology reporting and management tasks
GetTopologyData forestName
CreateAdSite newSiteName
CreateAdamSite targetName newSiteName
CreateSubnet newSubnet siteName
CreateSiteLink siteName newLinkName
AddSiteToSiteLink siteName siteLinkName
RemoveSiteFromSiteLink siteName siteLinkName
MoveDcToSite sourceDC targetSite
DeleteAdSite siteName
DeleteAdamSite targetName siteName
DeleteLink linkName

• Replication reporting and management tasks
GetReplicationStateData
ReplicateFromSource partitionDN sourceServer targetServer
ReplicateFromNeighbors targetServer partitionDN
SyncAllServers partitionDN
CreateNewConnection sourceServer targetServer connectionName
SetReplicationConnection server connectionName
DeleteReplicationConnection server connectionName

• Trust reporting and management tasks
GetCurrentForestTrusts
GetCurrentDomainTrusts
GetTrustWithTargetForest
GetTrustWithTargetDomain
CreateCrossForestTrust targetForest userNameTargetForest password
SetForestTrustAttributes targetForestName
ChangeForestTrustToOutbound targetForestName userNameTargetForest password
AddExcludedDomain targetForestName targetDomainName
DisableDomainNetbiosName targetForestName targetDomainName
RepairTrust targetForestName userNameTargetForest password
RemoveForestTrust targetForestName userNameTargetForest password
RemoveDomainTrust targetDomainName userNameTargetDomain password

Capitalize on the Platform’s Identity Infrastructure for Single Signon (SSO)

donovanf — Wed, 25 Oct 2006 22:43:00 GMT

Providing SSO across desktop applications is certainly a desired goal in application development, but many developers think it is either not achievable, too difficult to implement, or lean on third-party solutions to provide this capability. In Keith Brown’s paper, The .NET Developer’s Guide to Identity, he states, “There are companies that spend fortunes trying to implement SSO across the myriad of applications they've developed or purchased over the years. What I'm here to tell you is that you can get this feature for free; all you have to do is agree to write less code and instead rely on the platform to do the heavy lifting.” He also discusses in some detail the nuts-and-bolts of authentication that developers should be aware of, but his guidance is to let the platform infrastructure carry that load. Developers should simply tap into what the authentication event makes available to them through the WindowsIdentity and WindowsPrincipal classes. Keith discusses these two classes in the paper so I will not elaborate here, but my intent is to show a bit of code and point you to a couple resources so you can experiment with this on your own.

Essentially, a developer can leverage the desktop’s login for their application in just a couple lines of code. You can see in this screenshot, http://blogs.msdn.com/photos/donovanf/images/874326/original.aspx, some of the information available in each of the instantiated objects.

So how does one tap into this? First, the developer must pull in a couple namespaces, System.Security.Principal and System.Threading. Then if your application needs to do repeated access for role-based validation (such as for .IsInRole checks), it is more efficient to simply drive off the WindowsPrincipal object because there is no need to repeatedly instantiate the WindowsIdentity object. These two lines of code will accomplish this:

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
WindowsPrincipal myPrincipal = (WindowsPrincipal)Thread.CurrentPrincipal;

If you need the additional information that the identity object provides, you can instantiate a WindowsIdentity object and then use it to subsequently instantiate a corresponding WindowsPrincipal object. This is shown in the following two lines of code:

WindowsIdentity myIdentity = WindowsIdentity.GetCurrent();
WindowsPrincipal myPrincipal = new WindowsPrincipal(myIdentity);

Now, does leveraging the platform’s authentication absolve the application from doing its own due diligence? Most likely not. Therefore, the application could interrogate the DOMAIN provided in the .Name property or use any of the other data values provided in the objects to assess whether or not to let the application continue. Or by the presence or absence of specific data values, it could make the determination to pop-up a login window that could collect and validate credentials against AD, ADAM or another LDAP store for that matter. My point here is to simply take tactical advantage of what you can from the platform and then extend it as needed. A short seven-minute screencast presenting a coding example for this is found here on Channel9 http://channel9.msdn.com/Showpost.aspx?postid=154885. And the companion, downloadable code sample is available here http://channel9.msdn.com/ShowPost.aspx?PostID=154871. Lastly, the code example shows how to use .IsInRole with a WindowsPrincipal object to validate if the user is in any one of the WindowsBuiltInRoles. It also shows how to use the .Groups of a WindowsIdentity object to list all the group security identifiers (SIDs) to which the logged on user belongs.

A Developer’s Resource for Identity and Access (IdA) Understanding

donovanf — Thu, 28 Sep 2006 19:23:00 GMT

If you were to read the following line of code in a program, what meaning might you derive from it?

grokIdA = Developer.GetIdAUnderstanding(information)

So what do I mean by grokIdA? If Grok is an unfamiliar word to you, it means to understand in a deep way. Since understanding is essentially a function of adequate and appropriately applied information, the purpose of this blog is to facilitate the types of information necessary for developers to attain a deep(er) understanding of the challenges surrounding Identity and Access (IdA). And further, to see how to apply technologies like Active Directory (AD), Active Directory Application Mode (ADAM), Active Directory Federation Services (ADFS) and Authorization Manager (AzMan) to help mitigate these challenges. The Microsoft Identity Integration Server (MIIS) product enables life-cycle management of identities (provisioning/de-provisioning and much, much more), but IdA Management (IdAM) will not be the initial focus of this blog.

Today enterprises face ever pressing regulatory compliance and audit requirements making it essential for them to solve their identity and access issues. However, I realize it can be a daunting task for a developer to research all the capabilities of the available technologies, search and find all the information available, and then stitch together an approach for building their application. Some readers may have just been assigned the task to get a handle on their enterprise’s or product suite’s IdA issues. Some may be in the research phase but are getting bogged down with information overload. And others may be well on their way to designing approaches and solutions. In any case, the premise I am working from is that this is a “journey toward understanding” which assumes that many will be traveling alongside who may be new to IdA and its problem space. Therefore, let’s start the journey/conversation with, “The .NET Developer’s Guide to Identity” on MSDN by Keith Brown. This is an excellent document that lays out the landscape for identity from authentication to authorization to federation and much more. Enjoy.