Hviidnet.com
28Jan/100

SSL Vpn With 2008 Server

Now-a-days, every business is mobile, which means a VPN connection is most likely needed.  The problem is when clients travel to hotels or other countries, where firewall compatiblity and configuration can cause connectivity issues.  Fortunately, there is an answer for this: SSL VPNs.  Since an SSL VPN connection is secure and allowed on almost all firewalls, remote users will have a much more reliable connection mechanism; no matter where they are.  To top it off, SSL VPN (SSTP) is a feature natively bundled with Windows Server 2008.

How does SSL VPNs help?

* A NAT device doesn’t need to support PPTP in order for it to work.
* Specific ports aren’t required to be open on the firewall (think hotels and other countries).
* Connectivity can be made through web proxy servers.
* The small footprint VPN client is easily accessible.

Clients supported: Vista SP1+, Windows 7, Windows Server 2008

What are the high level steps involved to setting up Windows Server 2008 SSL VPN connections (SSTP)?

* Obtain a certificate to be used for your connections (just as if you are installing an SSL certificate for your website)
* Install IIS on the VPN server
* Request a certificate for the VPN server using the IIS Certificate Request Wizard
* Install the SSL certificate
* Install the RRAS server role on the VPN server
* Enable the RRAS Server and configure it to be a VPN server
* Configure the User Account to allow dial-up connections
* Update DNS (ie. vpn.company.com)
* Configure the Client to use SSTP and Connect to the VPN Server using SSTP

How-To configure Windows 2008 for SSTP VPN

1.  Install IIS on VPN server with all security settings marked for installation
2.  Create a Certificate Request in IIS console
a.  Make sure common name is actual Internet Hostname clients will connect to (e.g. vpn.company.com)
3.  Cut and Paste the certificate request into your SSL provider’s website
4.  Install any Intermediary certificates and your SSL certificate per your SSL provider’s instructions (DO NOT bind the certificate to a website in IIS)
5.  Install Routing and Remote Access
6.  Load the Routing and Remote Access MMC and run the wizard to enable it (Select Custom -> VPN if you are using only 1 NIC)
8.  Enable Dial-In access for the remote user’s AD account
9.  Enabled SSL connection (port 443) from the outside
10. Update DNS for the domain with the common name of the certificate
11. Test the SSL VPN connection by choosing SSTP in the vpn network connection properties

If the connection doesn’t work, make sure the proper certificate is bound following:

1.  Make sure the right certificate hash is bound (netsh http show  ssl)
a. If necessary, delete and readd the correct certificate binding…
1. Remove binding from IPv4 (netsh http delete ssl 0.0.0.0:443)
2. Remove binding from IPv6 (netsh http delete ssl [::]:443)
3. Delete registry entry for the hash (reg delete hklm\system\currentcontrolset\services\sstpsvc\parameters /v sha256certificatehash /f)
4. Add binding from IPv4 (netsh http add sslcert ipport=0.0.0.0:443 certhash=<replace with your cert hash> appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY)
5. Add binding from IPv6 (netsh http add sslcert ipport=[::]:443 certhash=<replace with your cert hash> appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY)

9Jul/090

winrm and winrs a management tool for windows 2008

If you are using Windows 2008 Server, WinRM is installed but not enabled by default. This is a good security precaution. The easiest way to determine if WinRM is already enabled and started on your machine is to go to a CMD prompt and run:

winrm enumerate winrm/config/listener

If you get no response them WinRM is not running. To configure WinRM to start automatically and allow for remote access, use the winrm quickconfig command like this:

C:\Users\Administrator> winrm quickconfig
WinRM is not set up to allow remote access to this machine for management.
The following changes must be made:
Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
Make these changes [y/n]? y
WinRM has been updated for remote management.
Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
C:\Users\Administrator>

Once I configured the quickconfig, I reran the enumeration command with these results:

C:\Users\Administrator> winrm e winrm/config/listener
Listener
Address = *
Transport = HTTP
Port = 80
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 10.253.15.98, 127.0.0.1, ::1, fe80::5efe:10.253.15.98%11, fe80::9583:2148:e1ef:6444%10
C:\Users\Administrator

From this, I know that WinRMis enabled.

Similar in operation to the former Sysinternals tool PSExec, WinRS leverages Windows Remote Management to let you launch processes on remote machines. Where it differs from PSExec is in its ability to easily pass through firewalls in the same way as WinRM. For example, if you want to discover IP information about a remote machine, you can remotely launch ipconfig with the -all switch on that machine using this syntax:

winrs -r:{Remote Host} ipconfig -all

Another handy use of WinRS can be when installing software on remote systems. If you want to quietly install an application using an MSI file onto a remote machine, use the following syntax. This syntax assumes the MSI file has already been deposited into the C:\ folder.

winrs -r:{Remote Host} msiexec.exe /i c:\install.msi /quiet

I have used this for other things as creating a centralised backup with windows backup (Windows 2008 only) and then ship the completion logs directly to the same server. Simply make a batch file containing all our severs like this:

winrs -r:{Remote Host} wbadmin start backup -backupTarget:\\{Remote Host}\backup\weeknumber -include:C: -allCritical -vssFull -quiet

hope you enjoy. Please leve a comment if you liked thic article

25May/090

Securing RDP connections with Certificates

I had been looking for this for a long time, and finally i found the solution.

ALL credit for this article goes to: petri.co.il so if you have any questions go ask them there and be sure to thank them there and not in this thread ;) They deserve it!

When Microsoft Windows 2000 was released many years ago, administrators were blessed with new functionality called Terminal Services which easily allowed remote administration of a server. The functionality or the concept was actually not new. Administrators of Windows operating systems as well as other platforms are plenty familiar with the concept of remote administration. For Windows and some many other platforms, remote administration was accomplished through the use of 3rd party tools which meant the purchase of an extra remote administration tool license for every server that is deployed. While the licensing costs generally weren’t terrible, especially for what is gained in return (ease of remote administration, working from home in your pajamas while smoking a cigar like I’m doing now), the costs could add up quickly for infrastructures with large numbers of servers to remotely administrate. What was new, however, was that Windows 2000 introduced a remote administration tool that was built into the OS with no bolt-on licensing costs needed. The tool was called Terminal Services and other than a few minor quirks that it had such as software installation problems in Terminal Services, drive letters not dynamically added/removed without a logoff/logon, not a true console0, etc., it was a God send and still is to this day.

The release of Windows XP brought us an overhauled remote administration tool. The Terminal Services client was still a viable tool but the version in Windows XP called Remote Desktop Connection was, well, cooler. In typical Microsoft fashion, the new tool brought with it some added functionality to make administrator’s lives even easier.

Fast forward to the year 2006. A new version of the Remote Desktop Connection (5.2) had been released for download from Microsoft which added the ability for more secure communications. Then finally Windows Server 2003 Service Pack 1 was released which delivered a slightly updated version of the tool (5.2.3790.1830) which allows the initiating client to require secure communication with a remote server which is what I wanted to write about a little today. Today we live in a world where security is held in much higher regard. Sure it was talked about in the 1990s and for those who are old school certification nuts, you probably even got a few exam questions on security way back when, but today with the events of 9/11, terrorists, internet availability and anonymity, wireless networks, and computer hacking, maintaining a secure network has really come to the forefront as a hot topic. This writing will showcase a method to securing communications between a server and a client using the Remote Desktop Connection and the Remote Desktop Protocol (RDP).

In the example that follows, we will have a Windows client named client.contoso.com and a server named server.contoso.com which is running Windows Server 2003 SP1. Neither machine is a member of a domain; both are running as members of a workgroup. Our example will make use of digitally signed certificates using with server.contoso.com being a stand alone root CA. In a practical environment, not every server that you RDP to needs to be running a CA, in fact, most servers won’t be running a CA, but since we only have two machines in our example, I chose the server to run the CA services. In your environment, you may already have a stand-alone or enterprise CA. Either can be used to issue certificates to the machines in which you wish to establish a secure RDP session with. It is assumed that by this point, you already have a CA in place in your infrastructure or you are making use of an external CA. You also have configured the server to receive remote desktop connections. In our example, we have obtained a certificate and installed it already on server.contoso.com.

First we configure the server. Under Administrative Tools, open Terminal Services Configuration. Double click RDP-TCP to configure the properties of Terminal Services using the RDP protocol. Under the general tab to the right of the word certificate, click Edit. Choose the installed certificate that you wish to associate with the Terminal Services connection over RDP:

Back under the general tab, you will now be able to choose SSL for the security layer. This is what ultimately requires the use of certificates for the RDP communication on the server side. Take a quick look at the encryption level setting. Choices are client compatible, high, or FIPS. Client compatible means enforce the highest level of encryption that the connecting client supports. High means enforce the highest level of encryption that the server supports. FIPS means enforce FIPS encryption on both the server and the client. FIPS is government approved level of encryption.

Now let’s move over to the client. The first thing we need to is ensure that the client trusts the CA chain that the server’s certificate was issued from. If this has not been done already, I will quickly walk you through the steps involved with a stand-alone CA. On the client, open a web browser and go to http://servername/certsrv/. Click Download a CA certificate, certificate chain, or CRL:

Choose Install this CA certificate chain:

Choose Yes:

Choose Yes:

At this point you can close the web browser on the client machine:

Ensure that on the client, Remote Desktop Connection version 5.2.3790.1830 is installed (read Download RDP 5.2). If it is not installed, you can install it from a server running Windows Server 2003 SP1. The source files are located on the server in c:'windows'system32'clients'tsclient'.

Open the Remote Desktop Connection client. Click on the Options button so that you can view all configurable options. Click on the Security tab. Choose Require Authentication in the pull down box.

Click on the General tab. Enter the FQDN name of the server you will be connecting to. It is important here to enter the FQDN name:

You will receive the following warning. Click the button labeled View Certificate:

Click Install Certificate:

Click Next:

Click Next:

Click Finish:

Click Yes:

Click OK:

Click OK and you the Remote Desktop Connection will close:

Now that the certificate is installed on the client, we may connect. Remember to use the FQDN here because that is what is contained in the server’s certificate:

We have now established a secure encrypted Remote Desktop Connection from the client to the server:

Clicking on the small padlock at the top of the screen ensures are secure connection by displaying the certificate that is in use:

9Apr/090

Microsoft Netbook idea – Origami!

NOTE: The original article can be found on www.mydigitallife.info - This is their work not mine!

Origami Experience is a operation interface software from Microsoft similar to Windows Media Center (MCE). Origami Experience is designed for Ultra-Mobile PCs that run Windows Vista. The current version of Origami Experience is v2.0. Origami Experience 2.0 combines four programs that make your ultra-Mobile PC (UMPC) running Windows Vista even easier to use.

Microsoft Origami Experience 2.0 contains these four programs for an ultra-Mobile PC (UMPC) running Windows Vista:

  • Origami Central
    Central gives you instant access to all your media, programs, and the Internet, with the touch of a finger.
  • Origami Now
    Now gives you one-touch access to the most important information at any given time and place.
  • Origami Picture Password
    With a Picture Password, you can log on to Windows and unlock your computer by tapping a sequence of targets on a picture, instead of typing a password.
  • Touch Settings
    Touch Settings combines several settings in Windows Vista into one place to make it easier to customize a touch screen.

Microsoft Origami Experience 2.0 is available to download from Microsoft Download Center, but it requires user’s system to pass the WGA (genuine Windows) validation. If you always fail to pass the validation test, or don’t want to install any ActiveX control for validation, use the direct download link below to start downloading.

Direct download link to Origami Experience 2.0: OrigamiExperiencePackv2.msi

16Feb/093

Installing Windows Vista or 7 on USB stick

WHY INSTALL FROM USB FLASH DRIVE?
Why would someone want to install a client OS from a thumb drive instead of a DVDROM or over the network?  One reason:  Performance.  Installing Windows Vista from a high speed USB flash drive is in my experience the easiest & fastest way to complete a Windows Vista install.  This is much faster than using a DVD, gigabit ethernet, or possibly even some external USB 2.0 hard drives, due to differences in access speed & transfer rate.  To put this into perspective, y'know how installing Windows on a Virtual PC virtual machine from an .ISO CD image is really, really, really fast?  Imagine something roughly just as fast, except for doing installations of the OS on to actual workstations.

STEP-BY-STEP INSTRUCTIONS
Here's some step-by-step instructions on how we do this.

  1. Format the Flash Drive
    Run CMD.EXE and type the following.  Note: This set of commands assumes that the USB flash drive is addressed as "disk 1".  you should double check that by doing a list of the disks (type "list disk") before cleaning it.  If you have multiple hard drives, like an SDFlash drive or a Multibay drive, you could end up wiping your second drive using this command.

    1. diskpart
    2. select disk 1
    3. clean
    4. create partition primary
    5. select partition 1
    6. active
    7. format fs=fat32 quick
    8. assign
    9. exit
  2. Copy Windows Vista's DVD ROM content to the Flash Drive
    Simply issue the following command to start copying all the content from the Windows Vista DVD to your newly formatted high speed flash drive.

    • xcopy d:\*.* /s/e/f e:\

And that's it.  Boot up the machine, have it boot off the USB drive, and watch how fast the installation completes.  If you thought Windows Vista installed quickly before then let's see how you like it now.  The slowest part of the install will probably be the computer waiting for you to type in information in the setup fields, and even that can be automated using the Windows Automated Installation Kit.

Seems microsoft just found out they can do this with windows 7 ;) take a look HERE for a foolproof guide with 10.000 screenshots.

Tagged as: , , 3 Comments