LeeM's questions

I have an AD environment and in ldapsearch, I am able to use SRV records in DNS to resolve the LDAP servers in the domain and in a site.

This works great on the usual ldap port on 389, with basic auth and STARTTLS.

However, some horrible clients won't do STARTTLS, or the vendor is unable to provide a method to configure it.[1] So we need to provide an option for LDAPS on 636.

In principle, I belive that creating ldaps SRV records and using the ldaps:/// URI should work. I've created 2 ldaps SRV records in the domain zone (there are 3 ldap hosts), but when I do ldapsearch and specify ldaps:///, all it's discovering are the ldap hosts.

Here's the ldapsearch command - here it's returning three DCs with _ldap SRVs on port 389

$ ldapsearch -v -H "ldaps:///dc%3Devl%2Cdc%3Dexample%2Cdc%3Dcom" -D "user" -W -b "DC=evl,DC=example,DC=com" -b "" -s base "(objectclass=*)" -d 1

ldap_url_parse_ext(ldaps:///dc%3Devl%2Cdc%3Dexample%2Cdc%3Dcom)
ldap_initialize( ldaps://EVLADC002vs.evl.example.com:389 ldaps://EVLADC001vs.evl.example.com:389 ldaps://EVLADC006vs.evl.example.com:389 )
ldap_create
ldap_url_parse_ext(ldaps://EVLADC006vs.evl.example.com:389)
ldap_url_parse_ext(ldaps://EVLADC001vs.evl.example.com:389)
ldap_url_parse_ext(ldaps://EVLADC002vs.evl.example.com:389)

However, the client machine can resolve the two SRVs for _ldaps, with port 636

$ dig -t SRV _ldaps._tcp.evl.example.com +short
0 100 636 EVLADC002vs.evl.example.com.
0 100 636 EVLADC001vs.evl.example.com.

Here's the LDAP SRV for comparision

$ dig -t SRV _ldap._tcp.evl.example.com +short
0 100 389 EVLADC001vs.evl.example.com.
0 100 389 EVLADC006vs.evl.example.com.
0 100 389 EVLADC002vs.evl.example.com.

If I query a specific server on ldaps, everything is fine

$ ldapsearch -H ldaps://evladc001vs.evl.example.com -D "user" -W -b "" -s base "(objectclass=*)"
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#

#
dn:
currentTime: 20200213045340.0Z
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=evl,DC=example,DC=com
dsServiceName: CN=NTDS Settings,CN=EVLADC001VS,CN=Servers,CN=Server,CN=Sites,CN=Configuration,DC=evl,DC=example,DC=com
...  

I'd appreciate any advice on whether I'm missing some option or something else obvious re this issue.

[1]: Please don't start with lectures about using different products. Large enterprises have integration issues no matter what - try telling hospital systems to purchase different multimillion dollar software for their specific requirements

We've found the domain Administrator account - which we do not use except in the event of a disaster recovery scenario - has a recent date in the LastLogonTimeStamp attribute. As far as I am aware, no-one should have used this account in the time period concerned (and several months beyond), but maybe some idiot has configured it to run a scheduled task.

Due to the quantity of security log events (and lack of SIEM tool for analysis), I wanted to determine which DC had the actual lastLogon time (i.e. not the replicated attribute) for the account, but I have queried every DC in the domain, and they each have a lastLogon of "none" for Administrator.

This is a child domain in the forest, so it's possible that someone has used this child domain Administrator account to run something in the parent domain.

Can anyone think of a way to determine which DC is doing the logon other than examining the potential 20 million events from 16 forest DCs around the time recorded in LastLogonTimestamp? I suppose I could target the parent domain DCs first (as the child DCs seem not to have done the auth).

Explanation

[Added after zeroing in on the cause after using repadmin per the below]

The original reason for this request was due to our IT Security team, who were wondering why we were apparently logging on with the default domain Administrator account on a frequent basis.

We knew that WE weren't logging it on. It turns out that there is a mechanism called "Kerberos S4u2Self" that's when a calling process running as Local System is doing some privilege escalation. It does a network logon (not interactive) as Administrator on a domain controller. As it's non-interactive, this is why there's no lastLogon for the account on any DC (this account had never been logged onto any current domain controller).

This article explains why the thing pings your logs and makes your security team have kittens (the source machines are Server 2003, to make things worse). And how to track it down. https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/

Lesson learned - only provide reports on lastLogon attributes to IT security teams when it concerns Administrator logons.

We're about to commence an AD upgrade to 2012 R2, and I have just found to my horror that anonymous LDAP binds have been enabled in the 2003 domain.

We've certainly been issuing accounts for LDAP auth to non-Windows systems by policy, but before disabling the anonymous bind, we should probably do some due diligence to ensure no-one's just taking the anonymous shortcut.

Any suggestions has to how to audit anonymous operations in LDAP? Obviously it's possible to enable AD debug diagnostic logging, or perhaps use a tool like ADInsight, but I would have no idea what events to filter for.

I'm having this issue with two Server 2008 R2 domain member servers built as VMWare guests. The DCs built at the same time do not have this issue.

When I try to ping 127.0.0.1 (or "localhost") when logged on with a domain (admin) account, I get an error saying "Unable to contact IP driver. General failure." However, if I'm logged on as the local Administrator account, it works fine.

I've tried resetting the TCP/IP stack with netsh int ip reset and rebooting. Makes no difference.

However, pinging the default gateway, its own IP and other hosts are just fine as the domain user.

Any pointers?