6

Without the equipment and software (and knowledge yet) readily available to test myself, I've been wondering about the relationship between computers and domains in a Windows environment. Some information is available in answers like https://security.stackexchange.com/a/83380/58802, but I was thinking about other things, like:

  • What information, like the computer SID and stuff, IDs a computer to a domain?
  • I assume this information can be faked or replicated, but can it?
  • If so, is that a security issue?

Like, if I have a computer that's authorized for a certain domain, and wipe it clean, assuming I took note of whatever locally stored information that is relevant to the case, could I restore the authorization to the domain for my computer, without explicit privileges to administer the domain?

I was also thinking about the-other-way-around-scenarios:

  • How does a computer "identify" a certain domain?
  • Can the domain be "faked"?

I'm sort of asking if it's possible to trick a computer into "believing" it's on the supposed domain, but it's really not, enabling scenarios where inappropriate policies are forcibly applied and stuff.

I'm asking these questions in the interest of better understanding the security workings of a windows domain (and similar), even though it's really not my main area of competence, and I hope that someone with the proper knowledge will find educating in general to be good cause enough.

Thank you before hand.

Community
  • 1
Oskar Lindberg
  • 393
  • 3
  • 10

1 Answers1

2

The technology you are looking for is Kerberos. It allows for a secure, mutual trust between objects in an Active Directory (in your case - the AD controller and a host, member of the AD).

Microsoft has a few comprehensive reviews of how it works. This one is from 2009 but the concepts are the same.

WoJ
  • 8,957
  • 2
  • 32
  • 51
  • How does "Kerberos" answer my questions, like "can a Windows domain be faked"..? – Oskar Lindberg Feb 28 '16 at 10:15
  • Sorry if it was not clear. The answer is "no, it cannot" - because AD authentication is based on Kerberos and Kerberos has been created to ensure cryptographic trust. The links I mentioned (particularly the second one) explain why. i was actually wondering whether to repeat the content but it would be more or less copy-paste. – WoJ Feb 28 '16 at 10:34
  • OK, but I'm not asking specifically about AD authentication of user accounts. Are you saying that computers on the domain are identified through Kerberos too? – Oskar Lindberg Feb 28 '16 at 10:40
  • Yes, in an AD you will find objects which may be computers, users, devices, etc. The authentication details vary between the type of object but the underlying principles are the same. – WoJ Feb 28 '16 at 10:46
  • Thank you for taking the time to elaborate. Kerberos may be the preferred authentication protocol, but it's not the only option. My question may be too broad, and the answer may well vary depending on the circumstances. Would I be correct in assuming that your answer should be interpreted as "if using Kerberos, one client cannot fake it's identity, even assuming full physical access to another client that's already on the domain, and clients can never be tricked into trusting the wrong domain"? – Oskar Lindberg Feb 28 '16 at 11:27
  • Kerberos is THE authentication protocol for Active Directory. Please see https://technet.microsoft.com/en-us/library/hh831472.aspx for details (especially the table down the page) – WoJ Feb 28 '16 at 22:52
  • According to [this answer](http://security.stackexchange.com/a/116175/58802), in theory, there's nothing really that prevents manipulating the exchange between a domain controller and a particular computer, at least not as far as how the domain controller identifies and allows a computer access to the domain goes. And like I said, Kerberos may be preferred, but legacy protocols are still supported, are they not? See https://msdn.microsoft.com/en-us/library/windows/desktop/aa378749%28v=vs.85%29.aspx – Oskar Lindberg Mar 02 '16 at 16:01
  • Re: Kerberos: An authentication protocol is there to ensure that a given device is allowed to connect. The answer you point to assumes that someone has complete control over the client and can therefore manipulate any of its responses + also has a pre-existing authentication to the AD in place. There isn't much which can be done in such a case, except if the information was encoded in silico (which is the case with TPM for instance). Kerberos is not vulnerable to someone listening to the network and intercepting data in order to join a domain (which is its role) – WoJ Mar 02 '16 at 17:12
  • Re: NTLM: NTLM v2 Session is not vulnerable to attacks except for Pass the Hash. This is a horrendous weakness of Windows which has been fixed in Windows 10 only. It requires administrative access to a machine where an administrator logs in. So it is not a weakness of the authentication to the domain but a horrendous (again) design flaw in how an existing authentication can be intercepted on a client and replayed. Microsoft claims this is "by design" and does a lot of belly dancing around "measures to avoid the attack" (which are silly). – WoJ Mar 02 '16 at 17:16