0

Guys (and gals and everything in-between), I'm stumped.

I'm an MSP and recently took over a new client. The prior IT left on not so great circumstances, and I'm inheriting their mess. One of my recent projects is to crack their DC. All of my information tells me the DC is managed by an Ubuntu System running Samba. I was forced to reset the password for the Ubuntu system, but I do not think [I could be wrong, not an expert at Linux] that would be causing my issue, especially since the issue started before I did so.

It started simply enough, was trying to join a new computer to the domain controller. Received an error indicating that there was no DC. This is a lie, as there are other computers already joined to the DC that are functional, had the DC been down or non functional they would have had login issues long before this.

I then began to investigate the DC, which is when I learned it is supposedly hosted on the Ubuntu system. I found the system hosted on a VM machine, and it seems to be up and running. However, when I logged in, one of the first things I did was try to run the samba command, simply to make sure it was installed. I received an error saying Samba was not installed, but could be installed via sudo apt install samba. Where this system is functional and the DC is not failing to log in nor causing other issues, the only thing I can assume is that it must be hosted on a different system? With that said, EVERYTHING points to this machine. I can connect DNS to it, and once, just once, I was able to access it utilizing Active Directory Users and Computers, so I must be doing something wrong. The computer of course was rebooted after that, disconnecting me and I have not been able to log in again. DNS is functional, and lists all OU's.

End goal here is to yank the data off the system (whatever system that might be) and get a new Windows AD and import the data. But, I have to be able to get back into the system to do so.

I've tried every User who I have passwords and accounts for. My account has full access to EVERYTHING, every administrative group has been added to it (I verified that the one time I was able to access the system), and I have complete admin rights when I access one of the domain joined systems. When I attempt to connect to the domain controller I receive an error The domain ad.SOMEDOMAIN.com [obv. not the real domain name] could not be found because: Access is denied.

I've spent a good... oh 30 hours on this, at least. A lot of it during my own time after work because, well, I don't like to be bested. But this system... it's bested me. I have no idea where else to go, or what else to do.

Please, please tell me some good samaritan out there is willing to help me figure this out, or at least give me a direction to go...

I'm attempting to access the system from a Windows 10 workstation with RSAT installed. I have verified the DNS is set correctly, and am attempting this from a system on the domain already. It used to work, my boss was able to get into it initially, but by the time I got access this issue arose.

There is a script on the old Admins desktop called ADUC, this seems to be calling up the active directory in some way, but when I try to authenticate using the script it tells me the password is wrong.

script in question: ............ @echo off set /p username="Enter Username@example.com: "

echo listen up! echo %username%

runas /netonly /user:%username% "mmc %SystemRoot%\system32\dsa.msc"

rem runas /netonly /user:[REDACTED]@ad.[REDACTED].com "mmc %SystemRoot%\system32\dsa.msc"

pause

....................... Yes, the 'ad' portion is part of their domain name.

Thank you for looking!!!

WonkoTheSane
  • 1

1 Answers1

0

It started simply enough, was trying to join a new computer to the domain controller. Received an error indicating that there was no DC. This is a lie, as there are other computers already joined to the DC that are functional, had the DC been down or non functional they would have had login issues long before this.

It makes me wonder whether they weren't joined to the domain through AD, but instead through the old NetBIOS-based NT4 domain protocols. I think this was supported up to Windows 7, and existing joins would still work in Windows 10. As NT4 domains did not rely on DNS, they wouldn't notice any DNS-related brokenness.

(Or they might be using locally cached credentials for AD logins...)

However, when I logged in, one of the first things I did was try to run the samba command, simply to make sure it was installed. I received an error saying Samba was not installed, but could be installed via sudo apt install samba. Where this system is functional and the DC is not failing to log in nor causing other issues, the only thing I can assume is that it must be hosted on a different system?

It is possible that a locally compiled Samba version is being used, instead of the package available in repositories (which, for a long while, was very outdated in the Debian repos). For example, our DCs need a few patches that haven't yet been accepted upstream, so they run from /usr/local/samba.

Don't try to run samba, especially if it is expected to be running already. Instead, look at the process list ps axf or the service list systemctl -t service, systemd-cgls, systemctl status samba to see whether any related processes are running and you will usually see their locations.

With Samba it is easy to get direct access to the raw database that stores the LDAP entries (or even modify it – e.g. reset the AD "Administrator" password). If you find the files (they might be in /var/lib/samba/private but a local build might keep them elsewhere), you could e.g. check the modification timestamp of sam.ldb.d/*.ldb, or list the entries to see if they correspond to what you were seeing in ADUC – it might reveal that this DC has been sitting unused for a few years. For example, to list OUs:

ldbsearch -H /var/lib/samba/private/sam.ldb "(objectClass=organizationalUnit)" name

Also, if you find the smb.conf file (which is typically in /etc/samba), I'd suggest increasing the log verbosity a bit – just to see whether the DC at least reacts to your domain join attempts:

[global]
    # Older Samba versions only accept "log level = 3". Newer ones accept
    # levels for individual subsystems.
    log level = 0 auth:3 auth_audit:3 kerberos:3 rpc_srv:3

When I attempt to connect to the domain controller I receive an error The domain ad.SOMEDOMAIN.com [obv. not the real domain name] could not be found because: Access is denied.

With a mess like that, there's a slight chance that the network has two completely separate domains, hosted on different domain controllers, but with the exact same name. If the AD domain hasn't been delegated through DNS, but instead all computers were manually configured to directly use a DC as their DNS server, then the two domains would just kinda coexist and not conflict as long as they don't interact... but when they do interact (e.g. you logged in to domain A, but are trying to access the DCs of domain B) you won't get any access.

End goal here is to yank the data off the system (whatever system that might be) and get a new Windows AD and import the data.

Regarding this, if you're planning to just join a new Windows DC to the existing domain and have it replicate, then you'll most likely need to do in two steps (Samba→Win2008→latest), as later Windows Server versions seem to require some new APIs that Samba lacks. So first you'll need to add a temporary Windows Server 2008 DC, then remove the Samba DC, and then add the real Windows Server 201x/202x DC.

However, if you're planning to use some migration tool that only needs the basic LDAP information, you can extract it from the DC's sam.ldb using ldbsearch as above.

My suggestion is:

  1. Check a few DNS SRV records to make sure they point to the DC. I'd try to do this both through RSAT DNS Manager (if it can connect to the DC), but primarily through actual DNS:

    host -t srv _kerberos._udp.ad.example.com
host -t srv _kerberos._tcp.ad.example.com
host -t srv _kerberos._tcp.dc._msdcs.example.com
host -t srv _ldap._tcp.ad.example.com
host -t srv _ldap._tcp.dc._msdcs.example.com

    host ad.example.com
host <dc_name>.ad.example.com

    Do this both against the DC itself as a DNS server, and against the company's regular network-wide DNS server.

    There's probably a dcdiag.exe or something that does this for Windows.

grawity
  • 501,077