locked
Authenication Fails when trying to login to client via Edge RRS feed

  • Question

  • Hello all,

    I'm having issues getting OCS working outside of our network.  OCS works fine internally but not when a user tries to connect from home.  We have an Edge and ISA server setup and all firewall ports that are needed are open. 

    When a client tries to connect externally they get to the point to enter their password.  At that point it will not let the password through.  I know the password is correct but it just doesn't work.  I traced the packets and the Egde and the client are "talking".  Our user does have remote access enabled.

    When I try to validate the Edge server I get the below error.

    Maximum hops: 2
    Failed to register user: User sip:testuser@testdomain @ Server internalpool.testdomain
    Failed to send SIP request: outgoing TLS negotiation failed; HRESULT=-2146893022
    Suggested Resolution: Make sure that the server is listening on the specified IP address/Port/Transport. If you have a firewall make sure that this port is open. Make sure that the server is running. If this is an Edge Server, ensure that remote user access has been enabled. This can be ignored if you have not enabled the transport on the target server.

    Tuesday, July 14, 2009 7:30 PM

All replies

  • So when you say the client and edge are talking can you explain more? usually if all of that is working and the client is hitting the edge correctly they it is a problem with the next hop from the edge server to your internal environment. Are you setup with Dual NIC's on the edge?

    Take a look at the event logs on the edge server you may see where it is having cert issues with the internal server or Name resolution problems. Be sure you can telnet from the edge to the next hop server i.e. director or pool. on port 5061.

    let us know if that helps.
    mitch
    Wednesday, July 15, 2009 12:47 PM
  • Mitch,

    Thanks for the reply!

    Sorry for not explaining myself a little better.  I'm new to using packet sniffers.  What I mean by "talking" is that the external client is sending and receiving packets from the edge server.  It starts out with TCP and then changes to TLSv2. 

    On the Edge server we have 2 NIC's.  One NIC is for the internal traffic and the other is external.  The external NIC has 3 public non-NAT IP Addresses.

    I'm able to successfully telnet 5061 from the Egde to the pool.  No issues there.

    On the edge server I see the below 2 warings in the event log.


    7/15/2009  2:11:50AM OCS Certificate Manager  1016  31007

    The CRL could not be downloaded for certificate:

    Subject: US, XX, XX, XX, XX, XX, Issuer: XX, XX, XX, XX, Extended Error Code: 0x80092013
    Cause: This could happen if the CA is unreachable or the certificate did not specify the CDP location. It could also happen if the CA was overloaded.
    Resolution:
    You should contact the issuer and download/install the CRL.



    7/14/2009  2:13:09AM OCS Certificate Manager  1016  31007

    Subject: US, XX, XX, XX, XX, XX, Issuer: XX, XX, XX, XX, Extended Error Code: 0x80092013
    Cause: This could happen if the CA is unreachable or the certificate did not specify the CDP location. It could also happen if the CA was overloaded.
    Resolution:
    You should contact the issuer and download/install the CRL.

    Could this be my problem? 

    Thanks,

    Keith
    Wednesday, July 15, 2009 1:31 PM
  • No that usually is not the cause of this type of problem. Do you have Gateways for both nics? if so remove the one for the internal nic and be sure you put a route in the route table so the edge can route to your internal IP's also check to make sure that the outside NIC is set to not register in DNS. Then check DNS to make sure it is not regestering in your internal DNS.

    Also check the logs on the ocs server.
    mitch
    Wednesday, July 15, 2009 1:46 PM
  • Mitch,

    Only the External NIC as a default gateway.  We make a static route to route the traffic to the internal network. I assume it works because we can ping the internal OCS server with no issues.  I checked the to make sure that the external NIC is not registering. 

    We do have the internal NIC set to register.  Should I remove that check mark?

    Thanks for your help!

    Keith
    Wednesday, July 15, 2009 1:53 PM
  • Reigstering the internal NIC is typically correct, depending on what DENS server you are using and what FQDN you've defined for DNS resolution for the Internal Edge.

    Is this a Standard Edition deployment or an Enterprise with an HLB?
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Wednesday, July 15, 2009 2:02 PM
    Moderator
  • No you should leave it. So based on the error it says it failed to make a TLS connection this is usually a Certificate issue in most cases. I have seen in some it is a connection issue but often it is a cert issue. Which could be the cert in 3 places basically. 

    First check you Edge cert for you public side. Does it have a subject name? if so does it match the FQDN that the client is looking for and or connecting to from the outside?

    Check the internal nic Certificate to be sure it has a subject name and is trusted by the internal pool front end server. Check the logs on the front end as well for errors. 

    I usually setup the edge server to pass the FQDN of the server so it is not just passing the host name. 

    you can do this by going into properties under my computer where you usually add it to the domain and select more then you can add the domain name as a primary DNS suffix even though it is not a memeber of the domain. This way it will pass the FQDN while trying to establish the tls connection with the pool frontend server.
    mitch
    Wednesday, July 15, 2009 2:03 PM
  • This is what I have in our test domain.

    Internal OCS Server / SQL Server 2005 -  Server 2008 X64
    External Edge - Server 2008 X64
    ISA Server - Server 2003 X32

    We did a consolidated FE server using Enterprise edition.  Internal OCS works fine at this point.  I just checked the FE server and there are no errors or warnings.  It almost seems like the edge is not passing traffic through to the FE pool.
    Wednesday, July 15, 2009 3:37 PM
  • Mitch,

    All the certificates subjects match up with the FQDN's.  I'm totally baffled on this one.

    Thanks for your help!

    Keith
    Wednesday, July 15, 2009 3:38 PM
  • Well I would walk it through the basics again. also pull a wireshark trace just to see the connections happening. At the same time start a debug session on the edge and the pool server. check the sip stack for tracing and see if it shows anything at all.


    Mitch Roberson, AOS |MCITP:Enterprise Server Admin, Messaging |MCTS:OCS with Voice Achievement |MCT
    Wednesday, July 15, 2009 11:58 PM
  • Mitch,

    Here is the error in the Debug


     
    SIP/2.0 401 unauthorized
     
    TL_INFO(TF_PROTOCOL) [0]0104.0A80::07/16/2009-13:38:58.335.0000b287 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
    Instance-Id: 0000009A
    Direction: incoming;source="internal edge";destination="external edge"
    Peer: pool.testdomain.com:5061
    Message-Type: response
    Start-Line: SIP/2.0 401 Unauthorized
    From: <sip:user@testdomain>;tag=f694a0bcaf;epid=5d710b86a4
    To: <sip:user@testdomain>;tag=9359F711C095E100AEBAD72262E6473C
    CSeq: 1 REGISTER
    Call-ID: 5829e692c7ab4aa3964b2c9e46913493
    Date: Thu, 16 Jul 2009 13:38:24 GMT
    WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="ocspool.testdomain", version=4
    Via: SIP/2.0/TLS 10.120.XX.XX:49190;branch=z9hG4bK23BCB809.821C84EAA0C32922;branched=FALSE;ms-received-port=49190;ms-received-cid=7D00
    Via: SIP/2.0/TLS 10.120.XX.XX:50016;ms-received-port=50016;ms-received-cid=1900
    Content-Length: 0
    Message-Body: –
    $$end_record


    This was in the event log on the internal FE server.

      7/16/2009 8:38:28 AM OCS Protocol Stack 1001 14498
      A significant number of authentication or authorization failures have occurred on messages for the account user@testdomain and the first attempt was from the IP address 10.120.XX.XX. 41 failures have been identified in the last 1305 minutes. There have been 41 errors in total. Note: the user uri might have been truncated to 64 characters.
    Resolution:
    It is recommended that this IP address be examined to determine if it should be blocked at the firewall to prevent password guessing attacks. This account may also be worth blocking with a script on the Access Edge Server to prevent continued attacks against it.


    • Edited by shadown7 Thursday, July 16, 2009 2:28 PM
    Thursday, July 16, 2009 2:08 PM
  • OK this looks like you are having an issue with the password and the way the user name is passed. is the client a member of the domain?


    Mitchr |MCITP:Enterprise Server Admin, Messaging |MCTS:OCS with Voice Achievement |MCT
    Thursday, July 16, 2009 5:32 PM
  • Mitch,

    The user is part of the domain and has remote access enabled.  If I login to the client internally using this same user there is no problem with the password and everything work correctly.

    Thanks for the help!

    Keith
    Thursday, July 16, 2009 7:04 PM
  • Check to make sure the authorized domains is correct in the edge server configuration, Also is the edge server behind a firewall? of so what type?
    Mitchr |MCITP:Enterprise Server Admin, Messaging |MCTS:OCS with Voice Achievement |MCT
    Thursday, July 16, 2009 9:30 PM
  • Also be aware that internal clients use Kerberos for authentication, while remote user clients use NTLM. From the trace log, it looks like the REGISTER request is reaching the home server but the credentials are being rejected.
    CW
    Thursday, July 16, 2009 10:53 PM
  • Thanks for all the help everyone. 

    I've tried all the above and nothing seemed to fix my issue.  I can successfully do anonymous Live Meetings via the Edge but the MOC will just not authenticate.

    We are behind two firewalls but we don't have any control over them.  We have to submit a rules request and another agency opens them up for us.  We have had them pull logs and we can't find any thing being denied by either of them.

    I'm kind of stumped on this one.

    Again, thanks for your help.
    Friday, July 31, 2009 12:57 PM