... | ... | @@ -3,6 +3,7 @@ |
|
|
So, you kinda sorta got it working, but it's not doing what you want... or it's just flat out failing. Here's how to replicate what's going on manually to find out where things have gone awry.
|
|
|
|
|
|
***1. SRV Records***
|
|
|
|
|
|
The first thing NoMAD does is attempt to look up your AD Domain Controllers via a DNS lookup for any LDAP SRV records. For the following examples we'll be using "company.com" as your AD domain and "server.company.com" as your AD Domain Controller. If you're playing along at home, swap your real information in for these examples.
|
|
|
|
|
|
```dig +short -t SRV _ldap._tcp.company.com```
|
... | ... | @@ -10,6 +11,7 @@ The first thing NoMAD does is attempt to look up your AD Domain Controllers via |
|
|
Will query DNS for any LDAP SRV records. If you don't get any results this means you're a) not able to reach your corporate AD domain, at which point it's probably a VPN issue or general network issue, b) you can't get any DNS resolution for your domain. Make sure you're using the expected DNS servers, or that you can actually reach your internal network.
|
|
|
|
|
|
***2. Kerberos Login***
|
|
|
|
|
|
Once you've gotten some results of the SRV lookup, the next step is to attempt to get a Kerberos ticket with an AD username and password.
|
|
|
|
|
|
```kinit user@COMPANY.COM```
|
... | ... | @@ -19,6 +21,7 @@ No news is good new here, but you can test to ensure it worked by using the ```k |
|
|
If this doesn't work it's most likely that you again can't reach any of the AD Domain Controllers.
|
|
|
|
|
|
***3. LDAP Queries***
|
|
|
|
|
|
If you were able to login via Kerberos, you can try looking up information via LDAP.
|
|
|
|
|
|
Use any of the servers that you find via the ```dig``` command in the first step and attempt to do an LDAP query against it.
|
... | ... | |