Exploring Active Directory with Free Software

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

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:

# 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 (...)

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 “ptijo@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:

# ldapsearch -h dc01.tumfatig.local. -b "CN=Subnets,CN=Sites,CN=Configuration,dc=tumfatig,dc=local" -D "ptijo@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 (...)

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:

# # ldapsearch -h dc01.tumfatig.local. -b "CN=Services,CN=Configuration,DC=tumfatig,DC=local" -D "ptijo@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 (...)

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:

# ldapsearch -h dc01.tumfatig.local. -b "CN=Services,CN=Configuration,DC=tumfatig,DC=local" -D "ptijo@tumfatig.local" -W -s one '(objectClass=container)' CN

Server list

To get an overview of the Exchange architecture, we’ll have a look at the Exchange servers them-selves:

# ldapsearch -h dc01.tumfatig.local. -b "CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=tumfatig,DC=local" -D "ptijo@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 (...)

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:

# # ldapsearch -h dc01.tumfatig.local. -b "DC=tumfatig,DC=local" -D "ptijo@tumfatig.local" -W '(mail=ptijo@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 (...)

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:

# ldapsearch -h dc01.tumfatig.local. -b "CN=Services,CN=Configuration,DC=tumfatig,DC=local" -D "ptijo@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 (...)

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:

# ldapsearch -h dc01.tumfatig.local. -b "CN=System,DC=tumfatig,DC=local" -D "ptijo@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 (...)

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:

# ldapsearch -h dc01.tumfatig.local. -b "DC=tumfatig,DC=local" -D "ptijo@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$ (...)

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:

# smbtree -S -N WORKGROUP \\VISITOR-PC TUMFATIG \\DC01 Active Directory #1 \\FILER03 File server #3 \\TMF-ADMIN # smbclient -L FILER03 -U ptijo -W tumfatig.local Enter ptijo'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

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.

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

*

%d bloggers like this: