mainesysadmin.com

With the client access role in exchange 2007 brought the need to work with and customize ssl for the internal domain activity of the server.  If the ssl is not replaced the Outlook clients will provide an ssl warning every time the app is launched.  To resolve this here is how you can get a custom ssl cert from your local CA.

• For generating a CSR in exchange 2007 I’ve been using this website tool: https://www.digicert.com/easy-csr/exchange2007.htm.  You can fill out the small form and then copy/paste the command that was generated into your exchange server’s management shell.  If you’re a CLI junky you can reference this bit of code and replace your information in the correct spots:

New-ExchangeCertificate -GenerateRequest -Path c:\exchange_mydomain_com.csr -KeySize 2048 -SubjectName "c=US, s=New York, l=Your City, o=Your Company, ou=Your Department, cn=exchange.mydomain.com" -DomainName exchange, exchange.mydomain.com, autodiscover, autodiscover.mydomain.com -PrivateKeyExportable $True

• The CSR will be located here:  c:\
• Use your local Microsoft CA server and import the csr to generate a new ssl certificate.
• Download the new certificate to the c:\ of your exchange server.
• Run this command in your exchange management shell to import the certificate.

Import-ExchangeCertificate -path c:\certnew.cer

(where certnew.cer is the location where you downloaded the cer from your CA server)

• Following the import the the command will output the thumbprint for the ssl.  Use the menu in the top left corner of the exchange management shell (left click once for the menu to appear).  Mark and copy the thumbprint, you need this for the next step.
• Run this last command to enable the ssl certificate for exchange usage.

Enable-ExchangeCertficate -services IIS, UM, SMTP - thumbprint "paste your thumbprint here"

(If this is just for client access you only need IIS for the service option.)

I was browsing zdnet today and found a useful article.  In the new 32 bit version of Windows 7 and previous versions of Vista you can enable a custom control panel anywhere you want and control just about the whole operating system.

Here is the blurb from zdnet:

“Although its name suggests perhaps even grander capabilities, Windows enthusiasts are excited over the discovery of a hidden “GodMode” feature that lets users access all of the operating system’s control panels from within a single folder.

To enter “GodMode,” one need only create a new folder and then rename the folder to the following:

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

Users are able to have a single place to do everything from changing the look of the mouse pointer to making a new hard-drive partition.”

http://news.zdnet.com/2100-9595_22-378247.html?tag=trunk;content

One of the challenges organizations come across while upgrading from exchange 2003 to 2007 is supporting both environments during the upgrade migration. I had difficulty finding the perfect solution for my IIS redirect issue, but the following technet article supplied the solution:

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

This is the article from Microsoft that I used on how to create virtual directories for OWA (outlook web access).

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

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

These are the commands that I found useful:

New-OWAVirtualDirectory -OwaVersion:Exchange2003or2000 -VirtualDirectoryType Mailboxes -Name "exchange" -WebSiteName "Contoso.com"

New-OWAVirtualDirectory -OwaVersion:Exchange2003or2000 -VirtualDirectoryType PublicFolders -Name "public" -WebSiteName "Contoso.com"

New-OWAVirtualDirectory -OwaVersion:Exchange2003or2000 -VirtualDirectoryType Exchweb -Name "exchweb" -WebSiteName "Contoso.com"

I’m currently using ESXi for a test environment for an exchange upgrade.  Through configuration I was looking for a way to extend the capabilities of ESXi and required ssh access.  I ran into the following article which I quoted to maintain my own notes, check out the site below:

http://www.yellow-bricks.com/2008/08/10/howto-esxi-and-ssh/

By default this isn’t possible. But there’s a way to get this working, just do the following:

1. Go to the ESXi console and press alt+F1
2. Type: unsupported
3. Enter the root password(No prompt, typing is blindly)
4. At the prompt type “vi /etc/inetd.conf”
5. Look for the line that starts with “#ssh” (you can search with pressing “/”)
6. Remove the “#” (press the “x” if the cursor is on the character)
7. Save “/etc/inetd.conf” by typing “:wq!”
8. Restart the management service “/sbin/services.sh restart”

I ran into a great blog posting here:  http://www.techhead.co.uk/running-vmware-vsphere-client-on-windows-7 on how to enable the VMware vsphere infrastructure client to run on a Windows 7 pc.

***VMware released a KB article regarding this error, but the fix remains the same.  Please refer to this link for the “official supported resolution”

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1011329

Here are a couple of really good reasons on why you need to secure your server’s boot loader regardless if you’re using GRUB or LiLo. In this article I am only going to cover how to configure GRUB.

• Preventing Access to Single User Mode — If attackers can boot the system into single user mode, they are logged in automatically as root without being prompted for the root password.
• Preventing Access to the GRUB Console — If the machine uses GRUB as its boot loader, an attacker can use the use the GRUB editor interface to change its configuration or to gather information using the cat command.

• ssh to your server host with root access
• type: grub to enter the grub console
• type: md5crypt to create a md5 encrypted password (document your password unencrypted and encrypted versions)
• open your favorite editor or download the files via your favorite ftp app. We need: menu.lst and grub.conf they’re located here: /boot/grub
• Add the below line to the top of menu.lst and grub.conf:
  password –md5 “your_encrypted_password” 
• Now add “lock” below each titled o/s choice that you want to prevent from booting without a password.

The method I described above will prevent modification of grub boot options AND only allow you to boot those items that were not password protected with the “lock” command.

I went ahead and manuallly modified menu.lst and grub.conf.

Here is an example of a sample file that you can use as a guide. Replace “your_encrypted_password” with the md5 hash that you generated earlier with the md5crypt command.

grub.conf

I found the following sites useful while writing this article:

http://ubuntuguide.org/wiki/Ubuntu:Edgy/Security

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/security-guide/s1-wstation-boot-sec.html#S2-WSTATION-BOOTLOADER

http://www.linux.com/feature/53569