As I understood the joined to Windows AD computers are always securely identified/authenticated before DC (using automatically changed computer accounts passwords).
Now, I read (in non-English article) that IPSec always should be configured in AD. Why is it? Suppose that AD is well secured from internet or even doesn't have internet connection in tight company environment.
When is IPSec "must" for AD?
BTW, why are the secure authentication of AD computers always needed? Can DC be configured for insecure authentication of computers (for ex., in small development/testing environment)?
----------
Update1:
Having this very secure, very flexible, very easy IPSec, how the hell to fall back to insecure AD computers?
Do I understand correctly that this secure authentication of AD computers makes impossible
- single-sign-on between workgroup users and AD user accounts
- RunAs and secondary logon with AD user account in workgroup Windows (and vice versa)
which is the pain in the ass for development or tiny companies infrastructures. This inflexibility does not make much sense (having IPSec)?
I suspect the primary reason for this requirement would be when you cannot trust the physical network. Perhaps because you are sharing the network with someone else. Perhaps the switches are outside of your control.
When I first ran into this opinion in 2001, it was early enough in the development of Active Directory that IT as a whole was still getting to grips about what exactly you could do with it. Windows NT had some IPSec controls in it, but Windows 2000 and Active Directory brought a lot more. The thinking went like this:
This was seen as a very solid step in 'defense in depth'. The few people I heard of who'd managed to actually make their networks fully IPSec still had to do a lot of work to make it so, even though AD theoretically made it easier. I honestly haven't heard of a pure IPSec AD network in the last 5 years.
Is it a good idea? Probably. Is it required? That depends on your security posture. If you can't trust the physical though network layers of your network, then IPSec is absolutely a good idea. Just like Zoredache pointed out. "Can't trust" can be due to explicit policy stating that the physical layer can't be trusted, to actual open ports that allow anyone to sniff, to having to leverage a public network.
IPSec is probably a very good idea when it comes to wireless networks, but again I haven't heard of many actually doing that.
I wouldn't consider IPSec a required feature of an AD without a specific security requirement, but if you're implementing a new AD environment today, I'd seriously consider it.
Microsoft is embracing the notion of fully mobile client computing, and PKIs and IPSec are a big part of that strategy. You can now pretty easily have remote workers anywhere persistently connected to your corporate network via DirectAccess whose computers are managed outside the firewall via SCCM in Native Mode. Pretty swoopy stuff.
Another use case is if you have a network where you have alot of firewalls restricting communication between application tiers, DMZs or other political divisions. Putting up AD servers in these little networks gets expensive fast, and IPSec makes it much easier to traverse these firewalls securely and ensure that only devices that you have issued a certificate to can use IPSec to communicate.