01/17/13
AnyConnect Secure Mobility Client version 3.1 - Untrusted VPN Server blocked
With the increase of targeted attacks against mobile users on untrusted networks, Cisco has improved the security protections in the AnyConnect Secure Mobility client version 3.1 to help prevent serious security breaches. The default client behavior has been changed to provide an extra layer of defense against man-in-the-middle attacks.
When the user tries to connect to a secure gateway, and there is a certificate error (due to expired, invalid date, wrong key usage, or CN mismatch), the user sees a red-colored dialog with Change Settings and Keep Me Safe buttons.
Clicking Keep Me Safe cancels the connection (Recommended – See Recommendations below).
Clicking Change Settings opens AnyConnect's Advanced > VPN >Preferences dialog, where the user can enable connections to untrusted servers.
If the user un-checks Block connections to untrusted servers, then the next time the user attempts to connect to this secure gateway, the user will not see the Certificate Blocked Error Dialog dialog; they only see the following dialog:
If the user checks Always trust this VPN server and import the certificate, then future connections to this secure gateway will not prompt the user to continue. (Not Recommended)
Recommendations:
You do not want your end users in the habit of ignoring these types of warnings, we strongly encourage following best practices. You should generate a Certificate signing request to be signed by a trusted 3rd Party Certificate Authority. Import the signed certificate onto your VPN appliance to avoid your end users changing the default setting, which is designed to keep them safe.
There is no administrative override to make the end user more secure automatically. To completely remove the preceding security decisions from your end users, enable Strict Certificate Trust in the user's local policy file. When Strict Certificate Trust is enabled, the user sees an error message, and the connection fails; there is no user prompt.
11/08/12
Cisco ACS v5 should be able to query only desired Domain Controllers – Active Directory/DNS Workaround
Background:
Currently in ACS 5.x, ACS queries DNS in order to get a list of all the Domain Controllers in the domain
In a typical Enterprise deployment, it would be common to have a Domain Controller at each local site. More than likely, ACS will be located in datacenters geographically distributed around the globe. The goal is to have ACS authenticate against the local Domain Controller in the same Datacenter.
Issues:
ACS uses DNS to determine which Domain Controller to authenticate each attempt. This default behavior will result in ACS authenticating against every Domain Controller in your environment. See Cisco Bug ID CSCte92062 for additional details.
Example Config
(Ex.) Sample ACS configuration: Sample Site: Charlotte, NC
ACS located in Charlotte, NC CLT0 Servers CLT0DC01
Hostname = CLT0-ACS01
IP Address = 192.168.1.10 Sample Site: Redditch, UK
Subnet Mask = 255.255.255.0 BHX0 Server: BHX0DC01
Default Gateway = 192.168.1.1
Validation: Pre-Change
To perform the next set of test, you must be running a minimum code release of 5.4.0.46. From CLI, issue the following command: acs troubleshoot adinfo -a
CLT0-ACS01/admin# acs troubleshoot adinfo -a
This command is only for advanced troubleshooting and may incur a lot of network traffic
Do you want to continue? (yes/no) yes
Local host name: CLT0-ACS01
Joined to domain: demo.local
Joined as: CLT0-ACS01.demo.local
Pre-win2K name: CLT0-ACS01
Current DC: BHX0DC01.demo.local(this Domain Controller was in Europe, this ACS is in Charlotte, NC)
Preferred site: <unavailable>
Subnet site:
Warning! Unable to locate computer's subnet site in Active Directory.
Please advise your system administrator.
Zone: NULL
Last password set: 2012-10-17 10:58:48 EDT
CentrifyDC mode: connected
Licensed Features: Enabled
Workaround:
Step 1:
In Active Directory: Sites & Services à Subnets: You will need to create a “subnet” in which each ACS resides
Step 2:
In Active Directory: Sites & Services à Sites: You will need to map that same subnet to the appropriate “site”. This should be the site in which you want ACS to authenticate against the desired/local Domain Controllers.
Step 3:
After you have allowed enough time for replication, Disjoin & Rejoin ACS to the Domain. This step will rejoin ACS to the appropriate Domain Controller
· Create a subnet: 192.168.1.0/24
· Edit the CLT0 Site & Add the Subnet: 192.168.1.0/24
Validation Post Change:
From CLI, issue the following command: acs troubleshoot adinfo -a
CLT0-ACS01/admin# acs troubleshoot adinfo -a
This command is only for advanced troubleshooting and may incur a lot of network traffic
Do you want to continue? (yes/no) yes
Local host name: CLT0-ACS01
Joined to domain: demo.local
Joined as: CLT0-ACS01.demo.local
Pre-win2K name: CLT0-ACS01
Current DC: CLT0DC01.demo.local(this Domain Controller is in the Charlotte Datacenter)
Preferred site: CLT0 (the correct server this is mapped to in AD Sites & Services)
Zone: NULL
Last password set: 2012-10-17 10:58:48 EDT
CentrifyDC mode: connected
Licensed Features: Enabled
Conclusion:
By utilizing AD Sites & Services, we are able to have ACS authenticate against the desired Domain Controller(s).
Please note – Cisco ISE uses DNS in order to get a list of all the Domain Controllers in the domain and then authenticates against all of them. This same concept of utilizing AD Sites & Services will ensure Cisco ISE authenticates against the desired Domain Controller vs. any random Domain Controller in the environment.
01/12/12
Changing Tivoli Endpoint Manager service startup from Automatic (Delayed Start) to Automatic
Background
While working in an environment with TEM (IBM's Tivoli Endpoint Manager - formerly BigFix) and Cisco's NAC (Network Admission Control) technology, I ran into an issue with Windows 7 machines not being allowed to pass through NAC after a TEM client upgrade. In this environment NAC is configured to not allow a workstation access to the network unless the TEM client is installed and running. After upgrading to the latest version of TEM and pushing out the client upgrade, several Windows 7 users reported that they were failing a NAC check. After further investigation I found that the service startup for the "BESClient" (The service name is still BESClient as of version 8.2.1093.0 even though the product has been renamed from BigFix to Tivoli Endpoint Manager) service was set to "Automatic (Delayed Start)" instead of "Automatic." The service would eventually start and work fine but the NAC check was occurring before the machine got around to starting the BESClient service.
Delayed Automatic Start Info
Delayed Automatic Start is a feature that has been around for a while (since Vista) that allows non-critical services to load later in the boot process thereby allowing the computer to spend CPU cycles on critical services and improve the speed which the computer is available to be logged on. For more information on this feature, check out the following link from Microsoft's Performance Team blog - WS2008: Startup Processes and Delayed Automatic Start
In most environments there probably wouldn't be an issue with the TEM client service starting up a little later but in this case we need to make some changes so that users can go through NAC successfully.
Changing the Startup Type of the BESClient Service
The BESClient service is set to delayed start by the presence of a DWORD registry value named "DelayedAutoStart" with a decimal value of 1 in the key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BESClient" of the registry. To disable Delayed Automatic Start and just have the service start type as Automatic the value of "DelayedAutoStart" should be set to 0. You can test this out by opening up the services management console on a machine and changing the startup type between Automatic and Automatic (Delayed Start) and seeing the registry value change.
If you change the value through the registry, the services management console will not update the startup type until after a reboot (at least from my experience). The machine will use the new value on the next boot and since the value really doesn't come into play until boot time I didn't see the services console not updating as a big issue.
Deploying the Change Through a Fixlet
I created a fixlet to make the change across the environment as a whole and have posted the sample relevance and action scripts below. You can modify this for your environment or to improve the relevance as you wish.
Relevance
The relevance below will check for a machine running Windows Server 2008, Windows Server 2008 R2, or Windows 7 (If you have Vista in your environment then just add that in). Then it will check to see if the machine has the registry value named DelayedAutoStart with a value of 0. The relevance will evaluate to TRUE if the machine either does not have the value at all or it does not equal 0 (and the machine is one of the OS's listed).
(it = "Win2008" OR it = "Win2008R2" OR it = "Win7" ) of name of operating system AND (not exists key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BESClient" whose (value "DelayedAutoStart" of it = 0) of registry)
Action
The action script is very simple and just makes the change in the registry to set the DelayedAutoStart value to 0. It does not matter if the value exists or not, the action script will set it to 0. You could put in "action requires restart" at the end but there's no reason to have the machine reboot since the change won't be processed until the machine boots anyway.
regset "[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BESClient]" "DelayedAutoStart"=dword:00000000
Conclusion
You can use this information to build a fixlet to work with any service, not just the BESClient service. This also applies to any type of NAC, Network Admission Control or Network Access Control technology that checks for running processes/services before allowing access to the network. If you are using a different systems management application than TEM then the same methodology applies - you'll just have some different implementation steps.
When you deploy the action for the fixlet shown above I recommend that you make it a "policy" (no start or ending constraints, action reapplies when relevant again, no reboot, no messages) and target all hosts. That way when you perform the next TEM upgrade you won't have to go through all this again.
Further Resources
Link to the Fixlet Debugger that you can use to test out your relevance and action scripts before rolling them out. Also has other resources for writing fixlets.
Release notes from BigFix on version 8.1 that mention changing the default startup behavior of the client. There is also mention of a command line parameter for the initial installation of the client that can change the default behavior but it does not change the behavior on upgrades.
Microsoft's Performance Team blog
04/18/11
Security Patch Breaks Printing in Outlook 2007 - Recalled by Microsoft
Anybody who installed
User account not shown in Active Directory unless Advanced Mode enabled - Cisco Unity is the Culprit
I recently ran into a situation where certain users in Active Directory were just not showing up for some administrators while other admins could see them just fine. Upon further investigation it became evident that if the Advanced Mode of Active Directory Users and Computers was not enabled, the user accounts were hidden. Using the Attribute Editor tab of the user's account I took a look at the attribute "showinAdvancedViewOnly" and sure enough the setting was enabled.
Cisco Unity was installed in this environment and the users that were not showing up in AD also happened to have the setting "Show subscriber in email server address book" unchecked in Unity. Unity was not only making the change that was intended for removing the user from the address book but was also setting the attribute "showinAdvancedViewOnly" as well.
If you experience the same issue the workaround is simple. Edit the attribute "showinAdvancedViewOnly" on the user's account with either the built-in Attribute Editor tab of the user account page (if you have AD 2008) or use a tool like ADSIedit or LDP.exe to perform the change.
XML Feeds