Windows domain accounts — insecure by default?

Today, I was working on an issue at a client site. I was given a Windows domain account and a personal certificate to login to their VPN.  I don’t know how the Windows domain account was created, but I’m assuming that it was nothing special.

Once I connected to VPN, I Remote Desktop’ed into the Windows server with my Windows domain credentials, and started working the issue. I began looking around. I found some errors, and had some emails back and forth with the client to work the problem. Eventually, I discovered that I was working on the wrong server. Oops.

I was grousing over the fact that the client hadn’t given me the correct server info or account login info, when all of a sudden, it hit me: without the correct server or login info, I was able to login to a Windows server, and do work. Could I login to ANY Windows machine with those Windows domain credentials?

Well, it turns out that the answer may be YES, unless additional explicit setup is performed by your Windows administrator. In fact, it not only affects Windows machines, but potentially, any server or service you have authenticated by Microsoft Active Directory (AD):

• Windows machines.
• Linux machines.
• Oracle Hyperion installs.
• Oracle Business Intelligence EE.
• Oracle E-Business Suite.
• Oracle RDBMS (for enterprise users).
• Oracle Fusion Middleware.
• Web servers in general.
• Etc.

For Windows machines in general, you need to consider:

1. Authentication: Windows domain accounts.
2. Access Control: Some additional access control mechanism (unless you want all Windows domain users to be able to access all your Windows machines).

Not only does it affect Windows, but I can also affect anything that relies on Microsoft Active Directory for authentication.  All software and operating systems want to integrate with Microsoft Active Directory for authentication. It’s wonderful – you get to use the same username and password everywhere, have a central point of administration for account management, etc.

But, to make a secure Microsoft Active Directory integration, you need to consider:

1. Authentication: Integration with Microsoft Active Directory for authentication.
2. Secure communication: SSL on the connection between your service and your Microsoft Active Directory domain controller, otherwise, you may be transmitting passwords in cleartext over the network, depending on how the authentication occurs.
3. Access Control: Some additional access control mechanism (unless you want all Windows domain users to be able to access your service).

I think the main message is that you need to separate the concepts of authentication and access control, and remember that by default, Microsoft Active Directory only takes care of the authentication part. It does not, by default, take care of the access control part, and the access control part is really critical too.

Some things that you integrate with Microsoft Active Directory may not grant access for an authenticated user, unless there is also explicit access configured. That would be good. So, the problem does not affect everything. It only affects those things that, by default, grant access for authenticated Windows domain users (like Windows machines…).

I am not a Windows expert, so I contacted the Internet Storm Center for clarification. Some very kind folks at the Internet Storm Center responded. In the order received:

From Guy Bruneau:

I’m no expert on Window AD account restriction but I know you can restrict access to certain boxes via AD. Other Handlers that administer Windows server might answer your question with more details.

From Mark H:

Hey Jeff, It is normal behavior in Windows world, but you do not have to live with the default behavior. What we usually do is change what devices the account can log onto. In AD you can specify exactly which servers the account can log onto. That restricts these kinds of issues and you would have only been able to work on that one device.

From Rob VandenBrink:

You typically need to grant RDP access, but in a lot of cases the users are domain admins, so access isn’t a problem. There are multiple access control methods – a few are outlined here:
http://technet.microsoft.com/en-us/library/cc753032.aspx
http://support.microsoft.com/kb/290720
But your other observation is spot on – if you have a working account, it’s a great foothold – it’s very common to find “normal” AD users with all sorts of permissions they shouldn’t have.

From Russ McRee:

Granular access and provisioning can (should) absolutely be achieved with Active Directory. Users and machines can be encapsulated in Organizational Units (OUs) and permission established for specific systems granted via membership in security groups. Sound like the folks who gave you access have a flat unstructured domain environment where in everyone with an account has access to everything. Easy to do, sadly common, but not recommended.

From Chris Mohan:

>>>I am curious: do normal MS administrators consider limiting access when they create MS AD accounts?
It should be standard practice is to define an account that has access only the resources the party has to interact with. That understanding is part of any Ms training and documentation on the topic. I can attest it’s drilled in to anyone taking Ms training, qualifications or that’s read any of the Ms best practice papers.

>>>If MS AD authentication = access, then having an MS AD account grants you a lot of access.
Only if misconfigured by the administrator to allow excessive, unnecessary permissions. Sadly this is a general problem, seen commonly across the IT space. Someone running a system or network handing out admin/Root level access “because it’s easier that way” or they simply don’t understand the risk of providing that level of control.
I’d submit that the administrators of that environment hadn’t followed standard, basic security practices for least privileges and limited, defined access, if they only meant for you to work on one server, rather than a group of them. I’d gently bring this up with the client as they may not be aware of this security misstep.

My colleague at Jibe Consulting, Pete Beebe, our Windows admin, wrote this:

No unless the domain administrator explicitly allowed ‘log on to server’ permissions for the AD account that you were using.  Normally the ‘log on to server’ policy is included in the Remote Desktop Connection security group.  If an account (other than administrator) is not added to the proper security group then logon access to the server is denied.  As noted by your later e-mail, it is also possible to explicitly define the server(s) that an AD account can logon to.  This combined with the local policy setting (for non-domain servers) and Group policy setting (for Domain member servers) would determine the accessibility of the AD account you’re using while on their network.

I also received a response from David at the Microsoft Security Response Center:

Presumably the client created an AD account with access to more than one server. Unless they specifically lock you out of other machines on that domain, you will have access.

So, consider carefully how you setup Windows domain accounts and security. You may be accidentally allowing more access that you bargained for.

P.S. If you’re a Windows administrator, and you see something that needs correction or clarification, please add a comment!