Validate IP addresses and the systems are reachable on the network
Getting Started - The Preparatory Steps
To keep the discussion easy to understand and replicate, we will use an example, and set out the process in ordered sequence of steps. We will also include steps for validating to ensure if any of the steps may not have been correctly taken.
In our example
We are using a Linux based host for deploying our Kerberos based SafeSquid
- FQDN of our Linux host: sabproxy.safesquid.test
- IP address of our Linux host: 192.168.221.222
We have a Microsoft Windows AD setup
- FQDN of Microsoft AD Domain: safesquid.test
- FQDN of Domain Controller: ad.safesquid.test
- IP address of our Domain Controller: 192.168.221.1
We will use additionally use a Windows Desktop, just for the purpose of validating our efforts.
- FQDN of our Windows Test Desktop: windows7.safesquid.test
- IP address of our Windows Test Desktop: 192.168.221.212
Linux machine | sabproxy.safesquid.test | 192.168.221.222 |
Windows Active Directory | ad.safesquid.test | 192.168.221.1 |
Windows Test machine | windows7.safesquid.test | 192.168.221.212 |
Network Connectivity
On EACH of the 3 above computers do the following
- ping the Linux host IP address
- ping the Domain Controller IP address
- ping the Windows Test Desktop IP address
Run below commands on linux console(putty)
ping 192.168.221.222
ping 192.168.221.1
ping 192.168.221.212
If any of the above seems to be unsatisfactory, fix the TCP/IP network configurations, before proceeding.
Validate that all our systems are using the same DNS provider
In a Microsoft AD based network, it is highly recommended to use the DNS provider that usually defaults to the Domain Controller itself.
On the Windows Systems these are specified in the TCP/IP configuration
On the Linux host view and confirem /etc/resolv.conf
Confirm that it reads as follows:
Run below command on linux console (putty)
vim /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 search safesquid.test |
On EACH of 3 systems use nslookup as follows to confirm that DNS is effectively serving our requirements.
Run below commands on linux console
nslookup sabproxy.safesquid.test nslookup ad.safesquid.test nslookup windows7.safesquid.test
|
root@sabproxy:~# Non-authoritative answer: root@sabproxy:~# Non-authoritative answer: |
If any of the above seems to be unsatisfactory, fix the DNS server configuration, by restarting the service or re-booting the Domain Controller host, before proceeding.
root@sabproxy:~#
|
If you face any issue as shown above, check monit service and verify
While doing configuration for SSO authentication if you give FQDN\IP in this format and select Bind method as "Negotiate"
SafeSquid will create the stub zone for DNS resolution of your Active Directory server.
After completing the entire configuration when you save the entry, the file with stub zone will create with the name : safesquid.dns.conf (automatically)
An given path :(verify it)
/usr/local/safesquid/security/dns
Also it will automatically copy at given path:(verify it)
/etc/bind/
(Note: Monit service must be running)
root@sabproxy:/usr/local/safesquid/security/dns# zone safesquid.test { root@sabproxy:/etc/bind# zone safesquid.test { |
If safesquid.dns.conf is empty, configure LDAP for SSO authentication from SafeSquid Web GUI LINK properly and then do above steps again to verify.
Note: Monit service should be running.
Validate each of the systems has same time and preferably timezone
Ensure that the time synchronization remains same across all the 3 system.
Confirm time synchronization using below command (use the IP address or the FQDN )
root@sabproxy:~# root@sabproxy:~# |