Tunnelling AD Traffic Using IPSec

If you don't like having to open this many ports, you could use IPSec to tunnel the traffic across the firewall. You could use ESP with encryption disabled, so the packets would still be cryptographically  signed and tunneled, but your intrusion detection systems (IDS) would still have visibility into the traffic.

Jason Fossen, who teaches the Securing Windows class at SANS, shared with us additional insights regarding the use of IPSec:

Because IPSec connections can be limited to those users and computers in specified global groups, is tightly integrated into the host-based Windows Firewall (which would be configured on all DMZ servers and participating controllers), and can optionally be tied into a Network Access Protection (NAP) infrastructure, the use of IPSec can provide benefits the perhaps outweigh the IDS/IPS hassles.

The Use of AD in the DMZ or a Screened Subnet

Jason Fossen also shared his thoughts on architecting AD in environments where some Windows servers reside close to the network's perimeter, such as in the DMZ or a screened subnet. He recommending implementing a  separate forest for DMZ servers that need to be domain members (perhaps with a one-way cross-forest trust to the internal forest), rather than joining DMZ servers to the internal forest directly. Jason continued:

The DMZ controller(s) will be located in a new perimeter network attached to a firewalling device.  When implementing a cross-forest trust, after configuring groups and permissions on the DMZ servers (which requires LDAP traffic), the only traffic that must be allowed through the firewall is Kerberos.  If the DMZ servers must be joined to the internal forest, then it’s better to place Read-Only Domain Controllers (RODC) in another perimeter network of the firewall for the sake of the DMZ servers.

Also, with the use of PKI, RADIUS, reverse proxy servers, etc., it has become less necessary to either join DMZ servers to the internal forest or to establish a one-way cross-forest trust from the DMZ forest to the internal one, even when users must authenticate with the internal forest credentials.

Required Active Directory Ports

AD-Related Ports

Active Directory communications involve a number of ports, some of which are more familiar to network and security administrators than others. These were outlined in the Active Directory Replication over Firewalls article by Steve Riley:

·         RPC endpoint mapper: port 135 TCP, UDP

·         NetBIOS name service: port 137 TCP, UDP

·         NetBIOS datagram service: port 138 UDP

·         NetBIOS session service: port 139 TCP

·         SMB over IP (Microsoft-DS): port 445 TCP, UDP

·         LDAP: port 389 TCP, UDP

·         LDAP over SSL: port 636 TCP

·         Global catalog LDAP: port 3268 TCP

·         Global catalog LDAP over SSL: port 3269 TCP

·         Kerberos: port 88 TCP, UDP

·         DNS: port 53 TCP, UDP

·         WINS resolution: port 1512 TCP, UDP

·         WINS replication: 42 TCP, UDP

·         RPC: Dynamically-assigned ports TCP, unless restricted

For a full listing of AD-related services, see Microsoft's support article 832017 Service Overview and Network Port Requirements for the Windows Server System.

Which of these ports actually need to be allowed through the firewall depends on the scenario you're implementing and on your environment. For instance, support for NetBIOS services may unnecessary in situations where you have newer Windows systems supporting the SMB over IP protocol. Similarly, newer Windows environments make use DNS, instead of Windows for name resolution.

AD Replication

The ports that need to be open to facilitate cross-firewall AD replication differ, depending on the versions of Microsoft Windows in your environment. Microsoft provides OS-specific guidelines in its Active Directory and Active Directory Domain Services Port Requirements article. For instance, replication between servers that use Windows 2000 or 2003 require the following ports open bidirectionally on the firewall that's between the servers:

·         RPC endpoint mapper: port 135 TCP

·         LDAP: port 389 TCP, UDP

·         LDAP over SSL: port 636 TCP

·         Global catalog LDAP: port 3268 TCP

·         Global catalog LDAP over SSL: port 3269 TCP

·         DNS: port 53 TCP, UDP

·         Kerberos: port 88 TCP, UDP

·         SMB over IP (Microsoft-DS): port 445 TCP

·         RPC: Dynamically-assigned ports TCP, unless restricted  

To restrict the use of RPC ports, follow instructions in Microsoft's support article 224196 Restricting Active Directory Replication Traffic and Client RPC Traffic to a Specific Port and a TechNet blog entry Dynamic Client Ports in Windows Server 2008 and Windows Vista.

Authentication to AD

AD uses the following ports to support user and computer authentication, according to the Active Directory and Active Directory Domain Services Port Requirements article:

·         SMB over IP (Microsoft-DS): port 445 TCP, UDP

·         Kerberos: port 88 TCP, UDP

·         LDAP: port 389 UDP

·         DNS: port 53 TCP, UDP

·         RPC: Dynamically-assigned ports TCP, unless restricted  

SQL Log Shipping (What is and How to Do)

It is data base level high availability feature and its one method to keep entire database in different server, from this Transactional log backup will copied and applied on schedule basis.

Pre Requisites

1.       Primary and secondary database instance should running on domain accounts

2.       Both servers must have same collation setting

3.       Primary Database must be in either FULL or Bulk-Logged recovery model

4.       All SQL edition are support (Ent, Std,)

5.       Two folders need to create BACKUPS Folder (R/W to Primary site and Read permission for secondary site and COPY/RESTORE (R/W permission for secondary site)

Advantages of Log Shipping Configuration

1.       Database High Availability – But manually we have to make it availability (15 min Downtime )

2.       Offloading Report Activities

3.       Database version upgrade very easy

Log Shipping Architecture

Log shipping consists of three main operations:

1. Back up the transaction log at the primary server instance. (BACKUP JOB)
2. Copy the transaction log file to the secondary server instance. (COPY JOB)
3. Restore the log backup on the secondary server instance. (RESTORE JOB)

The log can be shipped to multiple secondary server instances. In such cases, operations 2 and 3 are duplicated for each secondary server instance.

A log shipping configuration does not automatically fail over from the primary server to the secondary server. If the primary database becomes unavailable, any of the secondary databases can be brought online manually.

Configuring Log Shipping

1.       Create folders and grant permission

2.       Take full backup and restore in secondary server (

Manually or from wizard it can do

Restore Transaction log

3.       Secondary server database you can keep Standby mode or restore mode. (From Restoring mode – no reading and no writing access will apply

                Standby Mode with Disconnect users when restoring backups

                No Recovery Mode (Restoring Mode)

4.       Configure log shipping (Enable Log Shipping)

Configure Jobs

Configure Alerts

Configure linked servers

To configure log shipping

1. Right click the database you want to use as your primary database in the log shipping configuration, and then click Properties.
2. Under Select a page, click Transaction Log Shipping.
3. Select the Enable this as a primary database in a log shipping configuration check box.
4. Under Transaction log backups, click Backup Settings.
5. In the Network path to the backup folder box, type the network path to the share you created for the transaction log backup folder.
6. If the backup folder is located on the primary server, type the local path to the backup folder in the If the backup folder is located on the primary server, type a local path to the folder box. (If the backup folder is not on the primary server, you can leave this box empty.)

Important

If the SQL Server service account on your primary server runs under the local system account, you must create your backup folder on the primary server and specify a local path to that folder.

7. Configure the Delete files older than and Alert if no backup occurs within parameters.
8. Note the backup schedule listed in the Schedule box under Backup job. If you want to customize the schedule for your installation, then click Schedule and adjust the SQL Server Agent schedule as needed.
9. Microsoft SQL Server 2012 Enterprise supports backup compression. When creating a log shipping configuration, you can control the backup compression behavior of log backups by choosing one of the following options: Use the default server setting, Compress backup, or Do not compress backup. For more information, see Log Shipping Transaction Log Backup Settings.
10. Click OK.
11. Under Secondary server instances and databases, click Add.
12. Click Connect and connect to the instance of SQL Server that you want to use as your secondary server.
13. In the Secondary Database box, choose a database from the list or type the name of the database you want to create.
14. On the Initialize Secondary database tab, choose the option that you want to use to initialize the secondary database.

Note

If you choose to have Management Studio initialize the secondary database from a database backup, the data and log files of the secondary database are placed in the same location as the data and log files of the master database. This location is likely to be different than the location of the data and log files of the primary database. (Default Database Location)

15. On the Copy Files tab, in the Destination folder for copied files box, type the path of the folder into which the transaction logs backups should be copied. This folder is often located on the secondary server.
16. Note the copy schedule listed in the Schedule box under Copy job. If you want to customize the schedule for your installation, click Schedule and then adjust the SQL Server Agent schedule as needed. This schedule should approximate the backup schedule.
17. On the Restore tab, under Database state when restoring backups, choose the No recovery mode or Standby mode option.
18. If you chose the Standby mode option, choose if you want to disconnect users from the secondary database while the restore operation is underway.
19. If you want to delay the restore process on the secondary server, choose a delay time under Delay restoring backups at least.
20. Choose an alert threshold under Alert if no restore occurs within.
21. Note the restore schedule listed in the Schedule box under Restore job. If you want to customize the schedule for your installation, click Schedule and then adjust the SQL Server Agent schedule as needed. This schedule should approximate the backup schedule.
22. Click OK.
23. Under Monitor server instance, select the Use a monitor server instance check box, and then click Settings.

Important

To monitor this log shipping configuration, you must add the monitor server now. To add the monitor server later, you would need to remove this log shipping configuration and then replace it with a new configuration that includes a monitor server.

24. Click Connect and connect to the instance of SQL Server that you want to use as your monitor server.
25. Under Monitor connections, choose the connection method to be used by the backup, copy, and restore jobs to connect to the monitor server.
26. Under History retention, choose the length of time you want to retain a record of your log shipping history.
27. Click OK.
28. On the Database Properties dialog box, click OK to begin the configuration process.

How To Change Desktop.ini file for Replace it from Backup File

Scenario : You already taken backup including Desktop.ini, now you want re-store old backup to same location, with existing ini file its not allow, for this you better to change current ini file and replace it from new one. Go to windows assembly and run below commands C:\Windows\assembly>attrib -r -h -s C:\Windows\assembly>rename Desktop.ini Desktop.initemp.bak C:\Windows\assembly>cd..