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 2 hours 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

▲

brendoelfrendo an hour ago | parent [-]

> In the AD world, allowing remote code execution is not a bug, it's a feature.

This is the assertion that I think you have failed to prove. RDP and WinRM are just remote access protocols, like SSH or what have you. AD doesn't have to be involved in their use, so I'm not sure how "RDP allows you to log into a server remotely" is AD's problem. Or even a problem at all, since that's what its meant to do.

> A direct competitor of AD is oauth,

It really isn't. OAuth is for authorizing third parties access to client resources, not for authentication. By the time you're getting access tokens with OAuth, you've already authenticated with your identity provider. Perhaps you're referring to OpenID Connect, which is built on OAuth 2.0? In any case, AD and OAuth/OIDC don't really compete with each other. AD is intended to be used on internal enterprise networks to simplify authentication and authorization across a fleet of machines, and OAuth/OIDC have a much more pronounced focus on web.

> which does not allow people to execute code on the issuer

I'm not sure what this means. When you say issuer, are you referring to the auth server that issues ID tokens? What if I'm hosting my IDP in AWS and use an OIDC integration to access my AWS admin console and remotely log-in to my IDP server? Am I not then using it to execute code on my auth server?

▲

JackSlateur 28 minutes ago | parent [-]

"This is the assertion that I think .." - you are showing bad faith;

"OAuth is for authorizing third parties access to client resources, not for authentication" - just like AD, oauth is used for authentication and authorization; See the fields sub, scope, audience etc;

"OAuth/OIDC have a much more pronounced focus on web" - of course, we do not use "web" inside internal enterprise networks;

"When you say issuer" - issuer is a keyword, not a random word; But again: you know it;

"Am I not then using it to execute code on my auth server" : can you execute any kind of code on AWS' IAM servers (any server will do) ? Please share some details;

	▲	brendoelfrendo 4 minutes ago \| parent [-]
		> you are showing bad faith No, I'm not. You haven't proven it. > just like AD, oauth is used for authentication and authorization In a sort of roundabout way, but in those cases what the relying party is accessing are the user's identifying details. > of course, we do not use "web" inside internal enterprise networks That's not really what I mean. I would never expose an AD domain to the internet, that's not what it's for. > can you execute any kind of code on AWS' IAM servers That's not what I was saying, I was saying it in the context of a self-hosted identity provider. If all you've meant by this entire exchange is that OAuth means you don't have to worry about security because you've outsourced it to someone else, then I've really wasted my time.