Last week I passed the EC-Council CHFI exam (312-49). This is my second certification with EC-Council after taking the CEH exam. From my point of view The CEH exam was harder than the CHFI as it covers broad range of technical areas. The CHFI lays a good foundation for the Forensics domain, however if you are taking the Forensics as a job then I would recommend going to CHFI plus GIAC Forensics Certification or Guidance Software (EnCase).
Thursday, 22 December 2011
Monday, 19 December 2011
This problem was reported on a standard DirectAccess implementation scenario where all clients aren’t able to connect using Teredo and they all fall back to IPHTTPS which is the last resort for any DirectAccess connection.
Windows error 13887(ERROR_IPSEC_IKE_CERT_CHAIN_POLICY_MISMATCH)
After applying the Fix and removing the AV from the UAG server the clients were able to connect normally using Teredo.
Symptoms:
1. When checking the Teredo Interface state, the following was displayed.
Netsh int teredo show state
Client Type : teredo host-specific relay
The Client type should have been Teredo Client for a successful Teredo connection.
2. I disabled the IPHTTPS interface to ensure it won’t fall back to the IPHTTPS option, opened wf.msc (windows Firewall with advanced security mmc) and navigate to monitoring – Security associations – Main Mode and Quick Mode. Both displayed nothing as shown in the figure below. This indicated IPSEC connection failure
3. After capturing both server and client logs and with the help of a Microsoft senior engineer we noticed the following error
Resolution:
1. A recent KB was released from Microsoft to address this specific Certificate problem with a recommended fix. This fix needs to be applied on both the DirectAccess Server and Client.
2. It turned out that the DirectAccess server has an Antivirus solution which seems to load several modules like NAC and others although it was configured to run normal AV file protection.
Tuesday, 22 November 2011
Lately I passed by this issue with a client trying to implement the UAG Direct Access using UCC SAN (Subject Alternative Name) Certificate. The Problem was that the Direct Access IPHTTPS URL name “da.company.com” was not the common name of the Certificate (The common name was www.company.com). Microsoft recommends either Wildcard certificate or normal HTTPS certificate for the DA name. If you don't have other option but the SAN certificate then Its recommended to have the Common name matching the Direct Access IPHTTPS URL otherwise a manual work around should be done on both the UAG server and the UAG client.
UAG Server
The Direct Access URL should be adjusted manually on the UAG server using the Netsh command as follows:
Netsh Interface HTTPStunnel Set Interface https://da.company.com:443/IPHTTPS
Then run
Netsh Interface HTTPStunnel show interface
UAG Client
The UAG clients/OU (according to your setup) GPO need to be modifed manually to add the Direct Access URL.
Computer Configuration/Policies/Administrative Templates/Network/TCPIP Settings/IPv6 Transition Technologies/IP-HTTPS State
Make sure to update the GPO on the client (GPupdate /force) and activate the UAG configuration.
Thursday, 10 November 2011
Error Reported in Event Viewer or DNS Best Practices Analyzer.
"The Active Directory integrated DNS zone _msdcs.domain.com was not found"
DNS support for AD guide
http://technet.microsoft.com/en-us/library/cc759550(WS.10).aspx
"The Active Directory integrated DNS zone _msdcs.domain.com was not found"
This error might appear in environments and domains that were already built back in the days of windows 2000 or Windows 2003. By default, before windows server 2003 SP1, there was no independent _msdcs.domain.com zone in the DNS console. When the domain was originally created under Windows 2000 or Windows 2003, there was only a _msdcs folder under the domain.com zone which could also provide the resolution for _msdcs.domain.com zone. After windows server 2003 SP1, when you create a zone such as domain1.com, there is an independent _msdcs.domain1.com zone which is the delegation of the original _msdcs folder. This _msdcs will highly benefit the DNS replication.
What is the _msdcs Zone?
According to Microsoft documentation/definition:
“Microsoft-specific subdomain enables location of domain controllers that have specific roles in the Active Directory domain or forest. Resource records for the DNS root domain of a new Active Directory forest are stored in a _msdcs zone instead of a subdomain, and that zone is stored in the forest-wide application directory partition.”
This Zone will host only DNS SRV records that are registered by Microsoft-based services as well as the globally unique identifier (GUID) for all domains in the forest and a list of GC servers in your forest/domain.DNS support for AD guide
http://technet.microsoft.com/en-us/library/cc759550(WS.10).aspx
The Steps needed to resolve these issues are as follows:
1. Manually created _msdcs.domain.com zone
· Open DNS console, right-click “Forward Lookup Zones”, click “New Zone”, manually create new zone _msdcs.Domain.com, please select primary zone and check “Store the zone in Active Directory” on the page of Zone Type.
2. After that, please check if _ msdcs.Domain.com has been created and the records are correct. If not continue with the next step.
3. Create a delegated _msdcs zone under the domain.com and delegate it to the _msdcs.domain.com zone. Right-click “Domain.com”, click “New Delegation”, please type _msdcs in the Delegated domain text box
4. Click Add button to type DNS server’s IP address.
5. Stop and restart NETLOGON and DNS Service.
Friday, 4 November 2011
Event ID: 1058
Source: Group Policy
"The Processing of Group Policy failed. Windows attempted to read the file \\domain\sysvol\domain\policies\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\gpt.ini from a domain controller and was not successful."
I passed by this error lately with several environments running Windows 2008 or 2008R2 Domain controllers. The key element in resolving this issue is to determine which group policy is causing this problem.
Source: Group Policy
"The Processing of Group Policy failed. Windows attempted to read the file \\domain\sysvol\domain\policies\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\gpt.ini from a domain controller and was not successful."
I passed by this error lately with several environments running Windows 2008 or 2008R2 Domain controllers. The key element in resolving this issue is to determine which group policy is causing this problem.
When you install GPMC you get a sample folder full of very useful scripts that make use of GPMC COM interfaces, The Script we are looking for is the DumpGPOInfo.wsf. For some reason Windows 2008 doesn’t include this folder and you will have to download it manually from the following link
After downloading and installing the Sample scripts, use the above mentioned file to get the name of the GPO generating the above error.
Cscript DumpGPOInfo.wsf {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
This will give you the friendly name of the GPO.
You may delete, rename……….etc the GPO from the Group Policy Management Console. In my case I just enabled/disabled one setting and it worked fine and I was able to recreate the GPT.ini file back.
Subscribe to:
Posts (Atom)
