I have no honest clue how to really do Windows. While I have worked extensively with Windows in my life, I’ve never been a true systems administrator for it. I haven’t built active directory from nothing. This is going to be me documenting my stumbling journey through the wide and wonderful world of Windows environments! Let’s just jump straight in.
Let’s start with about as basic as you can get. A standard Windows 2016 server, and then a Windows 7 workstation machine.
We’re gonna get rolling right with the domain controller.
Next let’s get a PC up and going. This is going to be my primary interface into the environment. I am going to use it as if it were my client machine for administering the Windows servers and everything else.
This is just a plain ol’ Windows 7 computer at the moment. Let’s get it hooked up into the domain, and create myself a user and domain admin, shall we? For now, I have to do a console authentication directly to the server until I can get this client machine hooked up to the domain
Now, let’s pull up the Active Directory Administrative Center
Cmd.exe > dsac.exe
On the left side, I select dumbyland (local) > Users > New > User
And they’re created! I feel like we should next get going on the client machine. Here’s a vanilla machine, and I have no clue how to do this right… but let’s figure some stuff out.
In the System Properties window, there is the option to “Change” domain settings. Select that. It will prompt you to enter credentials -- I used the dumby-user account I just created to simulate a new, regular user!
Okay this just isn’t working. I have no clue what else I need to do. I update my DHCP settings to ensure that 192.168.2.10 (domain controller) is the primary DNS since at one point this was giving me DNS error of some kind. Now I’m getting a logon failure error
I figured that perhaps the issue is that I was using an account that I hadn’t yet logged in with before. To get around this, I used the primary administrator account to sign-in for the first time. My prediction seems correct… and I signed in for the first time! This message was a beautiful sight.
After this, I reboot the PC, and RDP back in to it. I still can’t sign-in as the normal user, but we’ll get that figured out soon enough. I replaced this dumby-user account with the administrator, and successfully signed back in.
Well, this is at least giving me hope!
I can’t get a sign-in to the regular user to work, but I’ve got a canvas to start from. My main goal right now was direct administration of the domain controller since I’m doing everything through the ESXi web console -- not exactly speedy and reliable! There are also some issues with directly RDP into the DC, so I’m gonna be using my Windows 7 VM as a ‘jumpbox’ into my domain. (Laptop RDP > Win 7 VM, RDP > Server 2016 VM)
RDPception! Here is my laptop RDP into the Windows 7 VM. From that, I RDP into the domain controller VM. Hooray!
For some reason now that I have direct access, password change and logon for the user worked. I opened up a new RDP session, signed in, and was prompted to change the password.
To get away from the default administrator account, I’m going to start using this new administrative account. First things first, it’s complaining about having Remote Desktop Users permissions -- let’s get that going right now.
I opened up my existing admin RDP access through the built-in Administrator account, and right-click my dumby-admin account, and added it to the ‘Remote Desktop Users’ group as well as the ‘Domain Admins’ group. I then signed back in with my dumby-admin account, and kicked out the other RDP session. Hooray!
And now I RDP back into the domain controller with my dumby-admin account from my client PC. WHOOO!I absolutely love hitting these milestone points in little projects like this. Another quick update was to add my user account to the ‘Remote Desktop Users’ group so that I can access it from my laptop directly using my client account.
For some reason… this isn’t working. I’m not sure if there’s a delay in it taking effect or what, but doing a domain sign-in to my ‘dumby-user’ account via RDP is still giving me the permissions error, whomp.
What I’m reading right now is that this is because of permissions on the local computer I’m trying to access, since I need to update its own members of the “Remote Desktop Users” group. It’s worth a try! Let’s first make the change directly, and then if that works, I’ll get some experience with Group Policy and distribute that change to all future computers as well
Okay, so first things first. Search ‘users’, and open ‘Edit local users and groups’. Go to ‘Groups’ > ‘Remote Desktop Users’. Select ‘Add’, and then I searched ‘dumby-user’, which then automatically discovered the domain user. This all makes perfect sense now! You must give individual permissions on each endpoint of which users can access it via RDP, but that user can be a domain user. Good to know!
It doesn’t seem like I needed to do these permissions for my admin account… perhaps because it’s a domain admin? An interesting note, and if that’s true, it prevents me from needing to do any GPO stuff for now, it seems, since I’m only worried about my own user account being able to access this VM. Hooray!
Now, I have a domain authenticated user machine! From it, I can use it to access the DC via my domain admin account -- dumby-admin. This is how I was hoping for it all to work! Very happy with all of this so far.
Performance of my server during all this….
Everything is super snappy. RDP is working fantastically -- console works a LOT better since I did the driver optimization fix for storage.
To start having some real fun, I want a 2nd client that can act as a vulnerable machine. Let’s see what trouble we can get up to! To make things easier, I figure it’s worth learning how to clone VMs with ESXi. I found this guide to do so:
And that’s basically it! I repeat my instructions above to get this new machine joined to the domain, and now I have a nice little set up going! Next up is to introduce some logging, and then I think I’ll have some fun setting up attacks and reviewing that information.Last Edited: 2018-06-17