When designing policies with the Security Compliancy Manager you can quickly design the Firewall policies and import these settings to a policy in your environment. However, when you configure the policies through that console, also make sure to configure the exceptions through that console!

In short, when you configure the donotallowexceptions, the registrykey HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile\DoNotAllowExceptions is set to REG_DWORD:1. When you configure the exceptions through the normal GPO editor, this key is NOT reset to 0, thus no exceptions are allowed and your configured exceptions will not work!. By configuring the exception also using this SCM console, you specifically edit the REG_DWORD to be 0.

PS: It is best to only configure the Windows Firewall with Advanced Security in the 2008 template:
Do not use: Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall\Domain Profile
Use: Computer Configuration\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security\Windows Firewall Properties\Domain Profile

Three written exams and one lab later, co-worker J. Reijling achieved MCM OCS.. congrats..

http://www.reijling.nl/

So CCF can help you with that..it requires a lot of programming to integrate all the apps, but it could be worth it.. are you designing CCF? are you interested in the architecture.. check out this post …

1     Introduction

CCF is based on a client-server model. The client is a .net application that runs on a client computer for example all computers in a call-center. When the client connects to CCF it creates a connection on a HTTP port of the CCF server and it receives the application configuration. When the client starts one of the retrieved applications, it creates a direct connection to that application. This connection is based on the configuration and connection information retrieved from CCF. CCF itself does not create a direct connection to the application but only hosts the connection and configuration information for each application it can grant access.When opening the application CCF can use Enterprise Single Sign-On to automatically log the user into the application. The CCF client actually types the username and password for the application in the background so that a generic work experience is received.

While multiple applications are accessible through the CCF console, each application can have a different access path. Some applications are installed locally on the client while others are accessible through web services or other client components. If an application is set to local program this could also imply that the client component is only installed on the Client Agent computer and that additional server connections for that application can apply.

2     Server architecture

Internet Information Services is used on the CCF server as the connection point for the client. The (default) website will be extended during the installation with CCF web applications. The web applications use SQL and XML or directory services to store information and configuration data. The directory services are best to be based on the Active Directory Application Mode (ADAM) component Active Directory Directory Services. When using multiple web servers each server can hosts its own instance of the ADAM directory store and replication amongst these stores is automatically configured. For availability the databases should be hosted on an SQL cluster that will host four databases for the CCF infrastructure. Apart from the SSO database, the databases are soley used by the CCF web applications. The SSO database is used to store encrypted credential information for signle-sign-on services. This service (Microsoft Enteprise SSO) should also present on each node and reads / writes data and configuration to this database.

All the applications run under a single application pool account. As services will run under Active Directory user service accounts. The CCF service is dependant on the Active Directory Service (or called Active Directory domain) and its dependant services like name resolving and authentication service providers.

A high available CCF solution would be based on a network load balanced architecture, where multiple CCF servers provide the services. Each node is configured to be able to work independantly from the other nodes, so that if one node has a full service failure, the CCF service will not be affected.



The installation of each server in the web services infrastructure is manual, however the configuration stored in the SQL server and ADAM store are to be shared amongst all servers. The ADAM service on each node will be part of the same application directory and replication amongst all ADAM instances will be automatically configured. Each webserver node will contact “msldap://localhost:389” for these directory services. While localhost is used, this ensures each webservice node can work idependantly from another.

2.1 Kerberos architecture

Kerberos is the required authentication mechanism for CCF. Any other authentication protocol will not be accepted and an access denied on the resource will be the outcome of the authentication attempt. Kerberos requires Service Principal Names (SPN) to function as they are the fundamental basis of kerberos. Each resource will need an SPN based on the address of the resource. The SPN must be registered on the Active Directory object hosting the resource. Within CCF all web applications are hosted on a single user service account. This account will have the web URL as an SPN registered. SQL will also require an SPN. This is usually set during installation. While the ADAM service and the Enteprise SSO services are hosted under the same account as the web applications, and since they are on the same physical machine further configuration will not be required.

more info:

http://technet.microsoft.com/en-us/library/dd638295.aspx

http://www.microsoft.com/serviceproviders/ccf/default.mspx

Kerberos works with Service Principal Names (SPN’s). Each service you want to contact with kerberos authentication requires an SPN registered in Active Directory. Now why and how kerberos works is not in this post, but lets focus on this new feature in IIS7.

Prior to IIS7 when we wanted to use Kerberos for a website that was not reached through the servername URL (http://<servername> we needed an SPN registered on the server host (setspn –A HTTP/<URL>   <Servername>  ). When the website was a web application and running under a service account, the SPN needed to be registered to the service account. Now let’s assume we have one website with multiple web applications. Each application runs under a different service account but the main URL is the same for all applications (http://MyURL/App1, http://MyURL/App2, etc).

We can only register the MyURL to a single object (computer or useraccount) and in this case we need to register it to each service account, or run all applications under the local system account (ouch) or a generic service account. Here comes Kernel mode to the rescue. While each service can run under a different service account, the IIS computer will take care of the authentication! The SPN of MyURL needs to be registered to the serverobject in AD, and each application pool will use the computer for authentication and delegation!

Easy hey.. and now the downside or the catch.. the above architecture works, as long as the web applications are ONLY on the same server, when using Load Balancing with multiple web servers the SPN needs to be registered on a service account that is used on all nodes of the NLB cluster. Since the fact that the SPN cannot be registered on multiple computer objects kernel mode cannot be used for NLB web clusters.

It’s like the docter amputates the heart of the patient, just to cure a brooze

Congratulations McAffee this time:

1. Download the EXTRA.ZIP file attached to this article and extract the EXTRA.DAT file.
2. Click Start, Run, type services.msc and click OK.
3. Right-click the McAfee McShield service and select Stop.
4. Copy the EXTRA.DAT file to the following location:<installation drive>\Program Files\Common Files\McAfee\Engine

5. In the Services window, right-click McAfee McShield and select Start.

• ePO 4.0 – KB52977
• ePO 4.5 – KB67602

1. Open the VirusScan Console.
2. Double-click Quarantine Manager Policy.
3. Click the Manager tab.
4. Right-click the required item and select Restore.

The allowed to authenticate right controls who can authenticate to a particular machine or service (or an entire domain). The attribute is available on computer, user and InetOrgPerson objects. The right is also applicable on the domain object if access is allowed for the entire domain. It can also be applied to OU’s to set inheritable ACE’s on OU’s containing a set of user or computer objects. The attribute can be set by members of the Account Operators, Administrators, Domain Administrators, Enterprise Administrators and the SYSTEM groups by default. This behaviour can be changed in the schema of a forest.

To allow authentication between the two domains that reflects an external domain trust authentication model, the allowed to authenticate right must be delegated from the domain object. To do this, right click the domain in Active Directory Users & Computers and select delegate. Add the domain users group from the trusted domain to the user/group list and select to delegate a custom task. Select only specified objects and select users, inetOrgPerson and Computers. Next select the allowed to authenticate attribute and finish the wizard.

PS: rumor has it, that I will be presenting about Trusts, (including selective authentication) in the near future.. keep following this blog for more information.

Expanding base ‘CN=SA-SQL01-SQL,CN=Managed Service Accounts,DC=ROOTDOMAIN,DC=local’…
Getting 1 entries:
Dn: CN=SA-SQL01-SQL,CN=Managed Service Accounts,DC=ROOTDOMAIN,DC=local
accountExpires: 9223372036854775807 (never);
badPasswordTime: 2/4/2009 1:34:38 PM W. Europe Standard Time;
badPwdCount: 0;
cn: SA-SQL01-SQL;
codePage: 0;
countryCode: 0;
distinguishedName: CN=SA-SQL01-SQL,CN=Managed Service Accounts,DC=ROOTDOMAIN,DC=local;
dSCorePropagationData: 0×0 = ( );
instanceType: 0×4 = ( WRITE );
isCriticalSystemObject: FALSE;
lastLogoff: 0 (never);
lastLogon: 2/4/2009 1:56:18 PM W. Europe Standard Time;
lastLogonTimestamp: 2/4/2009 1:16:59 PM W. Europe Standard Time;
localPolicyFlags: 0;
logonCount: 4;
msDS-HostServiceAccountBL: CN=SQL01,CN=Computers,DC=ROOTDOMAIN,DC=local;
name: SA-SQL01-SQL;
objectCategory: CN=ms-DS-Managed-Service-Account,CN=Schema,CN=Configuration,DC=ROOTDOMAIN,DC=local;
objectClass (6): top; person; organizationalPerson; user; computer; msDS-ManagedServiceAccount;
objectGUID: 87ba9c4a-8a9b-4c13-b1f8-5986c8c5a53e;
objectSid: S-1-5-21-1621971834-463630077-1066132090-1115;
primaryGroupID: 515 = ( GROUP_RID_COMPUTERS );
pwdLastSet: 2/4/2009 1:10:57 PM W. Europe Standard Time;
sAMAccountName: SA-SQL01-SQL$;
sAMAccountType: 805306369 = ( MACHINE_ACCOUNT );
servicePrincipalName: MSSQLSVC/SQL01.ROOTDOMAIN.LOCAL:1456;
userAccountControl: 0×1000 = ( WORKSTATION_TRUST_ACCOUNT );
uSNChanged: 16557;
uSNCreated: 16544;
whenChanged: 2/4/2009 1:16:59 PM W. Europe Standard Time;
whenCreated: 2/4/2009 1:10:20 PM W. Europe Standard Time;

The SamAccountType is as you can see a machine_account, and the userAccountControl is set to Workstation_trust_Account..

Now a lot of services are now set for delegation, since we do not have the regular “Trust for Delegation” tab on the object in Active Directory, we need to set the delegation through another way. Delegation is set by the 7th bit of the UserAccountControl attribute. We see that the current one is set to 0×1000(HEX) or 4096 (DEC) as the attribute tab shows us through the Active Directory Users & Computers MMC.

The HEX value is actually now: 0×00001000, and we need to set the 7th character to be a 1 to enable the Trusted for delegation option. The new value to put in is therefore DEC(01001000)=16781312.

Enter the new number in the UserAccountControl attribute and see the results:

userAccountControl: 0×1001000 = ( WORKSTATION_TRUST_ACCOUNT | TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION );

While many believe WINS or LMHOSTS can help us on external (non-forest) trusts, we dive into a packet capture that has captured the opening of a fileshare on a remote forest.

For this demo, I have installed a resource server in the forestroot domain, and a RIVER client on the OCEANFLOOR domain.

The first packet that interests us is the call for the DNS record of the Resource server

That packet is offcourse answered with the IP address of the Resource server (172.16.6.103)

Then we see the outgoing connection from the RIVER client towards the RESOURCE server on SMB level:

The RESOURCE server responds with a Negotiate packet and then the line seems quiet for some time, so we need to look at what is happening on the forestroot side.

On the resource server, we also had a capture running, and there we see that the resource server is actually connecting with RPC to its domain controller.

After connecting to the server, it sends a logon package, indicating the remote logon:

The domain controller performs a DNS lookup (based on the site again!)

Now in this case, I (sneaky me) created the site in advance (on the OCEANFLOOR domain). The response therefore is the two (auto site coverage…) domain controller..

Now we see the same as with the trust creation, an LDAP lookup is fired to both domain controllers that were retrieved:

Again, the first one to respond is the winner, however while the domain controller of the OCEANFLOOR do not respond that quickly (relatively speaking) the domain controller also fires a DNS lookup for the general domain, just in case: DNS:QueryId = 0×6B93, QUERY (Standard query), Query  for _ldap._tcp.dc._msdcs.OCEANFLOOR.local of type SRV on class Internet

And here is where it get’s interesting, while the LDAP is performed, the server actually also tries to locate the domain controllers of the OCEANFLOOR on Netbios!. This could be due to the fact that the OCEANFLOOR LDAP lookup takes some time, or that it does this always (something for next time). The better question then if off course, will the dc use the LDAP responses, or does it prefer the WINS lookup (need to setup a larger test lab )

In my case WINS does not answer, the OCEANDC01 wins the run for the LDAP lookup..

Then three packets follow that trigger our interest:

And after that, the RESOURCE server seems to be granted access.

When we have the same problem with user passwords, the PDC gives the vote whether the password (just changed) for the user is valid. The same seems to apply for Trusts. When running a trace while creating the trust on a “regular” domain controller and not the PDC, we can find out how that is accomplished. For this, I have installed a domain controller called MICHDC01 which is on the (newly created) LAKES site.

When creating the trust we see all the traffic as expected, and then after the SMB connection to the domain controller to the other forest we see a call to the local domain PDC (or root domain PDC I would suspect in a forest trust scenario with more domains).

A reply follows from the OCEANDC01 that the connection is open and available

And then the magic happens (sort of), the regular domain controller instructs the PDC to create an External trust

So we see, the PDC does have a role within the creation of trusts, but NOT related to the agreement between the two PDC’s of the domains. After the creation of the trust, it looks like urgent or immediate replication takes place to inform all the domain controllers.

Those questions we will answer in this series of authentication across trusts part 2, 3 etc..

First a little drawing about the used infrastructure for this and the next to come posts:

In the drawing above, we see two forests, rootdomain and oceanfloor. These forests are going to trust each other using a ‘normal’ trust. To establish the trust, each domain controller has a conditional forwarder for DNS setup to point to DNS servers of the other forest.

So, when we type perform an NSLOOKUP on the rootdomain domain controller to find the oceanfloor forest we get:

And from oceanfloor.local we get the IP addresses of all the domain controllers for forestroot (172.16.5.31, 172.16.5.32, 172.16.5.33, 172.16.5.34). Now although all those addresses are within the same subnet, they are split to different sites (just for this demo I’ve used /32 sites).

Figure 1: Forestroot.local Sites

Now let’s assume datacenter 1 is located in Amsterdam, datacenter 2 is located in New York, One of the branch-sites is somewhere in South Africa and the BRANCH-SITE site is a site with a Read Only domain controller. When we requested the domain name in DNS, we got ALL domain controllers including the South African one (only not the RODC). When we request the SRV records for the forestroot domain, we receive the following:

Note that all domain controllers are registered and are received.

So what does this mean?

If we do not take care of some things, for a user who is authentication over the trust, the authentication could end up on ANY domain controller (listed as above). In this example, that is nothing to worry about, since all domain controllers are well connected, but what if the OCEAN domain is closer to Datacentre 2? Can we force the cross-forest authentication towards that datacenter, so that every user that needs to be authenticated over the forests, does not cross the physical ocean WAN line?

To discover if we can force that, we need to find out, how a domain controller (in case of NTLM) or a client (Kerberos) finds domain controllers in the other domain. but off course we need to create a trust first, how is that done and how do domain controllers find each other during the creation of a trust.

When creating an external trust, it only allows for NTLM authentication. So we create a trust between the two domains, being an external trust. We open domains and trusts and create an external trust to the forestroot domain from the oceanfloor domain, while running a packet capture.

The packet capture shows something funny that has to be taken into account.

While everyone would expect the PDC to be targeted, this is NOT the case. So there we have lesson number one:

!The DNS query for domain information is NOT to the PDC service record!

And immediately we have lesson number 2:

!During the setup of a trust, the CURRENT site of the DC is looked up on the other forest BEFORE a generic query takes place!

The generic DNS service record lookup

Since our site plan of Forestroot does not have such a site, we retrieve an error back from the DNS server indicating it has no record.

Next a query for the generic service records is performed:

Now that query does receive an answer, just like we got during the NSLOOKUP manually. The response includes al domain controllers and service records like we saw before. Lesson number two can be learned here. Each service record has a priority and a weight, manipulating these weights can influence the results received and thus influence the next steps. See also Jorge’s blog for DNS optimization.

Next what we see, is that ALL LDAP domain controller srv records received are used. The OCEANFLOOR domain controller fires an LDAP lookup towards all domain controllers in the following packets.

Now comes the fun part, the FIRST domain controller to respond to this seachRequest gets to be the lucky winner and just like in the real world the other responses that come in late, are disregarded.

In my case, it’s the 172.16.6.32 that is the fastest domain controller to respond to the request with a successful lookup. Now you where probably expecting the next query to be the PDC emulator, but no, an SMB connection is tried to the 172.16.6.32 (referred to as FDC02.forestroot.local), however login failures are shown.

Note: No packets to 172.16.6.31 (FDC01.forestroot.local) that is the PDC of Forestroot.local are being sent, nor received.

But this is only the first part of the trust, we enabled the trust incoming and outgoing on the OCEANFLOOR.local domain. Now we must enable it also on the forestroot, and let us see what happens, for the time being, I’m creating the other end of the trust on the FDC02.forestroot.local. Again we see the site specific query from FDC02.forestroot.local where FDC02’s site is DATACENTER2

Dns: QueryId = 0×77C, QUERY (Standard query), Query  for _ldap._tcp.DATACENTER2._sites.dc._msdcs.OCEANFLOOR.local of type SRV on class Internet

The rest is about the same, up to the point of the SMB2 connection. This time (because the trust passwords ARE now present and the same on both ends) the connection IS successful.

So what have we learned, when we create a trust, the PDC emulators do not really come in to play, as all traffic is from domain controller to domain controller based on DNS information. We can manipulate this information to speed up the process (and optimize it), by either manipulating DNS information, OR! We add another site to our forest that has the exact site name of the site where the domain controller(s) is that we want to target!.