Sunday, 29 April 2012

What is an SNTP?

0 comments
The Simple Network Time Protocol (SNTP) is a simpler version of the Network Time Protocol (NTP). SNTP synchronizes the time between networked computer systems and is relied on when data is being transferred via the Internet. The NTP protocol is one of the most established protocols still used on the Internet. It uses a GPS or radio clock to tell time and is accurate past the seconds place.
Why is the SNTP Necessary?
The need for precise time synchronization has continued to increase with the evolution of computer technology over the past several decades. In the networking field, network servers and their client computers require precision to the millisecond and beyond in order to ensure data file transfers occur without errors. Computers also require specific time synchronization in order to ensure data packet and email delivery in the proper sequence to destination networks and email recipients. The importance of the SNTP and NTP protocols exponentially expands with the number of computers that are on a network in order to prioritize network traffic appropriately.
Computers that Use the SNTP Protocol
Servers are the primary SNTP protocol users. Servers use the protocol in order to keep the time on network services and client computers synchronized based on Internet standards. Web servers that put a heavy demand on traffic may have to switch to the NTP for time service requirements. However, the SNTP protocol is suitable for providing the time for all services and client computers on small to medium networks.
What are the Security Implications of the SNTP Protocol?
The SNTP protocol’s data is subject to packet sniffing since it is plain text that is transmitted over a local network and the Internet without encryption. It may also be susceptible to a dictionary or brute force attack in order to guess the authentication and encryption keys and strings. The protocol also uses the UDP communications protocol, which may be open to IP spoofing attacks.

Wednesday, 11 April 2012

Prepare your Domain for the Windows Server 2008 R2 Domain Controller

0 comments
Before installing the first Windows Server 2008 R2 domain controller (DC) into an existing Windows 2000, Windows Server 2003 or Windows Server 2008 domain, you must prepare the AD forest and domain. You do so by running a tool called ADPREP.



ADPREP extends the Active Directory schema and updates permissions as necessary to prepare a forest and domain for a domain controller that runs the Windows Server 2008 R2 operating system.
Note: You may remember that ADPREP was used on previous operating systems such as Windows Server 2003, Windows Server 2003 R2 and Windows Server 2008. This article focuses on Windows Server 2008 R2.
What does ADPREP do? ADPREP has parameters that perform a variety of operations that help prepare an existing Active Directory environment for a domain controller that runs Windows Server 2008 R2. Not all versions of ADPREP perform the same operations, but generally the different types of operations that ADPREP can perform include the following:
  • Updating the Active Directory schema
  • Updating security descriptors
  • Modifying access control lists (ACLs) on Active Directory objects and on files in the SYSVOL shared folder
  • Creating new objects, as needed
  • Creating new containers, as needed
To prepare the forest and domain for the installation of the first Windows Server 2008 R2 domain controller please perform these tasks:
Lamer note: The following tasks are required ONLY before adding the first Windows Server 2008 R2 domain controller. If you plan on simply joining a Windows Server 2008 R2 Server to the domain and configuring as a regular member server, none of the following tasks are required.
Another lamer note: Please make sure you read the system requirements for Windows Server 2008 R2. For example, you cannot join a Windows Server 2008 R2 server to a Windows NT 4.0 domain, not can it participate as a domain controller in a mixed domain. If any domain controllers in the forest are running Windows 2000 Server, they must be running Service Pack 4 (SP4).
First, you should review and understand the schema updates and other changes that ADPREP makes as part of the schema management process in Active Directory Domain Services (AD DS). You should test the ADPREP schema updates in a lab environment to ensure that they will not conflict with any applications that run in your environment.
You must make a system state backup for your domain controllers, including the schema master and at least one other domain controller from each domain in the forest (you do have backups, don't you?).
Also, make sure that you can log on to the schema master with an account that has sufficient credentials to run adprep /forestprep. You must be a member of the Schema Admins group, the Enterprise Admins group, and the Domain Admins group of the domain that hosts the schema master, which is, by default, the forest root domain.
Next, insert the Windows Server 2008 R2 DVD media into your DVD drive. Note that if you do not have the media handy, you may use the evaluation version that is available to download from Microsoft's website. You can also use an MSDN or Technet ISO image, if you have a subscription to one of them.
If you only have the ISO file and do not want to or cannot actually burn it to a physical DVD media, you can mount it by using a virtual ISO mounting tool such as MagicIso (can Convert BIN to ISO, Create, Edit, Burn, Extract ISO file, ISO/BIN converter/extractor/editor).
Browse to the X:\support\adprep folder, where X: is the drive letter of your DVD drive. Find a file called adprep.exe or adprep32.exe.
Note: Unlike in Windows Server 2008 where you had to use either the 32-bit or 64-bit installation media to get the right version of ADPREP, Windows Server 2008 R2 ADPREP is available in a 32-bit version and a 64-bit version. The 64-bit version runs by default. If you need to run ADPREP on a 32-bit computer, run the 32-bit version (adprep32.exe).
To perform this procedure, you must use an account that has membership in all of the following groups:
  • Enterprise Admins
  • Schema Admins
  • Domain Admins for the domain that contains the schema master
Open a Command Prompt window by typing CMD and pressing ENTER in the Run menu.
Drag the adprep.exe file from the Windows Explorer window to the Command Prompt window. Naturally, if you want, you can always manually type the path of the file in the Command Prompt window if that makes you feel better...
Note: You must run adprep.exe from an elevated command prompt. To open an elevated command prompt, click Start, right-click Command Prompt, and then click Run as administrator.
Note: If your existing DCs are Windows Server 2008, dragging and dropping into a Command Prompt window will not work, as that feature was intentionally disabled in windows Server 2008 and Windows Vista.
In the Command Prompt window, type the following command:
adprep /forestprep
You will be prompted to type the letter "c" and then press ENTER. After doing so, process will begin.
ADPREP will take several minutes to complete. During that time, several LDF files will be imported into the AD Schema, and messages will be displayed in the Command Prompt window. File sch47.ldf seems to be the largest one.
When completed, you will receive a success message.
Note: As mentioned above, ADPREP should only be run on an existing DC. When trying to run it from a non-DC, you will get this error:
Adprep cannot run on this platform because it is not an Active Directory Domain
Controller.
[Status/Consequence]
Adprep stopped without making any changes.
[User Action]
Run Adprep on a Active Directory Domain Controller.
Allow the operation to complete, and then allow the changes to replicate throughout the forest before you prepare any domains for a domain controller that runs Windows Server 2008 R2.
In the Command Prompt window, type the following command:
adprep /domainprep
Process will take less than a second.
ADPREP must only be run in a Windows 2000 Native Mode or higher. If you attempt to run in Mixed Mode you will get this error:
Adprep detected that the domain is not in native mode
[Status/Consequence]
Adprep has stopped without making changes.
[User Action]
Configure the domain to run in native mode and re-run domainprep
Allow the operation to complete, and then allow the changes to replicate throughout the forest before you prepare any domains for a domain controller that runs Windows Server 2008 R2.
If you're running a Windows 2008 Active Directory domain, that's it, no additional tasks are needed.
If you're running a Windows 2000 Active Directory domain, you must also the following command:
adprep /domainprep /gpprep
Allow the operation to complete, and then allow the changes to replicate throughout the forest before you prepare any domains for a domain controller that runs Windows Server 2008 R2.


Find Out Who Is Logged Into A Server And Kick Them Off

0 comments

If you remote onto a Windows server with any kind of regularity, you will probably have come across a scenario where the number of concurrent connections has reached the limit. This is often followed by shouting across the office or sending an email asking people if they are connected and whether they can log off so you can get on.
Well, shout no longer as you can find out who's logged onto a machine by running this simple command in command prompt. In this example, the server name is "YOURSERVERNAME".
query session /server:YOURSERVERNAME
And if you find out that someone has logged in and then left the country, you can kick them off too - the above command will tell you each user's session id and you can use this to boot them off the box. In this example, the session id is 1.

rwinsta /server:YOURSERVERNAME 1

How to track users logon/logoff

1 comments

The Auditing


Option 1:

1. Enable Auditing on the domain level by using Group Policy:

      Computer Configuration/Windows Settings/Security Settings/Local Policies/Audit Policy
      There are two types of auditing that address logging on, they are Audit Logon Events and Audit Account Logon Events.

      Audit "logon events" records logons on the PC(s) targeted by the policy and the results appear in the Security Log on that PC(s).

      Audit "Account Logon" Events tracks logons to the domain, and the results appear in the Security Log on domain controllers only


2. Create a logon script on the required domain/OU/user account with the following content:

     echo %date%,%time%,%computername%,%username%,%sessionname%,%logonserver% >>
        \\SERVER\SHARENAME$\LOGON.LOG

3. Create a logoff script on the required domain/OU/user account with the following content:

     echo %date%,%time%,%computername%,%username%,%sessionname%,%logonserver% >>
        \\SERVER\SHARENAME$\LOGOFF.LOG


Note: Please be aware that unauthorized users can change this scripts, due the requirement that

                  the SHARENAME$ will be writeable by users.


Option 2:


Use WMI/ADSI to query each domain controller for logon/logoff events.

Tuesday, 10 April 2012

Migrating Server 2003 to Server 2008 R2

0 comments

1. Verify the new server's TCP/IP configuration has been pointed to the current DNS server.

2. Make the new server become a member server of the current Windows Server 2003 domain first.

3. Upgrade the Windows Server 2003 forest schema to Windows Server 2008 schema with the "adprep /forestprep" command on old server.

Please run the "adprep.exe /forestprep" command from the Windows Server 2008 installation disk on the schema master. To do this, insert the Windows Server 2008 installation disk, and then type the following command:

Drive:\sources\ADPREP\adprep.exe /forestprep

4. Upgrade the Windows 2003 domain schema with the "adprep /domainprep" command on old server.

Please run the "adprep.exe /domainprep" command from the Windows Server 2008 installation disk on the infrastructure master. To do this, insert the Windows Server 2008 installation disk, and then type the following command:

Drive:\sources\ADPREP \adprep.exe /domainprep

5. Insert Windows Server 2008 Installation Disc in the new server.


6. Run "dcpromo" on new server to promote it as an additional domain controller in existing Windows 2003 domain, afterwards you may verify the installation of Active Directory.

Please refer to:
How to Verify an Active Directory Installation in Windows Server 2003

7. Verify the new server's TCP/IP configuration has been pointed to current DNS server.

8. Enable Global Catalog on new server and manually Check Replication Topology and afterwards manually trigger replication (Replicate Now) to synchronize Active Directory database between 2 replicas.

Please note: It will some time to replicate GC between DC, please wait some time with patience.

9. Disable Global Catalog on the old DC.

10. Transfer all the FSMO roles from the old DC to the new DC.

Please refer to:
How to view and transfer FSMO roles in Windows Server 2003

11. Verify that the old DNS Server Zone type is Active Directory-Integrated. If not, please refer to:

How To: Convert DNS Primary Server to Active Directory Integrated

Note: Active Directory Integrated-Zone is available only if DNS server is a domain controller.

12. Install DNS component on new server and configure it as a new DNS Server (Active Directory Integrated-Zone is preferred). All the DNS configuration should be replicated to the new DNS server with Active Directory Replication.

13. Make all the clients change TCP/IP configuration to point to new server as DNS.

14. You may configure TCP/IP on all the clients, or adjust DHCP scope settings to make them use the new DNS server.

Tuesday, 3 April 2012

How do I create a MSI wrapper over EXE installation files?

0 comments

In order to exemplify the procedure, we will assume to wrap three .EXE installers "test1.exe", "test2.exe" and "test3.exe" into a .MSI. Here are the steps:

1. In Product Details Tab (Product Details Page) under "Add or Remove Programs (Control Panel)" group, uncheck the "Register product with Windows Installer" option. We don't want the wrapper to appear in "Control Panel" -> "Add or Remove Programs" as an installed program.

2. Go to Files and Folders Page and add the .EXE installers in the "Application Folder".

3. Create a .BAT file with the following content and add it in the Files and Folders Page:

"|InstallPath|test1.exe"
"|InstallPath|test2.exe"
"|InstallPath|test3.exe"

5.  In the same folder, using the toolbar or context menu, create a text file update for the .BAT file. This file update should include a single replace operation:

Find : |InstallPath|
Replace : [APPDIR]
6.  In the Custom Actions Page add the .BAT file as a "Launch File or Open URL" custom action after the "Finish Execution" action group from "Install Execution Stage":

In the "Execution Properties" group on the right page make sure you choose the "Asynchronous execution, do not wait for return" option.
Also enable only the "Install" option from the "Execute Sequence Condition" group.


How to deploy a MSI on multiple machines by using Group Policy.

0 comments

1. Methods of deployment

Group Policy supports two methods of deploying a MSI package:

Assign software - A program can be assigned per-user or per-machine. If its assigned per-user, it will be installed when the user logs on. However, if its assigned per-machine then the program will be installed for all users when the machine starts.
Publish software - A program can be published for one or more users. This program will be added to the Add or Remove Programs list and the user will be able to install it from there.

2. Create a distribution point

The first step in deploying a MSI through GPO is to create a distribution point on the publishing server. This can be done by following these steps:

A.log on to the server as an Administrator user
B. create a shared network folder (this folder will contain the MSI package)
C. set permissions on this folder in order to allow access to the distribution package
D. copy the MSI in the shared folder
E. In the shared folder you can also perform an administrative install for a MSI package contained by an EXE bootstrapper.

3. Create a Group Policy Object

A MSI package is deployed (distributed) through GPO as a Group Policy Object. In order to create an object for your package, you can follow these steps:

A. click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
B. right-click your domain name in the console tree and select the Properties context menu
C. select the Group Policy tab and click New
D. set the name of the policy (for example MyApplication)
E. click Properties and select the Security tab
F. check the Apply Group Policy checkbox only for the groups to which the policy will be applied
G. click on the OK button

4. Assign a MSI package

A package can be assigned per-user or per-machine. Also, if the package is assigned, it will automatically be installed silently. In order to assign a package you can follow these steps:

A. click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
B. right-click your domain name in the console tree and select the Properties context menu
C. go to the Group Policy tab, select the object you want and click Edit
D. expand Software Settings under Computer Configuration
E. right-click Software Installation, select the New context menu and then click on Package
in the Open dialog type the full UNC path of the shared package you want to assign
F. click on the Open button
G. click on Assigned and then click OK (the package will be added to the right pane of the "Group Policy" window)
H. close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in
when the client computers start, the assigned package will be installed automatically
Do not use the Browse button in the Open dialog to access the UNC location. Make sure that you use the UNC path to the shared package.

5. Publish a MSI package

When using Group Policy, you can publish a package in order to allow the target user to install it by using Add or Remove programs. The steps for publishing a package are:

A. click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
B. right-click your domain name in the console tree and select the Properties context menu
C. go to the Group Policy tab, select the object you want and click Edit
D. expand Software Settings under User Configuration
E. right-click Software Installation, select the New context menu and then click on Package
in the Open dialog type the full UNC path of the shared package you want to publish
F. click on the Open button
G. click on Publish and then click OK (the package will be added to the right pane of the "Group Policy" window)
H. close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in
test the package:
I. log on to the target computer
J. click on the Start button and go to Control Panel
K. double-click the Add or Remove programs applet and select Add New Programs
in the Add programs from your network list select the program you published
use the Add button to install the package
L. click OK and then Close
Do not use the Browse button in the Open dialog to access the UNC location. Make sure that you use the UNC path to the shared package.

6. Redeploy a MSI package

Sometimes you may need to redeploy a package (for example when doing an upgrade). For redeploying a package you can follow these steps:

A. click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
B. right-click your domain name in the console tree and select the Properties context menu
C. go to the Group Policy tab, select the object you used to deploy the package and click Edit
D. expand the Software Settings element (per-user or per-machine) which contains the deployed package
E. expand the Software Installation element which contains the deployed package
F. right-click the package in the right pane of the Group Policy window
G. select the All Tasks menu and click Redeploy application
H. click the Yes button for reinstalling the application wherever it is installed
I. close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in

7. Remove a MSI package

Group Policy also allows you to remove packages which have been deployed in the past. Here are the steps for removing a package:

A. click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
B. right-click your domain name in the console tree and select the Properties context menu
C. go to the Group Policy tab, select the object you used to deploy the package and click Edit
D. expand the Software Settings element (per-user or per-machine) which contains the deployed package
E. expand the Software Installation element which contains the deployed package
F. right-click the package in the right pane of the Group Policy window
G. select the All Tasks menu and click Remove
H. select from the following options:
I. Immediately uninstall the software from users and computers
J. Allow users to continue to use the software but prevent new installations
K. click the OK button to continue
L. close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in