Monday, November 24, 2014

The Case of Transitive Trusts and Dropped RPC Connections

I was at a client earlier this morning, working to get a transitive forest trust setup between their two domains. Setting up the trust on ServerA to DomainB went without issue. However, when trying to create the trust between ServerB and DomainA, I received this error: The secure channel reset on Active Directory Domain Controller (Your domain controller) of domain (Your domain) to domain (your other domain) failed with error: RPC server is unavailable.

Troubleshooting (as always) started off with the basics: is the firewall on or off, are the services running, are the names being properly resolved, etc. Well, the Windows Firewall on both servers was off and
the RPC services were running. So what now?? I fired up NMAP on ServerB and did a syn scan on ServerA. After reviewing the output, I could see that the ports were open. I then went over to ServerA and opened up the Services MSC console. The RPC services appeared to be running. Being that they are system services and you cannot manually interact with them, I was unable to manually restart them. Just out of curiosity,

I opened a command prompt while connected to that server and ran Netstat -A. This is when I had the "AHA!" moment. Nothing was listening on any of the RPC ports! I rebooted the server (something I don't really like to do..), logged in and ran Netstat -A again. This time, RPC was listening. I went back over to ServerB, walked through the New Trust Wizard, and success! Oh, the feeling of victory!

The Case of Transitive Trusts and Dropped RPC Connections

I was at a client earlier this morning, working to get a transitive forest trust setup between their two domains. Setting up the trust on ServerA to DomainB went without issue. However, when trying to create the trust between ServerB and DomainA, I received this error: The secure channel reset on Active Directory Domain Controller (Your domain controller) of domain (Your domain) to domain (your other domain) failed with error: RPC server is unavailable.

Troubleshooting (as always) started off with the basics: is the firewall on or off, are the services running, are the names being properly resolved, etc. Well, the Windows Firewall on both servers was off and
the RPC services were running. So what now?? I fired up NMAP on ServerB and did a syn scan on ServerA. After reviewing the output, I could see that the ports were open. I then went over to ServerA and opened up the Services MSC console. The RPC services appeared to be running. Being that they are system services and you cannot manually interact with them, I was unable to manually restart them. Just out of curiosity,

I opened a command prompt while connected to that server and ran Netstat -A. This is when I had the "AHA!" moment. Nothing was listening on any of the RPC ports! I rebooted the server (something I don't really like to do..), logged in and ran Netstat -A again. This time, RPC was listening. I went back over to ServerB, walked through the New Trust Wizard, and success! Oh, the feeling of victory!

Sunday, November 16, 2014

Creating Applocker Policies



Application Control Policies can be used to restrict what programs a user is allowed to run. They can be created at the local Group Policy level or the Domain GPO level. There are 4 different types of Applocker RULES that you can implement, depending on what type of executable you want to control access to. 

·         Executable Rules – EXE’s, COM’s, etc. 
·         Script Rules – batch files, VB scripts, etc.
·         AppX Rules – AppX Packages (Windows 8.1/Server 2012 R2 Metro Interface programs)
·         Windows Installer Rules – Windows Installer Packages and MSU Packages

After choosing what type of executable file you want to control, you can choose the corresponding rule type. Then, you will be able to choose the criteria for that rule type. Applocker rule criteria are things such as file path, publisher, and file hash. Criteria allow you to be more granular with your selections. Rather than saying you want to block access to ALL executable’s on a computer, you can choose to block access to executable’s published by a certain vendor, or found in a specified directory.

Applocker can be found in the Group Policy Editor at: Computer Configuration > Windows Settings > Security Settings > Application Control Policies. By right-clicking on the Applocker node, you can configure rule enforcement. You have the option to enforce rules or audit rules based on rule type. Auditing will allow 
you get a good grasp on what Applocker will do in your environment if you are unsure. 

  
Clicking the Advanced tab of this window will allow you to configure rule enforcement for Dynamic Link Libraries. It’s best to leave DLL rule enforcement disabled, because it can cause a system to suffer dramatic performance hits.

Underneath the Applocker node, you will find nodes for the 4 different rule types. You can create new rules by right clicking on any of these nodes and clicking “Create New Rule”. Before creating any rules, I advise you to create the default rules. Doing this will ensure that users are still able to run programs in the Program Files directory and the Windows directory. Also, members of the built-in Administrators group will be allowed to run ANY files.  

When creating custom Applocker rules, you can choose to allow or deny the program, and what group the rule will apply to (by default, the “Everyone” special identity is always selected).

You will also be able to choose the criteria for the executable that you are controlling. 




If the executable has a digital signature from the software publisher, choose “Publisher”. Doing so will give you even more options: 



This allows you to really drill down and get granular with the rule. Microsoft allows us to control access to the file based on the Publisher, the Product Name, the File Name, and even the File Version.

Creating rules based on File Path criteria is not advised, being that if the file jumps directories, the rule will no longer apply. I also don’t advise using the File Hash criteria. My reason behind this is, if the file gets updated, the hash changes. If that happens, the rule is no longer valid.

After choosing the criteria type you would like to use, you can choose to create exceptions, if any. When multiple rules conflict, the order of precedence is Publisher, File Hash, and then File Path. So Publisher rules will always override File Hash rules, File Hash rules will always override File Path rules, and you get the point…

Finally, in order for your endpoint workstations to process Applocker rules, the Application Identity Service must be running. I like to control this with the same GPO that I configure Applocker in.

Creating Applocker Policies


Application Control Policies can be used to restrict what programs a user is allowed to run. They can be created at the local Group Policy level or the Domain GPO level. There are 4 different types of Applocker RULES that you can implement, depending on what type of executable you want to control access to.


·         Executable Rules – EXE’s, COM’s, etc.

·         Script Rules – batch files, VB scripts, etc.

·         AppX Rules – AppX Packages (Windows 8.1/Server 2012 R2 Metro Interface programs)

·         Windows Installer Rules – Windows Installer Packages and MSU Packages


After choosing what type of executable file you want to control, you can choose the corresponding rule type. Then, you will be able to choose the criteria for that rule type. Applocker rule criteria are things such as file path, publisher, and file hash. Criteria allow you to be more granular with your selections. Rather than saying you want to block access to ALL executable’s on a computer, you can choose to block access to executable’s published by a certain vendor, or found in a specified directory.


Applocker can be found in the Group Policy Editor at: Computer Configuration > Windows Settings > Security Settings > Application Control Policies. By right-clicking on the Applocker node, you can configure rule enforcement. You have the option to enforce rules or audit rules based on rule type. Auditing will allow

you get a good grasp on what Applocker will do in your environment if you are unsure.





Clicking the Advanced tab of this window will allow you to configure rule enforcement for Dynamic Link Libraries. It’s best to leave DLL rule enforcement disabled, because it can cause a system to suffer dramatic performance hits.


Underneath the Applocker node, you will find nodes for the 4 different rule types. You can create new rules by right clicking on any of these nodes and clicking “Create New Rule”. Before creating any rules, I advise you to create the default rules. Doing this will ensure that users are still able to run programs in the Program Files directory and the Windows directory. Also, members of the built-in Administrators group will be allowed to run ANY files.


When creating custom Applocker rules, you can choose to allow or deny the program, and what group the rule will apply to (by default, the “Everyone” special identity is always selected).


You will also be able to choose the criteria for the executable that you are controlling.






If the executable has a digital signature from the software publisher, choose “Publisher”. Doing so will give you even more options:





This allows you to really drill down and get granular with the rule. Microsoft allows us to control access to the file based on the Publisher, the Product Name, the File Name, and even the File Version.


Creating rules based on File Path criteria is not advised, being that if the file jumps directories, the rule will no longer apply. I also don’t advise using the File Hash criteria. My reason behind this is, if the file gets updated, the hash changes. If that happens, the rule is no longer valid.


After choosing the criteria type you would like to use, you can choose to create exceptions, if any. When multiple rules conflict, the order of precedence is Publisher, File Hash, and then File Path. So Publisher rules will always override File Hash rules, File Hash rules will always override File Path rules, and you get the point…


Finally, in order for your endpoint workstations to process Applocker rules, the Application Identity Service must be running. I like to control this with the same GPO that I configure Applocker in.

Layer 2 Switching Fundamentals



Switches are devices that support a large number of ports to connect devices to the network.
 Design:













More towards a CCNP or CCDA topic, but designing a network when it comes to the switching side can be done in three building blocks. The access layer, the distribution layer, and the core layer. The access layer generally has a high port density, can support VLANs, QoS, and access lists. The distribution layer will aggregate multiple access layer switches. These are also generally Layer 3 switches to allow routing among an enterprise. It will need to be able to handle the volume of traffic in addition to supporting the same features as the access layer switches. The core layer is the device which will need the highest bandwidth backplane to deal with all of the traffic.

How switches handle traffic:
A switch is an intelligent device that can make some decisions on how to handle the data it is given. Switches can be divided into two categories for these decisions: Layer 2 or Layer 3 switches. For the CCNA we will only be interested in the layer 2 switches. Layer 2 switches operate at the data link layer. This layer deals primarily with MAC addresses. A Layer 2 switch will build a CAM table full of dynamically learned MAC addresses. The way it learns these addresses is by inspecting the layer 2 header/trailer and learning the source MAC addresses on the frames it receives. A frame is what a packet is encapsulated in when it moves from device to device across the network.

With this example the switch has learned PC1/PC2/and PC3′s MAC addresses. If a packet came in on Fa0/4 from PC4, the switch would look at the source MAC address and put an entry for 4444.4444.4444 on Fa0/4. A switch will route traffic based on this table. There are a few decisions it must make to determine how to handle traffic. When it first receives a frame it will consult it’s CAM table to determine whether or not it has the source MAC address listed for that port. If not, it will add it to the CAM table. In the example above, PC1 sent a frame to the switch, the switch noticed PC1′s MAC address was not in it’s table and added it. The next thing it looks at is the destination MAC address. The CAM table is again consulted. If it finds a match the switch will send the frame directly to the recipient it needs to on whatever port it is on. In the example above, PC1 sends a frame to PC3. Because the switch sees 1111.1111.1111 sending to 3333.3333.3333 and has an entry for 3333.3333.3333 it will send the frame out of port Fa0/3 to the recipient. If a destination is not in the CAM table the switch will need to try to find the recipient. In this case the switch will decide to broadcast the frame out of every port EXCEPT the one it came in on. In this example, PC1 sends a frame destined for PC4. The switch will see a frame from 1111.1111.1111 to 4444.4444.4444. PC4′s MAC address is not in it’s table. The switch will then send the frame out of every port except for Fa0/1 (the source). When PC2 and PC3 get this frame, it will determine if the frame was meant for it, and if not it will ignore it. PC4 will also make the same decision and PC4 will respond. Once PC4 has responded the switch will be able to add PC4′s MAC address to it’s table on Fa0/4.

Follow by Email

Search This Blog