Exploring Active Directory with Free Software
1376 words, 7 minutes
In an Active Directory environments, you have (Windows) computers joined to a domain that does a lot a magic to allow you to use services without really thinking of it. You have Network Browsing, Exchange auto discovery…
I’m going to use general I.T. tools to explore the Active Directory and guess what we can connect to with our non-Microsoft system.
DNS, DHCP, Active Directory
First of all, I’ll assume we get access to the LAN. Remember, we’re not hacking the network ; just trying to discover the Microsoft services that’d be automatically configured if we were using an MS workstation.
If the network you’re on enables DHCP, then check your IP and naming configuration:
# ifconfig -a
(...)
inet 192.168.0.103 netmask 0xffffff00 broadcast 192.168.0.25
(...)
# cat /etc/resolv.conf
domain tumfatig.local
nameserver 192.168.0.1
nameserver 172.16.1.1
nameserver 172.16.2.1
</p>```
If DHCP is not enabled, then your IT guy should have given you those informations.
From such information, we can guess than the Active Directory domain name is "tumfatig.local", that a DNS server (probably a Domain Controller) is located on ".0.1" and that there might be 3 AD sites (networks) around.
Now, let's try to find and connect to the DC:
```<p>
# dig srv _ldap._tcp.tumfatig.local
(...)
;; ANSWER SECTION:
_ldap._tcp.tumfatig.local. 600 IN SRV 0 100 389 dc01.tumfatig.local.
_ldap._tcp.tumfatig.local. 600 IN SRV 0 100 389 dc02.tumfatig.local.
_ldap._tcp.tumfatig.local. 600 IN SRV 0 100 389 dc03.tumfatig.local.
(...)
;; ADDITIONAL SECTION:
dc01.tumfatig.local. 3600 IN A 192.168.0.1
dc02.tumfatig.local. 3600 IN A 172.16.1.1
dc03.tumfatig.local. 3600 IN A 172.16.2.1
(...)
</p>```
We can see that those DNS servers we got from DHCP also have the domain controller (DC) role. Domain controllers are "no more" than (complex) LDAP servers. To discover more of the available IT services, we're gonna switch to using LDAP tools. To connect to the DC, we'll have to use the credential we (must) have been given. As an example, my login would be "jdoe@tumfatig.local" and password "very complicated".
# Active Directory sites
We saw there were 3 different DCes located in 3 different networks. Let's confirm that there are AD sites configured round there. That should be useful because in Microsoft way-of-thinking, sites are "where the close services are".
The Active Directory sites are listed using LDAP tools:
```<p>
# ldapsearch -h dc01.tumfatig.local. -b "CN=Subnets,CN=Sites,CN=Configuration,dc=tumfatig,dc=local" -D "jdoe@tumfatig.local" -W siteObject
(...)
# Subnets, Sites, Configuration, tumfatig.local
dn: CN=Subnets,CN=Sites,CN=Configuration,DC=tumfatig,DC=local
# 192.168.0.0/24, Subnets, Sites, Configuration, tumfatig.local
dn: CN=192.168.0.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC=tumfatig,DC=local
siteObject: CN=site1,CN=Sites,CN=Configuration,DC=tumfatig,DC=local
# 172.16.1.0/24, Subnets, Sites, Configuration, tumfatig.net
dn: CN=172.16.1.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC=tumfatig,DC=local
siteObject: CN=site2,CN=Sites,CN=Configuration,DC=tumfatig,DC=local
# 172.16.2.0/24, Subnets, Sites, Configuration, tumfatig.local
dn: CN=172.16.2.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC=tumfatig,DC=local
siteObject: CN=site3,CN=Sites,CN=Configuration,DC=tumfatig,DC=local
# search result
(...)
</p>```
Correct guess, there are 3 Active Directory sites. And from my IP address, I know to which site I belong.
# Exchange server
Should there be an Exchange server around, we'll find it in Active Directory because this is were all Microsoft services are registered:
```<p>
# # ldapsearch -h dc01.tumfatig.local. -b "CN=Services,CN=Configuration,DC=tumfatig,DC=local" -D "jdoe@tumfatig.local" -W 'CN=Microsoft Exchange'
(...)
# Microsoft Exchange, Services, Configuration, tumfatig.local
dn: CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=tumfatig,DC=local
objectClass: top
objectClass: container
objectClass: msExchConfigurationContainer
cn: Microsoft Exchange
(...)
</p>```
I am not sure if this CN is correct for any Exchange version. I know the one here is Exchange 2010. In case it does not exist, the trick is to watch every "CN" reference from "CN=Services,CN=Configuration". It should be self-explaining:
```<p>
# ldapsearch -h dc01.tumfatig.local. -b "CN=Services,CN=Configuration,DC=tumfatig,DC=local" -D "jdoe@tumfatig.local" -W -s one '(objectClass=container)' CN
</p>```
## Server list
To get an overview of the Exchange architecture, we'll have a look at the Exchange servers them-selves:
```<p>
# ldapsearch -h dc01.tumfatig.local. -b "CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=tumfatig,DC=local" -D "jdoe@tumfatig.local" -W '(objectClass=server)' CN Name serialNumber msExchServerSite msExchCurrentServerRoles
(...)
cn: CAS01
serialNumber: Version 14.0 (Build 30639.21)
name: CAS01
msExchCurrentServerRoles: 4
msExchServerSite: CN=site2,CN=Sites,CN=Configuration,DC=tumfatig,DC=local
(...)
cn: HUB01
serialNumber: Version 14.0 (Build 30639.21)
name: HUB01
msExchCurrentServerRoles: 32
msExchServerSite: CN=site2,CN=Sites,CN=Configuration,DC=tumfatig,DC=local
(...)
cn: MBOX01
serialNumber: Version 14.0 (Build 30639.21)
name: MBOX01
msExchCurrentServerRoles: 2
msExchServerSite: CN=site2,CN=Sites,CN=Configuration,DC=tumfatig,DC=local
(...)
cn: XCH03
serialNumber: Version 14.0 (Build 30639.21)
name: XCH03
msExchCurrentServerRoles: 38
msExchServerSite: CN=site3,CN=Sites,CN=Configuration,DC=tumfatig,DC=local
(...)
</p>```
What we can see here is that there's no Exchange server on my local site and that there seem to be some fallback service on the third site. You can get the exact server's role from the How to Recover a Lost Exchange Server article:
| Server role | Role value |
| ------------------------ | ---------- |
| Mailbox role | 2 |
| Client Access role (CAS) | 4 |
| Unified Messaging role | 16 |
| Hub Transport role | 32 |
| Edge Transport role | 64 |
## Mailbox server
According to the previous listing, my mailbox server must be MBOX01. We can verify by looking at our user object:
```<p>
# # ldapsearch -h dc01.tumfatig.local. -b "DC=tumfatig,DC=local" -D "jdoe@tumfatig.local" -W '(mail=jdoe@tumfatig.local)' homeMTA homeMDB
(...)
# ptiJo, Users, tumfatig.local
dn: CN=ptiJo,OU=Users,DC=tumfatig,DC=local
homeMTA: CN=Microsoft MTA,CN=MBOX01,CN=Servers,CN=Exchange Administrati
ve Group (xxxxxxxxxxxxxxx),CN=Administrative Groups,CN=TMF,CN=Microsoft E
xchange,CN=Services,CN=Configuration,DC=tumfatig,DC=local
homeMDB: CN=Mailbox Database site2,CN=Databases,CN=Exchange Administrative Group
(xxxxxxxxxxxxxxx),CN=Administrative Groups,CN=TMF,CN=Microsoft Exchange,
CN=Services,CN=Configuration,DC=tumfatig,DC=local
(...)
</p>```
Now, we have it. We can try using SMTP(s)/IMAP(s) or MAPI compatible mail client.
## Webmail (OWA) URL
Most of the time, you can't connect to Exchange with anything else than Outlook (or mobile phones). The rescue option is to use Outlook Web Access. We have seen a "Client Access role" on the CAS01 server. We'll use a Web browser to connect to this server, probably in HTTPS, with an URL ending with "/owa/". In my example, I went for https://cas01.tumfatig.local/owa/. Bingo!
In newer Exchange version, there's also an "auto discover" feature available to Outlook mail client. The information is stored in the Active Directory:
```<p>
# ldapsearch -h dc01.tumfatig.local. -b "CN=Services,CN=Configuration,DC=tumfatig,DC=local" -D "jdoe@tumfatig.local" -W '(objectClass=serviceConnectionPoint)' serviceBindingInformation
(...)
# CAS01, Autodiscover, Protocols, CAS01, Servers, Exchange Administrative Group (xxxxxxxxxxxxxxx), Administrative Groups, TMF, Microsoft Exchange, Services, Configuration, tumfatig.local
dn: CN=CAS01,CN=Autodiscover,CN=Protocols,CN=CAS01,CN=Servers, CN=Exchange Administrative Group (xxxxxxxxxxxxxxx),CN=Administrative Groups,CN=TMF,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=tumfatig,DC=local
serviceBindingInformation: https://webmail.tumfatig.local/autodiscover/autodiscover.xml
(...)
</p>```
This means that the OWA service is probably (also) available from https://webmail.tumfatig.local/owa/ too.
# File server
In the Microsoft environment, there are two kinds of file servers: the "standard" shares server and the "DFS" servers. The first is a "simple" directory sharing on a server ; same as Samba. The other is a more complex file sharing system that publishes shares without the server reference.
## Distributed File System
To get the list of published DFS shared, as usual, ask the Active Directory:
```<p>
# ldapsearch -h dc01.tumfatig.local. -b "CN=System,DC=tumfatig,DC=local" -D "jdoe@tumfatig.local" -W '(objectClass=msDFSR-ContentSet)' msDFSR-DfsPath objectGUID
(...)
# Data, Content, TMF, DFSR-GlobalSettings, System, tumfatig.local
dn: CN=Data,CN=Content,CN=TMF,CN=DFSR-GlobalSettings,CN=System,DC=tumfatig,DC=local
objectGUID:: ZLKXuJ5uX0+Ueb0MO7pf7Q==
msDFSR-DfsPath: \\tumfatig.local\shares\Data
# Users, Content, TMF, DFSR-GlobalSettings, System, tumfatig.local
dn: CN=Users,CN=Content,CN=TMF,CN=DFSR-GlobalSettings,CN=System,DC=tumfatig,DC=local
objectGUID:: lYBqbKYxBEixbA7QNh7N5A==
msDFSR-DfsPath: \\tumfatig.local\shares\Users
(...)
</p>```
With a *N?X tool, you may connect to the DFS using the following syntax `smb://tumfatig.local/shares/Users`.
The msDFSR-DfsPath entries are the "general" path that will be resolved by the DNS and dealer with the DFS system to connect to the "better" DFS server. The objectGUID is the reference that can be found on every server being able to provide the share:
```<p>
# ldapsearch -h dc01.tumfatig.local. -b "DC=tumfatig,DC=local" -D "jdoe@tumfatig.local" -W '(objectClass=msDFSR-Subscription)' msDFSR-ContentSetGuid msDFSR-DfsLinkTarget
(...)
# 6c6a8095-31a6-4804-b16c-0ed0361ecde4, 5be06b21-e070-4155-aa3b-3a419083635f,
DFSR-LocalSettings, FILER02, DFS, tumfatig.local
dn: CN=6c6a8095-31a6-4804-b16c-0ed0361ecde4,CN=5be06b21-e070-4155-aa3b-3a419083635f,CN=DFSR-LocalSettings,CN=FILER02,OU=DFS,DC=tumfatig,DC=local
msDFSR-ContentSetGuid:: lYBqbKYxBEixbA7QNh7N5A==
msDFSR-DfsLinkTarget: \\filer02.tumfatig.local\Users$
# 6c6a8095-31a6-4804-b16c-0ed0361ecde4, 415e895e-b523-4cfa-b10b-bde7f9736b33, DFSR-LocalSettings, FILER03, DFS, tumfatig.local
dn: CN=6c6a8095-31a6-4804-b16c-0ed0361ecde4,CN=415e895e-b523-4cfa-b10b-bde7f9736b33,CN=DFSR-LocalSettings,CN=FILER03,OU=DFS,DC=tumfatig,DC=local
msDFSR-ContentSetGuid:: lYBqbKYxBEixbA7QNh7N5A==
msDFSR-DfsLinkTarget: \\filer03.tumfatig.local\Users$
(...)
</p>```
Looking at the IP addresses, we can guess which filer is on our local site, if there's any.
## Shared folders
In some cases, there are no DFS but "only" shared folder. To learn about the available shares, we'll use the SAMBA tools:
```<p>
# smbtree -S -N
WORKGROUP
\\VISITOR-PC
TUMFATIG
\\DC01 Active Directory #1
\\FILER03 File server #3
\\TMF-ADMIN
# smbclient -L FILER03 -U jdoe -W tumfatig.local
Enter jdoe's password:
Domain=[TUMFATIG] OS=[Windows Server 2003 R2 3790 Service Pack 2] Server=[Windows Server 2003 R2 5.2]
Sharename Type Comment
--------- ---- -------
Data Disk
C$ Disk Partage par défaut
IPC$ IPC IPC distant
ADMIN$ Disk Administration à distance
Users Disk
Domain=[TUMFATIG] OS=[Windows Server 2003 R2 3790 Service Pack 2] Server=[Windows Server 2003 R2 5.2]
Server Comment
--------- -------
DC01 Active Directory #1
FILER03 File server #3
TMF-ADMIN
Workgroup Master
--------- -------
WORKGROUP VISITOR-PC
</p>```
We could find the direct shared folders from the file server.
# Conclusion
That's all for this quick exploration of Active Directory. Following those directions, you can get all the information you need to configure your *N?X workstation in an Active Directory environment.
Cheers.