by Darren Mar-Elia

This chapter provides a practical guide to protecting your AD-based identity data. It is not part of the life cycle I spoke about in earlier chapters, but it is an important part of ensuring that any identity system you implement that leverages AD is protected such that it is able to do its job of authenticating and authorizing the right people to the right resources. All the great identity provisioning processes in the world won’t help you if your AD is a free-for-all that anyone can fiddle with to their heart’s content. This chapter will dive into the AD security model and provide techniques and best practices for securing the data that resides in AD.

by Darren Mar-Elia

Managing identity is ultimately about managing access to your corporate resources. Users authenticate to resources with their identity, then use the properties of that identity (for example, group membership) to get authorized to resources. In a typical midsize-to-large organization, you might find the following sources of identity…

by Darren Mar-Elia

Microsoft’s Active Directory (AD) product had humble beginnings. When it first came on the scene in 2000, Novell Netware was the dominant directory service on the market, and was certainly the most popular directory service to leverage the industry-standard Lightweight Directory Access Protocol (LDAP). Fortunately for AD, after a number of missteps on Novell’s part, [...]

by Realtime Publishers 

Realtime Publishers is proud to announce the complete book entitled The Definitive Guide to Active Directory Troubleshooting, Auditing, and Best Practices – 2011 Edition by Don Jones is now available for download! Synopsis and chapter list for this book below

by Don Jones

In the Windows Server 2003 timeframe, Microsoft introduced Active Directory Application Mode, charmingly referred to as ADAM. These days, ADAM has grown up and changed his name to ADLDS (or AD LDS, if you prefer): Active Directory Lightweight Directory Services, which is distinct from the AD directory service that we’re usually referring to when we just say “Active Directory.” In this short chapter, we’ll explore what AD LDS is all about, when you should (and shouldn’t) use it, and how to perform basic troubleshooting and auditing with it.

by Don Jones

Third‐party auditing tools take several approaches to supplementing Windows’ native
capabilities. First, these tools may do a better (and faster) job of collecting events from
multiple servers’ logs into a central location. Often, that central location is a SQL Server
database, although other tools will always forward events in real‐time to an external
logging mechanism, such as a syslog server.

by Don Jones

Unfortunately, the native auditing system does not always hold up well. I really don’t regard this as a weakness on Microsoft’s part—after all, their job isn’t to anticipate every possible business need, but rather provide a platform on which other software can be deployed to meet specific, varying business needs. They’ve done that. The native auditing architecture is bare‐bones, suitable for the smallest organizations that are less likely to be able to afford add‐on software to meet specific business needs. The native system is also close to three decades old, and you can’t always expect systems of that age to meet every possible modern requirement.

by Don Jones

Microsoft has already begun to address the issue of one log holding so much information. In Windows Vista and Windows Server 2008, Microsoft introduced a parallel event log architecture that makes it easier for each product or technology to maintain its own log. This was always possible-the original Application, System, and Security logs have long been supplemented by logs for Directory Services, for example. But this new architecture is more robust in several ways. Figure 5.5 shows some of the old and new-style logs.

by Don Jones

In the previous chapter, you learned that permissions are applied to a Discretionary Access Control List (DACL). Each DACL consists of one or more Access Control Entries (ACEs), and each ACE grants or denies a specific set of permissions to a single security principal—that is, a user or a group. The DACL is the authorization part of the AAA model: AD authenticates you, and gives you a security token containing a unique Security Identifier (SID). That SID is compared with the ACEs in a DACL to determine your permissions on a given resources.

by Don Jones

This chapter is a kind of “miscellaneous best practices” list. The trick with AD and best practices is that there’s never any one right answer for every organization. You have to temper everything with what’s right for your organization. So really, this chapter is intended to simply give you things to think about within your [...]