This chapter focuses on how AD becomes less-than-secure, how you can work with AD security more effectively, which AD security items are often overlooked or neglected, and how you can work to keep AD more secure on a continuing basis.
As more applications rely on AD as a central directory, making and keeping AD secure becomes more important to securing everything else in your enterprise. In addition, AD itself can be incredibly complex, so it's hardly surprising that a few security practices drop through the cracks now and again.īut AD is, much like your physical network infrastructure, a core part of your organization's operations and security. Administrators can't be faulted, because too often they're caught up in the heat of the battle, dealing with less-experienced junior administrators, inheriting environments that weren't well-configured to begin with, and so forth. Nobody is really to blame: AD itself is designed to give you a lot of flexibility and won't complain if you don't follow best practices because you may have specific organizational needs that prevent you from doing so. However, over time-as objects are added, removed, updated, and moved around-AD often becomes somewhat less than secure. Initially, most organizations take the time to plan AD deployments and come up with a reasonably secure initial configuration. (Win2K also uses secure LDAP by default once you install SP3 or later.) Unfortunately, AD is literally what you make of it, meaning it comes out of the box almost entirely useless until you create users, computers, organizational units (OUs), Group Policy objects (GPOs), and so forth. AD comes out of the box in a pretty secure state, particularly in WS2K3, which uses secure Lightweight Directory Access Protocol (LDAP) by default and uses a fairly locked-down set of default permissions and configuration settings.
0 kommentar(er)
