NAP VPN ENFORCEMENT LAB

NAP VPN ENFORCEMENT LAB

3 machines : [DC  + VPN SERVER Domain Member + Client [WG]

LAB Steps :-

1- Add ENT Root CA on DC .

2- Cert templates --- r.click -- manage -- computer -- properties -- security -- read+Enroll --- ok .

3- On VPN -- MMC – Certificates [computer] --- request  certificate .

4- On VPN ----- add Roles ----- Network policy and Access ------------- choose NPS + RRAS [R.A] --- ok

5- start ----- programs ------ Administrative Tools -------- Open Network Policy Server  .

Windows Security  Health ----- default configuration --- allow only F.W + clear all other settings .

policies--- health policies -- create 2 policies

Compliant --- pass all SHV + select ...

Non Compliant --- fail one or more SHV + select ....

Network policies --- disable defaults --- NEW

** compliant full access ---  condition " health policy"[compliant] ----access granted --- allow full access ---- finish

** non compliant - limited access ----- condition " health policy"[non compliant] --- limited access + uncheck " enable auto   
      remediation" .

IP filters ----- input + output  " allow for one PC "

Input filters--- new DST Network --- add -- DC IP/32 mask --- permit only --- ok

Output filters--- new SRC Network --- add -- DC IP/32 mask --- permit only --ok  ---- then finish the policy

Connection request policy --- disable default --- create NEW

name ---- type[VPN] ---- condition "tunnel type" select pptp+l2tp+sstp --- auth method [override] --- EAP types --- add --- MS protected EAP + MS Secured password ... -- ok

MS protected EAP --- Edit -- ensure --- Enforce network access protection is selected ----- finish

NOW -- configure RRAS --- VPN --- finish  ---- then  go to NPS --- connection request policies  ------- disable MS RRAS + MOVE our policy into the  TOP ***

Administrative tools --------- Firewall with advanced sec  ------ Create Inbound Rule ------- ICMP V4 [Echo request] ------ Finish

Client :-

** Export CA cert --- import into computer trusted Root CA [MMC]

1- run --- napclcfg.msc --- Enforcement -- EAP --- Enable .

2- gpedit.msc ---- administrative  templates --- windows  components  --- security center -- turn on

3- Run --- services.msc --- network access protection --- Auto + start

4- Create VPN connection --- finish ---- properties --- security ----- Authentication ---- use EAP

Microsoft : Protected EAP [PEAP] (encryption Enabled) --- properties --- uncheck "connect to these ..." + check " Enforce network access protection" 

شرح كورس 70-290

Course 70-290 

Managing and Maintaining Windows server 2003

http://www.4trainee.com/videocourses/-microsoft/-mcse/70-290.html

شرح كورس الأبجريد إلى ويندوز سيرفر 2008 70-649

http://www.youtube.com/playlist?list=PL71BEC4E0817231EB&feature=viewall

شرح كورس 70-291 على يوتيوب

http://www.youtube.com/playlist?list=PL123A1F028823CD11&feature=viewall

Windows 2003 Trust Relationships

·  Two-way trust: A trust relationship between two domains in which both domains trust each other. For example, domain A trusts domain B, and domain B trusts domain A. All parent-child trusts are two-way trusts.

·  One-way: incoming trust: A one-way trust relationship between two domains in which the direction of the trust points toward the domain from which you start the New Trust Wizard (and which is identified in the wizard as This domain). When the direction of the trust points toward your domain, users in your domain can access resources in the specified domain. For example, if you are the domain administrator in domain A and you create a one-way, incoming trust to domain B, this provides a relationship through which users who are located in domain A can access resources in domain B. Because this relationship is one-way, users in domain B cannot access resources in domain A.

·  One-way: outgoing trust: A one-way trust relationship between two domains in which the direction of the trust points toward the domain that is identified as Specified domain in the New Trust Wizard. When the direction of trust points toward the specified domain, users in the specified domain can access resources in your domain. For example, if you are the domain administrator in domain A and you create a one-way, outgoing trust to domain B, this provides a relationship through which users who are located in domain B can access resources in domain A. Because this relationship is one way, users in domain A cannot access resources in domain B.

·  Domain-wide authentication: An authentication setting that permits unrestricted access by any users in the specified domain to all available shared resources that are located in the local domain. This is the default authentication setting for external trusts.

·  Forest-wide authentication: An authentication setting that permits unrestricted access by any users in the specified forest to all available shared resources that are located in any of the domains in the local forest. This is the default authentication setting for forest trusts.

·  Selective authentication: An authentication setting that restricts access over an external trust or forest trust to only those users in a specified domain or specified forest who have been explicitly given authentication permissions to computer objects (resource computers) that reside in the local domain or the local forest. This authentication setting must be enabled manually.

What types of trust relationships does Windows Server 2003 support?

Windows 2003 supports six types of trusts (although the OS doesn't support all types for all forest modes):

• Tree-root trust--Windows 2003 automatically creates a transitive, two-way trust when you add a new tree-root domain to an existing forest. Tree-root trusts let every domain in different trees in the same forest implicitly trust one another.
• Parent-child trust--Windows 2003 automatically creates a transitive, two-way trust when you add a child domain to an existing domain. This trust lets every domain in a particular tree implicitly trust one another.
• Shortcut trust--When domains that authenticate users are logically distant from one another, the process of logging on to the network can take a long time. You can manually add a shortcut trust between two domains in the same forest to speed authentication. Shortcut trusts are transitive and can either be one way or two way.
• External trust--Administrators can manually create an external trust between domains in different forests or from a Windows 2003 domain to a Windows NT 4.0 or earlier domain controller (DC). External trusts are nontransitive and can be one way or two way.
• Forest trust--When two forests have a functional level of Windows 2003, you can use a forest trust to join the forests at the root. An administrator can manually create a two-way forest trust that lets all domains in both forests transitively trust each other. Forest trusts can also be one way, in which case the domains in only one of the forests would trust the domains in the other forest. Multiple forest trusts aren't transitive. Therefore, if forest A has a forest trust to forest B and forest B has a forest trust to forest C, forest A does not implicitly trust forest C.
• Realm trust--An administrator can manually create a realm trust between a Windows 2003 domain and a non-Windows Kerberos 5 realm. Realm trusts can be transitive or nontransitive and one way or two way.

[AD Tutorial] How to adjust Domain Controller ]

Each windows domain controller has several SRV records that client use as part of the DC locator process to find the closest domain controller. Two fields of the SRV record let clients determine which server to use when multiple possibilities are returned. The Priority field is used to dictate if a specific server or set of servers should always be contacted over others unless otherwise unavailable. A server with a higher priority( Lower field value) will always be contacted before a server with a lower priority. First let's check the existing priority and weight of the domain. The weight  value is stored in the LdapSrvWeight registry entry. The default value is 100, but it can range from 0 through 65535. By reducing this value, DNS refers clients to a domain controller less frequently based on the proportion of this value to the value of other domain controllers. For example, to configure the system so that the domain controller hosting the PDC emulator role receives requests only half as many times as the other domain controllers, configure the weight of the domain controller hosting the PDC emulator role to be 50. DNS determines the weight ratio for that domain controller to be 50/100 (50 for that domain controller and 100 for the other domain controllers). After you reduce this ratio to 1/2, DNS refers clients to the other domain controllers twice as often as it refers to the domain controller with the reduced weight setting. By reducing client referrals, the domain controller receives fewer client requests and has more resources for other tasks, such as performing the role of PDC emulator. Adjusting the priority of the domain controller also reduces the number of client referrals. However, rather than reducing it proportionally to the other domain controllers, changing the priority causes DNS to stop referring all clients to this domain controller unless all domain controllers with a lower priority setting are unavailable. A domain controller's priority value is stored in its registry. When the domain controller starts, the Net Logon service registers with the DNS server. The priority value is registered with the rest of its DNS information. When a client uses DNS to discover a domain controller, the priority for a given domain controller is returned to the client with the rest of the DNS information. The client uses the priority value to help determine to which domain controller to send requests. The value is stored in the LdapSrvPriority registry entry. The default value is 0, but it can range from 0 through 65535. Important: A lower value entered for LdapSrvPriority indicates a higher priority. To change the weight for DNS SRV records in the registry: 1.Click Start, click Run, type regedit and then press ENTER. 2. navigate to HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3. To configure the Priority, add a REG_DWORD with the name LdapSrvPriority.      to configure the Weight, add a REG_DWORD with the name LdapSrvWeight. After you make the change, \System32\Config\netlogon.dns file should be updated and the DDNS updates sent to the DNS server within an hour. You can also restart the NetLogon service to expedite the process.

ISATAP Router LAB Video

http://vimeo.com/31334607

http://www.youtube.com/watch?feature=player_embedded&v=TEFgNvV9TTY

Synchronize with Active Directory Domain Services

You can use adamsync command line tool to synchronize data from an Active Directory Domain Services (AD DS) forest to a configuration set of an Active Directory Lightweight Directory Services (AD LDS) instance.  

Important

adamsync does not synchronize user passwords between AD DS and AD LDS.

Matching the schema objects in the AD LDS instance with the schema objects in the AD DS forest :-

To ensure that your AD LDS schema matches the AD DS schema, use AD DS/LDS Schema Analyzer to create an LDIF file that will contain the target schema elements, and then import this LDIF file into your base AD LDS schema by using the ldifde command.

Remarque

You can use AD DS/LDS Schema Analyzer to help migrate the Active Directory schema to AD LDS, from one AD LDS instance to another, or from any LDAP-compliant directory to an AD LDS instance. You can use AD DS/LDS Schema Analyzer to load a target (source) schema, mark the elements you want to migrate, and then export them to the base AD LDS schema. You can also compare the two schemas or two LDAP Data Interchange Format (LDIF) files. When using AD DS/LDS Schema Analyzer to create an LDIF file, you should load both a target and a base schema. Otherwise, the resulting LDIF file might not be usable by the ldifde tool.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition.

To create an LDIF file with AD DS/LDS Schema Analyzer

1. To open AD DS/LDS Schema Analyzer, at the command prompt, change the directory to %windir%\ADAM, type the following command, and then press ENTER:

adschemaanalyzer

2. To load a target schema, click File, and then click Load target schema, and then do one of the following:
• To load the domain Active Directory schema as the target schema, in the dialog box, type your user name, password, and domain, and then click OK .   "srv1:389" السيرفر الأصلى
• To load a different schema (such as the schema of an Active Directory forest or an another LDAP-compliant directory), in the dialog box, type the server name and port of the directory containing the target schema, type your user name, password, and domain as needed, and then click OK.
3. To load the schema of your AD LDS instance as the base schema, click File, click Load base schema, and then in Server[:port], type the server name and port of the AD LDS instance.
4. In the dialog box, click OK.     .   "srv1:3333"   LDS instance
5. Click Tools, click Options, and on the LDIF generation tab, click Update with references to new and present elements.

Important

If this option is not selected and you proceed to create an LDIF file with the default option of Update with references to new elements only, the resultant LDIF file will not contain all the differences between the schemas. For example, the User class in you AD DS schema might have Optional Attributes that are not included in the User class in your AD LDS schema. If the LDIF file that was created through AD DS/LDS Schema Analyzer does not contain these Optional Attributes and later you attempt to synchronize data in your AD DS forest and the AD LDS configuration set into which this LDIF file has been imported, adamsync will fail with an object violation error.

6. Since later you plan to synchronize data by using adamsync, click Schema, and then click Mark all non-present elements as included.
7. To create the LDIF file, click File, and then click Create LDIF file. To save the created LDIF file, type in the file name and save it at an appropriate location. For example, C:\Windows\ADAM\Differences.LDIF
8. To import the LDIF file into the AD LDS instance in order to update the AD LDS schema to match the AD DS schema, open the created LDIF file, copy the ldifde command created by the AD DS/LDS Schema Analyzer, (for example,

ldifde -i -u -f test.ldf -s server2:3333 -c "cn=Configuration,dc=X" #configurationNamingContext

       10- now try to create new objects --- new elements added

*******************************************************************************

Extending the AD LDS instance schema for objects that are required by adamsync

You can use the following procedure to extend the AD LDS schema to include schema objects that are required by the adamsync command line tool.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition.

To extend the AD LDS instance schema to include objects that are required by adamsync

1.      At the command prompt, change the directory to %windir%\ADAM, type the following command, and then press ENTER:

ldifde -i -f MS-AdamSyncMetadata.ldf -s <server>:<port> -c CN=Configuration,DC=X #ConfigurationNamingContext

For example, to extend the AD LDS schema on a local server, type the following command, and then press ENTER:

ldifde -i -f MS-AdamSyncMetadata.ldf -s localhost:50000 -c CN=Configuration,DC=X #ConfigurationNamingContext

2.      To open the configuration file MS-AdamSyncConf.xml in a text editor (Notepad.exe) and modify it with the appropriate parameters, type the following command, and then press ENTER:

notepad MS-AdamSyncConf.xml

3.      In Notepad, make the following changes to the contents of the configuration file:

• Replace the value of <source-ad-name> with the name of the source AD DS domain controller, for example, <source-ad-name>SeattleDC1</source-ad-name>.
• Replace the value of <source-ad-partition> with the distinguished name of the source domain, for example, <source-ad-partition>dc=fabrikam,dc=com</source-ad-partition>.
• Replace the value of <source-ad-account> with the name of an account in the Domain Admins group of the source domain, for example, <source-ad-account>administrator</source-ad-account>.
• Replace the value of <account-domain> with the fully qualified Domain Name System (DNS) name of the source domain, for example, <account-domain>fabrikam.com</account-domain>.
• Replace the value of <target-dn> with the name of the partition of the target AD LDS instance, for example, <target-dn>DC=Microsoft,DC=US</target-dn>.

Remarque

If you are preparing to synchronize an AD LDS instance on a computer running Windows Server 2008, you must specify a naming context head as the value for <target-dn>. If you do not specify a naming context head as the distinguished name of the target AD LDS instance in the configuration file, the following error message appears when you attempt to run adamsync in the next step: "The target partition given was not the head of a partition. AdamSync cannot continue."

• Replace the value of <base-dn> with the base distinguished name of the container in the source domain where you want the search for synchronizing objects to start, for example, <base-dn>ou=users,dc=fabrikam,dc=com</base-dn).
• Modify the query filter (the default being <object-filter>(objectClass=*)</object-filter>), depending on what objects you want to synchronize.

Important

Do not delete any unused fields from this file.

Remarque

It is not necessary to synchronize an entire domain naming context. To save disk space and avoid synchronization problems, consider excluding objects and attributes that are not necessary to ADAM (for example, DNS records, FRS subscriptions, and DN-binary values), and edit your MS-AdamSyncConf.xml file appropriately. For more information, see Adamsync Configuration File XML Reference (http://go.microsoft.com/fwlink/?LinkId=119621).

4.      In Notepad, on the File menu, click Save As, type a new name for the file, click Save, and then close Notepad.

5.      To install the modified configuration file, at the command prompt, type the following command, substituting the file name that was used in the procedure above for .xml_file, and then press ENTER:

adamsync /install <server>:<port> .xml_file

For example,

adamsync /install localhost:50000 %windir%\ADAM\MS-AdamSyncConf.xml

Synchronizing AD DS data to an AD LDS instance

You can use the following procedure to synchronize the data from your AD DS data to the AD LDS configuration set.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition.

 

To synchronize AD DS forest data to an AD LDS instance

1.      At a command prompt, type the following command, and then press ENTER:

adamsync /sync <server>:<port> ADLDS_configuration_dn /log

Replace ADLDS_configuration_dn with the distinguished name of the AD LDS namespace where you saved the configuration MS-AdamSyncConf.xml file (or the value of target_dn in MS-AdamSyncConf.xml file). For example, adamsync /sync localhost:50000 DC=microsoft,DC=US” /log.

The following table contains the parameters for the preceding procedures and other commonly used adamsync parameters. For more information about adamsync parameters, at a command prompt, type adamsync /?, and then press ENTER.

 

Parameter	Description
/?	Displays command-line options.
/i or /install<input_file>	Installs the configuration that is contained in the specified input file.
/sync configuration_dn	Synchronizes the specified configuration.
/fs configuration_dn	Performs a full replication synchronization for the specified configuration.
/ageall configuration_dn	Performs an aging search for the specified configuration. An aging search determines—by searching for the AD LDS objects in AD DS—if the AD LDS objects in a configuration have been deleted in AD DS.
/so configuration_dn object_dn	Performs a replication synchronization for the specified object in the specified configuration. Use the distinguished name of the object.

• You must have Read or Dirsync access to the objects or partitions in the AD DS forest that you want to synchronize.
• You must have full control of an application directory partition on an AD LDS instance to run this command.