> AD has built-in mecanisms where a random person can execute code on the AD themselves

Could you provide an example? I'm sure I know what you're talking about, but the way you put it I'm having a hard time figuring out what you mean.

> Most people are not perfect; Hence, most people have security issue with AD (see the never ending tail of cryptolocked companies)

Yeah, but, how many of those ransomware attacks exploit misconfigured AD environments rather than something more banal like harvesting credentials accidentally checked into Git, or spear phishing for a target? Identity, in general, is hard.

▲ JackSlateur 3 hours ago | parent [-]

AD allows connections between two computers that are registered against the active directory, including a random laptop and the AD themselves

This is a fundamental difference versus something like oauth: in the former, everything is done to allow RCE on the AD: the code exist; in the later, everything is done to prevent RCE on the issuer;

Identity is hard ? Identity is a lot simpler once you assume that:

  - people make mistakes
  - code is buggy
  - infrastructure has issue

This is why using things like oauth instead of AD's authentication mecanism is good: because it is secured by default and you must try really hard to allow a wide range of attack

▲

Dylan16807 2 hours ago | parent [-]

"allows connections" isn't code execution. An actual example would be really helpful here.

▲

JackSlateur an hour ago | parent [-]

In the windows world, you connect to a server using RDP. I thought this would be implied. RDP is a mean to connect to a remote host and, from there, execute code. Hence, code execution.

https://en.wikipedia.org/wiki/Remote_Desktop_Protocol

See also this: https://en.wikipedia.org/wiki/Windows_Remote_Management (different player, same thing)

▲

brendoelfrendo 42 minutes ago | parent [-]

What on earth are you talking about? RDP and AD are pretty much orthogonal to each other. You can use an AD account to connect to a domain-joined remote server over RDP, but at that point you're just... logging into a machine, same as any other remote protocol. You prevent bad actors from doing this by not giving them permissions to log in to that server. To call this "code execution" is really odd. Remote code execution as a vulnerability almost always refers to an unintentional behavior in software that allows an attacker to execute arbitrary code as part of that process. Referring to a user logging into a machine with the appropriate permissions and running software as "code execution" is not typical, and is not a vulnerability in any normal sense of the term.

	▲	JackSlateur 11 minutes ago \| parent [-]
		Because logging to a remote server is not "executing code in that remote server" .. ? Same as any other remote protocol ? Yes. But we are not talking about that, we are talking about active directory, whose main purpose is to authenticate and authorize stuff. Yes, you can configure everything. But just like a wall is better than a door with a lock .. see what I'm saying ? In the AD world, allowing remote code execution is not a bug, it's a feature. Call it a vulnerability if you want; A direct competitor of AD is oauth, which does not allow people to execute code on the issuer Number of cryptolock due to oauth: none (that I know of); As if theory and practice sometimes meet .. I understand that you like AD, and that's fine. The original post was about security and I stand by my point: thinking that we are perfect, that others are doing mistakes but "not us" is not good for security. Neither is playing with fire, as per the vast quantity of burnt people