I received an email the likes of which I have seen a few times over the last few years and figured I would share the issue and my response.
The issue is someone who has a bunch of machines scattered around a very large environment and they really don’t know what domain those machines are in, if any. Now I expect there are folks out there reading this who are absolutely incredulous over the fact that you could have machines in the environment and not even know if they are in a domain or if they are in a domain, what domain that might be. Unfortunately I have to say that that happens rather regularly in the larger environments where you have hundreds if not thousands of machines and you actually, I am not lying, have even tens or hundreds of domains laying about the network.
There will be machines in the environment and actually forgotten for years once the person who was responsible for them moves on or gets fired or whatever. I recall once that I found a very super high powered server (Quad Proc when even a Dual Proc was pretty darn cool) that was probably 5-10 times more powerful than most of the stuff I got to use that was just sitting and spinning idle. Had been in that state for over three years. Someone had a hot project that needed a hot server, they paid for it up front, it got deployed, then something happened and the project died and no one came and reclaimed it. It wasn’t listed in any of the standard support databases, not in AD, nothing. I only found it because it was infected with something and beating the network up trying to infect other machines.
Anyway, the basic problem is, say you have an IP or a resolvable machine name but you don’t know what domain that machine is part of and need to determine that info remotely. Yes, I know the quick answer is, well whatever the domain suffix it has on it, that is the domain it is part of. That is the quick answer, but it could very likely be the wrong answer. There is no rule that states a machine has to be a member of a given domain in order to have that domain as its DNS suffix.
The quickest and easiest solution I am aware of kind of old school and will slowly become less and less useful. The idea is to enumerate the NetBIOS Name table for the machine and work out what the records are. Obviously, machine based firewalls and turning off NetBIOS can impact this, both of which are becoming more common and why I said this idea will slowly become less and less useful.
Here are some examples:
G:\>nbtstat -a joeware-dc1
Local Area Connection:
Node IpAddress: [192.168.0.122] Scope Id: []NetBIOS Remote Machine Name Table
Name Type Status
———————————————
JOEWARE-DC1 <00> UNIQUE Registered
JOEWARE <00> GROUP Registered
JOEWARE <1C> GROUP Registered
JOEWARE-DC1 <20> UNIQUE Registered
JOEWARE <1B> UNIQUE Registered
JOEWARE <1E> GROUP Registered
JOEWARE <1D> UNIQUE Registered
..__MSBROWSE__.<01> GROUP RegisteredMAC Address = 00-0C-29-F4-7B-5E
Note if you had the IP you would use NBSTAT -A IPADDRESS (note the cap –A switch)
From that name table you can see that this machine has the <00> and <1E> group records for JOEWARE which means it is a member of the JOEWARE domain. Not only that, but it also has a <1C> group record for JOEWARE which means it is a domain controller for JOEWARE…. And not only that… It has a <1B> record for JOEWARE which means it is the PDC for JOEWARE. The only catch here is… JOEWARE is a NetBIOS name, the DNS name could be anything. Thankfully since it is a DC, you can (assuming not Windows NT) query the RootDSE and get more data like so:
G:\>adfind -h joeware-dc1 -rootdseanon
AdFind V01.41.00cpp Joe Richards (joe@joeware.net) February 2010
Using server: JOEWARE-DC1.joeware.local:389
Directory: Windows Server 2003dn:
>currentTime: 20101123194337.0Z
>subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=joeware,DC=local
>dsServiceName: CN=NTDS Settings,CN=JOEWARE-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=joeware,DC=local
>namingContexts: DC=joeware,DC=local
>namingContexts: CN=Configuration,DC=joeware,DC=local
>namingContexts: CN=Schema,CN=Configuration,DC=joeware,DC=local
>namingContexts: DC=DomainDnsZones,DC=joeware,DC=local
>namingContexts: DC=ForestDnsZones,DC=joeware,DC=local
>defaultNamingContext: DC=joeware,DC=local
>schemaNamingContext: CN=Schema,CN=Configuration,DC=joeware,DC=local
>configurationNamingContext: CN=Configuration,DC=joeware,DC=local
>rootDomainNamingContext: DC=joeware,DC=local
>supportedControl: 1.2.840.113556.1.4.319 [LDAP_PAGED_RESULT_OID_STRING]
>supportedControl: 1.2.840.113556.1.4.801 [LDAP_SERVER_SD_FLAGS_OID]
>supportedControl: 1.2.840.113556.1.4.473 [LDAP_SERVER_SORT_OID]
>supportedControl: 1.2.840.113556.1.4.528 [LDAP_SERVER_NOTIFICATION_OID]
>supportedControl: 1.2.840.113556.1.4.417 [LDAP_SERVER_SHOW_DELETED_OID]
>supportedControl: 1.2.840.113556.1.4.619 [LDAP_SERVER_LAZY_COMMIT_OID]
>supportedControl: 1.2.840.113556.1.4.841 [LDAP_SERVER_DIRSYNC_OID]
>supportedControl: 1.2.840.113556.1.4.529 [LDAP_SERVER_EXTENDED_DN_OID]
>supportedControl: 1.2.840.113556.1.4.805 [LDAP_SERVER_TREE_DELETE_OID]
>supportedControl: 1.2.840.113556.1.4.521 [LDAP_SERVER_CROSSDOM_MOVE_TARGET_OID]
>supportedControl: 1.2.840.113556.1.4.970 [LDAP_SERVER_GET_STATS_OID]
>supportedControl: 1.2.840.113556.1.4.1338 [LDAP_SERVER_VERIFY_NAME_OID]
>supportedControl: 1.2.840.113556.1.4.474 [LDAP_SERVER_RESP_SORT_OID]
>supportedControl: 1.2.840.113556.1.4.1339 [LDAP_SERVER_DOMAIN_SCOPE_OID]
>supportedControl: 1.2.840.113556.1.4.1340 [LDAP_SERVER_SEARCH_OPTIONS_OID]
>supportedControl: 1.2.840.113556.1.4.1413 [LDAP_SERVER_PERMISSIVE_MODIFY_OID]
>supportedControl: 2.16.840.1.113730.3.4.9 [LDAP_CONTROL_VLVREQUEST]
>supportedControl: 2.16.840.1.113730.3.4.10 [LDAP_CONTROL_VLVRESPONSE]
>supportedControl: 1.2.840.113556.1.4.1504 [LDAP_SERVER_ASQ_OID]
>supportedControl: 1.2.840.113556.1.4.1852 [LDAP_SERVER_QUOTA_CONTROL_OID]
>supportedControl: 1.2.840.113556.1.4.802 [LDAP_SERVER_RANGE_OPTION_OID]
>supportedControl: 1.2.840.113556.1.4.1907 [LDAP_SERVER_SHUTDOWN_NOTIFY_OID]
>supportedControl: 1.2.840.113556.1.4.1948 [LDAP_SERVER_RANGE_RETRIEVAL_NOERR]
>supportedLDAPVersion: 3
>supportedLDAPVersion: 2
>supportedLDAPPolicies: MaxPoolThreads
>supportedLDAPPolicies: MaxDatagramRecv
>supportedLDAPPolicies: MaxReceiveBuffer
>supportedLDAPPolicies: InitRecvTimeout
>supportedLDAPPolicies: MaxConnections
>supportedLDAPPolicies: MaxConnIdleTime
>supportedLDAPPolicies: MaxPageSize
>supportedLDAPPolicies: MaxQueryDuration
>supportedLDAPPolicies: MaxTempTableSize
>supportedLDAPPolicies: MaxResultSetSize
>supportedLDAPPolicies: MaxNotificationPerConn
>supportedLDAPPolicies: MaxValRange
>highestCommittedUSN: 741310
>supportedSASLMechanisms: GSSAPI
>supportedSASLMechanisms: GSS-SPNEGO
>supportedSASLMechanisms: EXTERNAL
>supportedSASLMechanisms: DIGEST-MD5
>dnsHostName: JOEWARE-DC1.joeware.local
>ldapServiceName: joeware.local:joeware-dc1$@JOEWARE.LOCAL
>serverName: CN=JOEWARE-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=joeware,DC=local
>supportedCapabilities: 1.2.840.113556.1.4.800 [LDAP_CAP_ACTIVE_DIRECTORY_OID]
>supportedCapabilities: 1.2.840.113556.1.4.1670 [LDAP_CAP_ACTIVE_DIRECTORY_V51_OID]
>supportedCapabilities: 1.2.840.113556.1.4.1791 [LDAP_CAP_ACTIVE_DIRECTORY_LDAP_INTEG_OID]
>dsSchemaAttrCount: 1980
>dsSchemaClassCount: 361
>dsSchemaPrefixCount: 47
>isSynchronized: TRUE
>isGlobalCatalogReady: TRUE
>supportedConfigurableSettings: DynamicObjectDefaultTTL
>supportedConfigurableSettings: DynamicObjectMinTTL
>supportedConfigurableSettings: DisableVLVSupport
>supportedExtension: 1.3.6.1.4.1.1466.20037 [LDAP_SERVER_START_TLS_OID]
>supportedExtension: 1.3.6.1.4.1.1466.101.119.1 [LDAP_TTL_REFRESH_OID]
>supportedExtension: 1.2.840.113556.1.4.1781 [LDAP_SERVER_FAST_BIND_OID]
>domainFunctionality: 2 [Windows Server 2003 Domain Mode]
>forestFunctionality: 2 [Windows Server 2003 Forest Mode]
>domainControllerFunctionality: 2 [Windows Server 2003 Mode]
>validFSMOs: CN=Schema,CN=Configuration,DC=joeware,DC=local
>validFSMOs: CN=Partitions,CN=Configuration,DC=joeware,DC=local
>validFSMOs: DC=joeware,DC=local
>validFSMOs: CN=Infrastructure,DC=joeware,DC=local
>validFSMOs: CN=RID Manager$,CN=System,DC=joeware,DC=local1 Objects returned
That extra info, available because it is a DC, really lets us know what is going on with that machine. Best of all, it is all anonymous, no need for creds if you even knew what creds to use… In fact, the reason for this exercise could be to try and ascertain what ID you should be using.
Unfortunately, a machine that isn’t a DC isn’t quite as helpful but perhaps it does give enough info.
G:\>nbtstat -a mbx01
Local Area Connection:
Node IpAddress: [192.168.0.122] Scope Id: []NetBIOS Remote Machine Name Table
Name Type Status
———————————————
MBX01 <00> UNIQUE Registered
JOEWARE <00> GROUP Registered
MBX01 <20> UNIQUE Registered
JOEWARE <1E> GROUP RegisteredMAC Address = 00-0C-29-64-4D-D7
The <00> and <1E> Group records again tell you the domain, but that is about all you get out of this one. Occasionally you will find that if you portscan the machine, you will find a port for some common service, say SMTP that may give you more info, that can be enough to get you going in the right direction.
Overall, I see this issue getting more and more difficult to handle as we move forward and lock machines down. It has made me recommend to some people that maybe their standard OS loads should have some sort of beacon type functionality in place. If you hit the server on the right port with some simple string, say IDENTIFY, it responds with some basic info about the machine. That port and command would be maintained in a very stringent manner and well tested for string length etc so it doesn’t later become an Achilles heel for the machine but could be very useful for larger orgs that just for the life of them can’t seem to get a handle on stray machines in the environment.
joe
