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.