I was working on a case, where Oracle MA was required to be created to sync Oracle DB's identity data with FIM, so that it can be synced with other identity stores. Following link provides most of the information needed http://social.technet.microsoft.com/wiki/contents/articles/18548.fim-2010-r2-how-to-make-a-connection-to-oracle-database-11g.aspx to connect to Oracle DB store. But there were few things, which I wanted to make sure everybody knows and its easy for them to configure this easily .
In my scenario admin was getting following error, when they had configured settings as shown below.
Data Source : SID (provided by oracle DBA)
Table/view : Name of table view(provided by DBA)
for Authentication
Database auth, with credentials of the user to make connection ( Provided by DBA)
so with Above information , they were getting " Failed to retrieve schema"
To make sure we are able to connect to Oracle server, I took netmon while trying to connect and connection was fine but still we were not able to get the schema. Oracle DBA tested with the command prompt with sqlplus and test work fine.
We then configured it as below to get it to work.
Datasource : SERVERIP:PORTNO(of the oracle server)/(SID)-provided by oracle DBA, rest is straight forward and same as they were using before.
There is a third party link that explains this connection string http://stackoverflow.com/questions/2134617/what-is-a-tnslistener-in-the-context-of-oracle, I found it useful so thought of sharing it as well.
Once we got this working rest of MA configuration is as usual.
It appeared strange issue, when I worked on a case where out of all the users for only few Iphone users ActiveSync was not working, For other users including Iphone, windows phone and Andriod phones it was working. In this scenario client certificate authentication was implemented.
Live Logs on TMG are so Awesome that they can at times point directly to where could be the problem. In this scenario, I took live logs for users who had apple keyword in the client agent string and found following
******************************************************************************************************
Apple-iPhonexxxxx No Reverse Proxy x.contoso.com TCP OPTIONS Req ID: xxx xxx xxx 443 https Failed Connection Attempt 0x80092010 anonymous http://xx.contoso.com/Microsoft-Server-ActiveSync SAMPLESERVERTMG
highlighted result code 0x80092010
A look up of this status code in Err gives following result :
----------------------------------------------
C:\Err>err 0x80092010# for hex 0x80092010 / decimal -2146885616 : CRYPT_E_REVOKED winerror.h# The certificate is revoked.# 1 matches found for "0x80092010"
and it talks about the revoked certificate.For working Iphone users we did not have this status code in the logs.
I also took TMG data packager logs with web proxy and publishing template , more on that (http://blogs.technet.com/b/sooraj-sec/archive/2010/04/10/instructions-for-isa-data-packager-to-collect-data-in-repro-mode.aspx)
Then in the ISA Tracing logs for the problem traffic found following (more on analyzing TMG data packager logs http://blogs.technet.com/b/sooraj-sec/archive/2012/11/07/data-analysis-using-with-tmg-data-packager.aspx)
****************************************************
Info:Starting user authentication"
Info:[0x000000004A379980] Verifying SSL client certificate"
Info:URL retrieval timeout =60000"
Info:Getting certificate chain..."
Info:Certificate chain obtained"
Info:Entered: else if dwChainStatus & CERT_TRUST_REVOCATION_STATUS_UNKNOWN (usually cannot get the CRL file)"
Info:Element index# 0 in chain (total of 3 elements) dwRevocationResult != NO_ERROR (0x80092013)"
Warning:[0x000000004A379980] VerifyRemoteCertificate failed, Failure = 3, hr = 0x80092010(CRYPT_E_REVOKED)"
Info:WPPISAPUBLIC:Returning error text ""The certificate is revoked. "" for error code -2146885616(CRYPT_E_REVOKED)"
ERROR:ValidateClientCertificate() failed, dwError= -2146885616(CRYPT_E_REVOKED)"
ERROR:ValidateClientCertificateAndTimestamp failed, err = -2146885616(CRYPT_E_REVOKED)"
Noise:WPPISAPUBLIC:(x.x.x.x:xxx <== x.x.x.x:xxx), 2153 bytes, ""HTTP/1.1 500"""
***********************************************************************
From here we can see when certificate authentication is starting it checks Certificate Revocation status and here its not able to do that as it could not get the CRL file and "VerifyRemoteCertificate" operation fails and hence certificate is considered revoked keeping the law of least privilege or access. Hence user is not able to authenticate.
To get immediate relief to such users, I suggested a temporary diabling of CRL revocation check on TMG for client certificate(shown below). After disabling that, problem Iphone users started working fine.
We found following events on the CA server( in this scenario Internal root CA was used to issue the certificates.)
************************************************************************
Event Type: Error
Event Source: CertSvc
Event Category: None
Event ID: 66
Date: xx
Time: xx
User: N/A
Computer:xx
Description:
Certificate Services could not publish a Delta CRL for key x to the following location: xxxx\CertSrv\CertEnroll\xxx+.crl. xxx
which is a delta CRL and it was not available, After correcting the Delta CRL problem which was not available.( Which explains the problem we were seeing, so it was planned to correct this, either make it available(publish) or not use it any more and use the usual CRL URL and once that's available ) Certificate Revocation check is enabled on TMG for enhanced security.
Sometime back I worked on a case where UAG DA clients were not able to connect using IPHTTPS intermittently . In such scenarios, we can get initial diagnostic information from DCA(direct access connectivity assistant) logs. So I collected this log at the time of issue and found following for the IPHTTPS interface. more on DCA (http://technet.microsoft.com/en-us/library/gg274289.aspx)
netsh int httpstunnel show interfaces
Interface IPHTTPSInterface (Group Policy) Parameters
------------------------------------------------------------
Role: client
URL : https://da.contoso.com:443/IPHTTPS
Last Error Code :0x80092013
Interface Status : failed to connect to the IPHTTPS server. Waiting to reconnect
If we do err lookup we could see
C:\Err>err 0x80092013# for hex 0x80092013 / decimal -2146885613 : CRYPT_E_REVOCATION_OFFLINE winerror.h# The revocation function was unable to check revocation# because the revocation server was offline.# 1 matches found for "0x80092013"
It was clear that client was not able to connect to the CRL. So from the client machine's browser I tried to open this URL https://da.contoso.com:443/IPHTTPS and collected network monitor trace while doing that and found.
1. That admin was using internal Certification Authority to issue the IPHTTPS SSL server authentication.
2. The CRL checking for this certification was failing as seen below. Double click the picture to zoom it.
We could see that for URL http://crl.contoso.com/certenroll/samplenameofserver+.crl we were getting URL denied. I found that Admin had published his CRL through ISA server 2006 and this URL path was missing. I engaged our directory services team and they explained that this is incremental CRL update location http://crl.da.com/certenroll/samplenameofserver+.crl .
Then suggested customer to publish this as well along with the usual CRL he has published on his ISA server. Once he did that , we did not see issue occurring again.
Conclusion
Given above scenario , its recommended that we should use a public Certificate Issuing authority to issue certificate for IPHTTPS website, so that CRL check can be done easily for this certificate from any external or internet location. But in case if internal CA is used then we should make sure that CRL is available for anonymous access, i.e. we should publish it the way we did through reverse proxy servers like ISA/TMG servers.We know that CRL check is required for IPHTTPS. If CRL is not available then connection will always fail. In this scenario we had intermittent failures because the client has cached CRL information from AD synchronization. Once this cache expires IPHTTPS fails due to this incremental path not being published and hence not available to external users for CRL download and checking purpose.
http://technet.microsoft.com/en-us/security/jj720323.aspx
sharing the link with all my friends. As some of them asked for it.