Posts Tagged ‘Microsoft’
Boost your internal PKI/Microsoft CA security with FREE green Extended Validation SSL in 15 minutes or close your eyes until 2016!
One of the new CAB Forum baseline requirements is that all SSL certificate issuers are to stop issuing SSL certificates with internal host names and IP addresses. Currently it is possible to get internal host names in public certificates until 2016, but after 1. July it will be shortened to 2015. But keep reading and you will remove this threat today, instead of waiting to 2015-2016.
Normal usage of SSL certificates
Most companies with a medium to large infrastructure, use an internal PKI solution like Microsoft Certification Authority for identity and encryption on internal workstations and accounts. They will also use internal CA to issue certificates for server systems that are only accessed by internal computers where Root CA trust can be controlled automatically thru GPO or similar.
But external facing websites and server systems use public external CA issued SSL certificates, to ensure trust by all units including mobile units and external computers.
(did you see the padlock in the above image?)
Example of attack
It makes sense to prevent easy attacks on the identity part of SSL security for internal systems. Any internal website would be easy to replace with a fake site or do a man in the middle attack with a real external publically trusted SSL certificate that includes the internal host names. Example: an internal password management portal on https://mypassword.abc-organization.local. The intruder gets a certificate issued to www.notyours.dk including a SAN name “mypassword.abc-organization.local”. It would be easy for the intruder to setup a fake website to harvest passwords with a real SSL certificate that all clients would trust equally to their internally issued SSL certificate on the existing system. Clients would see the padlock with no visible changes. Read the rest of this entry »
How to configure your virtual Domain Controllers and avoid simple mistakes with resulting big problems
So You went ahead and used virtualized Domain Controllers for Your Active Directory domain, congratulations! I am sure You will be happy with the decission, as long as You have a decent virtualizing environment, this will give You both peace of mind, faster recovery and cheaper redundancy.
There is however some special considerations You must do, when You are using virtual Domain Controllers, not to mention, please with sugar on top, do NOT P2V/Convert Your physical Domain Controllers to virtual, without at least reading this article!
What areas do we need to consider on a virtual DC?
- Time synchronization
- Disk cache
- Suspend/pausing virtual machine
- Snapshots and System State backups
Personally I much prefer virtual Domain Controllers, from having a lot of physical ones, but there are some considerations to be made, about perhaps leaving some physical and what features to use on the virtual and what settings to use as well. This article attempts to uncover some of the points to consider, specifically for virtal DC's. The list is in no way meant to be the only considerations, but is mostly the things that I personally have noticed forgotten in environments I have encountered. Add Your own preferences and research to this and You should be well on Your way to live happily forever with Your virtual DC's.
I might be realy slow in discovering this, after all it has been some months since I last touched an OCS installation. I seriusly wished I had this tool when I was last time thou.
This tool just like the Exchange testing tool, will show all the steps involved in connecting to an OCS system and produce any errors and confirmations that everything is working, excellent for debugging or even just validating that everything is working as it should. I found the link to the tool on a new danish UM experience sharing group (all danish) http://www.colabora.dk/.
The actual tool can be found here: https://www.testocsconnectivity.com/
Thought I would also add some extra info and show what the tool can produce of results (FQDN's and IP's changed)
How to disable administrative shares on workstations thru Group Policy and avoid spending time on pesty virus infections
Large companies sometimes have problems with a virus that realy loves administrative shares on other workstations (i.e. c$ and admin$), it will try and break into theese to spread it self directly. The easy option ofcourse being kill the virus or even better harden administrative users and not use administrator rights for normal users! But untill that is an easy, non-political and not so time consuming task, why not disable the administrative shares on the workstations alltogether?
Seems like a perfect thing to do with Group Policy, unfortunately the setting is non-existing default in Group Policies, so by finding the registry key we need to change, a small custom administrative template will do the trick. This could also be used for other registry changes needed with group policy.
We might also want the option to easily enable the administrative shares later, might be used by applications, services, automated installations, etc. Heres is how to do it quick and easy. Read the rest of this entry »
How to publish RD Web & Gateway (2008 r2) on ISA 2006, and still have time to watch The Big Bang Theory!
So I was asked the question, how do You publish the new Windows Server 2008 and 2008 R2 editions of Terminal Server, including the RD Web and RD Gateway (GW) services. And on top of that still use the ISA 2006 as authentication with Forms Based Authentication (needed in this case for RSA keys). Sounds easy enough right? Wrong!
Well once You get your head wrapped around the limitations, which of course are always hard to find documentation on, then it is easy enough. Basicly the RD Web service is easy enough to get working, simple next next next, will get You there with little trouble.(The RD Gateway on the other hand...)
Configure a ISA 2006 rule, with relevant web listener (or existing if appropiate), allow the /rdweb/* paths, use FBA authentication, use NTLM delegation of authentication to the internal webserver, configure the webserver (RD WEB) to use NTLM, install relevant SSL certificates to ISA and webserver, and presto it works! It even works with SSO if needed, and the user is only prompted by the ISA forms and not a second time by the RD Web site.
So far so good! A small hint before we go on, if You want to add multiple connections to other Terminal Servers in the RD Website, Read the rest of this entry »
Please pretty please do not just hit the button and P2V/ColdClone/HotClone/Copy your Windows Server Domain Controllers, regardless if they run Windows Server 2000/2003/2008 etc.
In best case You accomplish to virtualize your domain controllers, wich You could have done with a few simple steps just as easily with out any danger.
In worst case You render your Domain Controllers useless, create several other problems and hickups in your infrastructure, not limited to complete production halt and at least several hours of pain and horror trying to get everything back and running!
Personally I have nothing against virtual Domain Controllers, usually best practice is not to run all kinds of other software or services on a Domain Controller, plus the need to have multiple Domain Controllers for redundancy will quickly add alot of boxes doing very little. Virtualizing some or all of these Domain Controllers, will put better use of ressources and still keep the box seperate from other services. Dont forget to change time synchronisation settings in the w32time service, vmware tools and ntp servers in the ESX's, but thats another story.
One of the big problems with doing a clone of a Domain Controller, is that if you get problems, you will not notice them untill it is too late. The domain controller will seem to function and work with clients, but it will actually have stopped replicating with all other domain controllers, because it has detected that it has been copied. The result is an inconsistent domain with client records not being updated, they will slowly stop working depending on what domain controller they get in contact with, untill everything goes dead. If you have then virtualized ALL domain controllers, You will be left with 1-3 months of changes going down the tube together with your damaged Domain Controllers. Dont forget to take a full backup of at least 1 Domain Controller before starting your cloning!
So what happens when things go bad? Read the rest of this entry »