I was going thru few old posts in this group and came across this one. First I would like to thank for this information. It was very helpful. I would like to share tools on this topics in windows operating system, which you can use it to study / analyse / test / audit an Active directory or Group policies in a network. This will be helpful during IT Security and Compliance audit as well.
*Microsofts' Active Directory topology diagrammer:* http://www.microsoft.com/downloads/details.aspx?FamilyID=CB42FC06-50C7-47ED-A65C-862661742764&displayLang=en *Microsofts' Group Policy Inventory:* http://www.microsoft.com/downloads/details.aspx?familyid=1D24563D-CAC9-4017-AF14-8DD686A96540&displaylang=en Regards Sandeep Thakur On Mon, Jun 21, 2010 at 11:56 AM, Sadguru Thakur <[email protected]>wrote: > Hi All, > > The below will be of help to understand how to secure the active directory > or key areas to look for during audit of systems / network. > > When a security professional is asked what repositories are most used to > gain access to the infrastructure services and applications, one of two > answers is almost always given: LDAP or Active Directory. > > While the first is an international standard repository supported by almost > all of the directory vendors in the marketplace, Active Directory has almost > as large of an enterprise deployment footprint as all of the LDAP vendors > combined (even though it is supplied by a single vendor, Microsoft). From > its initial use as a tool for authenticating a few interconnected PCs, it > has grown into the premier enterprise repository. With the level of > complexity needed for today's enterprise repository deployments, IT managers > spend hours and hours on design and support activities to ensure the > features and functions of Active Directory meet the needs of the > organization. But some IT managers overlook the most important task: > securing their Active Directory itself. > > Active Directory contains the keys to the kingdom when it comes to group > and user account information. In most cases, if an organization's Active > Directory deployment were to experience a catastrophic event, no one within > the organization would be able to access the services they need to perform > their duties. > > So what's the best way to determine if the security of an Active Directory > infrastructure is sufficient? A periodic Active Directory security audit is > required to ensure that Active Directory is being properly managed and > protected. But audit personnel must understand what coverage areas are > important for the security of an Active Directory deployment and what to > look for. The list below will help in understanding how to ensure Active > Directory security: > * > Policy and architecture* - Active Directory, like any enterprise service, > must have a long-term management plan. Auditors should look for > well-documented policies and architectures that define what information is > owned by Active Directory, who is allowed to access it, what Active > Directory's functional role is within the organization and how architectural > changes should be made and documented. > > *Physical placement *- At the lowest level, ensuring that Active Directory > servers and their domain controllers are secure means ensuring that they are > located in physically secure spaces. Whether in professional data centers > or locked communications closets, Active Directory servers should always be > protected against physical theft. Finding Active Directory servers under > desks or in open, unsecured spaces may be an indicator that the > organization's deployment of Active Directory is insufficient to secure it. > > *Distributed deployment* - Due to the criticality of the role that Active > Directory plays in allowing access to systems and services, Active Directory > repositories should be distributed across the organization. While an > architecture project should be in place to determine where the Active > Directory repositories should be distributed, some good positions to > consider are geographic locations with slow wide area network links, > physical areas of large populations of users, and an area close to identity > access services that use Active Directory for authentication/authorization. > Also, a good replication service must be in place between the distributed > servers to ensure that denial-of-service (DoS) attacks will have minimal > impact. Placing Active Directory services close to the users who depend on > them for access ensures that network and power outages will minimize > downtime. > * > Administrative access* - Organizations should take advantage of Active > Directory's multi-level administrative access services to tailor > administrative functions to administrative privileges. Auditors should > ensure that full administrative access is limited to a small number of > administrators who are responsible for server-to-server interoperation and > configuration, along with schema management. Personnel responsible for a > subset of administrative functions, such as help desk personnel who reset > passwords, should be given only the ability to perform their functions > without any additional administrative access. And when it comes to > creation, deletion and updating of accounts, automated tools, like a > provisioning system, should do the job in order to minimize manual errors > and guarantee protection of sensitive account information. > > *Active Directory groups *- Active Directory groups are used to manage > access to services at a macro level. By assigning a user to a group, the > user automatically inherits the group's access privileges. Active Directory > group management originally started out organically -- groups were created > on the fly with little documentation and few controls -- and that led to a > lack of understanding of the groups' original purposes by later > administrators. This caused Active Directory groups to proliferate at a > speed that made them hard to manage; this is one of the key areas for > auditors to explore. In auditing Active Directory groups, auditors should > look for clear, well-defined processes for the management of these groups. > Also, documentation should be completed on who the group owner is, any > projects the groups might have been created for, how long the groups are > valid, what access the groups grant, and any other Active Directory groups > related to the group in question that may be used for access. > > *Schema configuration* - Active Directory stores information in a > spanning-tree directory schema. Users and groups are allowed access based > on their placement in the hierarchy and the access control lists (ACL) for > the various containers, as well as objects for access rights (read, write, > execute, delete). Auditors should review the layout of the Active Directory > schema, and the associated ACLs, to ensure they are configured to provide > sufficient separation and protection of information from other groups or > users stored within Active Directory. > > *Strong automated account management* - As stated above, most > organizations have moved to automated provisioning tools to manage Active > Directory accounts. But just because the tools are automated doesn't mean > they're automated well. Auditors should look for well-defined processes for > account requests and well-thought-out rules within the provisioning tool > that ensure correct privileges. Also, accesses should be granted along with > correct workflows when access requires the user's manager or resource owner > to approve the access. In addition, auditors should ensure that any > accounts not recently accessed, or accounts no longer needed, are disabled > or removed in a timely manner. Finally, to ensure the right access > privileges are still in place, the organization should have a > "recertification" process wherein managers or administrators are > periodically required to certify that the accesses for the persons under > their responsibility correspond correctly to the users' responsibilities and > the functions they perform. > > *Active Directory integration* - While the list above outlines a number of > Active Directory-specific requirements for securing the repository, the fact > is that many legacy application and servers still can't directly access > Active Directory and must be synchronized with it. This involves extracting > information from Active Directory and electronically forwarding it to other > applications and servers, where the information is then stored locally on > the receiving system. Auditors should check to see if data transfers from > Active Directory are still required by inquiring whether new methods are > available to allow these applications and servers to directly connect to > Active Directory and not copy its information. Auditors should also ensure > that the Active Directory information in the local application or server has > the same level of access controls as it has in Active Directory. Finally, > auditors should ensure that the Active Directory information isn't forwarded > on to other applications or servers from the receiving systems to make > certain that the information can be tracked to all the servers and > applications which consume them. > > Active Directory has evolved from department-level PC control to a fully > functioning enterprise directory. While initially Active Directory > deployments were below the radar of most auditors, due to the ever-evolving > role of controlling access, Active Directory is now clearly in the sights of > organizational security and audit teams. Thus, while scrutiny of Active > Directory security has increased many times over, it is fully justified. > Due to the important access services it provides, organizations don't want > the keys to the kingdom to be left unprotected. > > > ------------------------------ > > *About the author: Randall Gamby is an enterprise security architect for a > Fortune 500 insurance and finance company who has worked in the security > industry for more than 20 years. He specializes in security/identity > management strategies, methodologies and architectures.* > > > Regards > T. Amardeep > > -- > You received this message because you are subscribed to the Google Groups > "nforceit" group. > To post to this group, send an email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<nforceit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nforceit?hl=en-GB. > -- You received this message because you are subscribed to the Google Groups "nforceit" group. To post to this group, send an email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nforceit?hl=en-GB.
