How Do I Connect to Active Directory Server Behind a Firewall

7,411

Don't open services on your domain controllers to the Internet. Configure a VPN between your digital ocean footprint and your on-prem Active Directory and query AD over the VPN.

Share:
7,411
Kismet Agbasi
Author by

Kismet Agbasi

Updated on September 18, 2022

Comments

  • Kismet Agbasi
    Kismet Agbasi over 1 year

    I'm having trouble getting LDAP queries to reach my Active Directory running on Windows Server 2012 R2 behind a Cisco PIX 506E firewall. My goal is to create a SSO environment for some applications that are hosted in the cloud (on Digital Ocean). I have full control of the entire network path to the server, and I have opened ports 389 (LDAP) and 636 (LDAPS) on the PIX and added a static statement to forward the LDAP traffic to the AD server. As I will show below, I'm getting a hit count on the firewall access-list each time I attempt to make a connection, but I am unsuccessful.

    Here's what I have done so far:

    1. Opened LDAP and LDAPS ports on Firewall

    fw1(config)# show access-list
    access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 1024)
                alert-interval 300
    access-list inbound; 4 elements
    access-list inbound line 1 permit icmp any any (hitcnt=383)
    access-list inbound line 2 permit udp any interface outside eq 1194 (hitcnt=3)
    access-list inbound line 3 permit tcp any any eq ldap (hitcnt=6)
    access-list inbound line 4 permit tcp any any eq ldaps (hitcnt=1)
    

    2. Port Forwarded the LDAP Traffic

    fw1(config)# show static
    static (inside,outside) udp interface 1194 172.23.6.148 1194 netmask 255.255.255.255 0 0
    static (inside,outside) tcp interface ldap 172.23.6.127 ldap netmask 255.255.255.255 0 0
    static (inside,outside) tcp interface ldaps 172.23.6.127 ldaps netmask 255.255.255.255 0 0
    

    3. Turned off firewall on the AD Server

    Screenshot showing that Windows Firewall is off on the AD server

    4. Used Microsoft's PortQuery Tool to test if the LDAP ports are really open

    PortQuery GUI test results

    5. Used netstat to verify that the AD server is actually listening on port 389

    NetStat command to verify that LDAP ports are listening for queries

    At this point I feel like I'm not doing something right on the firewall. Although I have a similar setup for an OpenVPN server and that's working fine (i.e., the ACL and Static statements are getting traffic through the firewall to the OpenVPN server successfully).

    I'm willing to provide any additional information needed to help me solve this, thanks.

    PS. Below is the config of my PIX firewall.

    fw1(config)# sho conf
    : Saved
    : Written by enable_15 at 22:16:51.652 EST Sat Oct 25 2014
    PIX Version 6.3(5)
    interface ethernet0 auto
    interface ethernet1 auto
    nameif ethernet0 outside security0
    nameif ethernet1 inside security100
    enable password ***** encrypted
    passwd ***** encrypted
    hostname fw1
    domain-name ctc.local
    clock timezone EST -5
    fixup protocol dns maximum-length 512
    fixup protocol ftp 21
    fixup protocol h323 h225 1720
    fixup protocol h323 ras 1718-1719
    fixup protocol http 80
    fixup protocol rsh 514
    fixup protocol rtsp 554
    fixup protocol sip 5060
    fixup protocol sip udp 5060
    no fixup protocol skinny 2000
    fixup protocol smtp 25
    fixup protocol sqlnet 1521
    fixup protocol tftp 69
    names
    access-list inbound permit icmp any any
    access-list inbound permit udp any interface outside eq 1194
    access-list inbound permit tcp any interface outside eq 1194
    access-list inbound permit tcp any any eq ldap
    access-list inbound permit udp any any eq 389
    pager lines 24
    logging monitor notifications
    logging buffered debugging
    icmp permit any outside
    icmp permit any inside
    mtu outside 1500
    mtu inside 1500
    ip address outside MY_PUBLIC_IP 255.255.255.248
    ip address inside 172.23.6.120 255.255.255.0
    ip audit info action alarm
    ip audit attack action alarm
    pdm location 172.23.6.0 255.255.255.0 inside
    pdm logging informational 100
    pdm history enable
    arp timeout 14400
    global (outside) 1 interface
    nat (inside) 1 172.23.6.0 255.255.255.0 0 0
    static (inside,outside) udp interface 1194 172.23.6.148 1194 netmask 255.255.255.255 0 0
    static (inside,outside) tcp interface ldap 172.23.6.127 ldap netmask 255.255.255.255 0 0
    access-group inbound in interface outside
    route outside 0.0.0.0 0.0.0.0 ISP_ROUTER_IP 1
    timeout xlate 0:05:00
    timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
    timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
    timeout sip-disconnect 0:02:00 sip-invite 0:03:00
    timeout uauth 0:05:00 absolute
    aaa-server TACACS+ protocol tacacs+
    aaa-server TACACS+ max-failed-attempts 3
    aaa-server TACACS+ deadtime 10
    aaa-server RADIUS protocol radius
    aaa-server RADIUS max-failed-attempts 3
    aaa-server RADIUS deadtime 10
    aaa-server LOCAL protocol local
    http server enable
    http 192.168.1.0 255.255.255.0 inside
    http 172.23.6.0 255.255.255.0 inside
    no snmp-server location
    no snmp-server contact
    snmp-server community public
    snmp-server enable traps
    floodguard enable
    telnet timeout 5
    ssh 172.23.6.0 255.255.255.0 inside
    ssh 172.23.7.0 255.255.255.0 inside
    ssh timeout 60
    console timeout 0
    dhcpd lease 3600
    dhcpd ping_timeout 750
    dhcpd auto_config outside
    terminal width 80
    Cryptochecksum:****
    
    • joeqwerty
      joeqwerty over 9 years
      At this point I feel like I'm not doing something right on the firewall - You're not doing something right. First, don't do it this way, use a VPN as MDMarra stated in his answer. Second if you insist on doing it this way then you're going to need more than just LDAP traffic to pass through. - technet.microsoft.com/en-us/library/dd772723(v=ws.10).aspx
    • Kismet Agbasi
      Kismet Agbasi over 9 years
      Thanks, I will follow MDMarra's suggestion. Thanks also for providing the article on Technet, I'll check that out too.
  • Kismet Agbasi
    Kismet Agbasi over 9 years
    Thanks. I just got home and I'll test your suggestion to see how that works out. I'll report back my findings shortly.
  • Kismet Agbasi
    Kismet Agbasi over 9 years
    Thanks for your suggestion again. I did some research and discovered that I could use Tinc to create a VPN between my cloud and on-premise servers. I've been able to set it up, but I can't ping any of the LAN IPs at the local site. So that's what I'm battling now, in case you can offer some pointers. Thanks.