very weird address book replication issue - 2nd SIP domain added to setup

Bir soru sorun

25 Nisan 2012 Çarşamba 16:59

0

Short version: a select group of users acannot download the address book, give the generic 'check proxy server settings' error. I do not have any proxy configured, so that's not it. the issue follows the user, not the PC

Here is the setup: Exchange 2010 cluster, single Lync 2010 server (IM only) ALL USERS ARE INTERNAL - no edge servers or internet IM, just within our firewall.

for years had all email/Lync users in one AD domain and one SIP domain, for example:
   AD Domain:             corp.company.com
   SIP/email domain:   company.com    (ie: user@company.com)
all was well and right with the world.

New setup, added an additional AD domain (same tree, full trust) and a SIP/email domain
   AD Domain:               holding.company.com
   SIP/email domain:     holdinginc.com   (ie: user@holdinginc.com)

There are 3 types of users:
      1. user account on CORP, email/SIP is  user@COMPANY.COM - these get the address book ok
      2. user account on HOLDING, email/SIP is user@HOLDINGINC.COM - these get the address book ok
     3. user account on CORP, email/SIP is user@HOLDINGINC.COM - NO Lync address book

makes no sense. Users email is fine and all can use Lync - but the 3rd set of users have to enter the full sip name to start an IM session. Also the Lync client shows an 'error conecting to exchange' unless outlook is running.

What I've tried:

- Did the right click on the icon - config info deal, all users show same URL for the address book

- browsed that url, get the same 403:forbidden access denied error on all users

- tried manual config, no change (client is user@holdinginc.com as the sign in addy, and the server settings to internal server name = lyncserver.corp.company.com, external server name blank.)

- checked DNS entries. All three domains have the _sipinternaltls._tcp.whatever.com entry, and it is correct (lyncserver.corp.company.com, SRV record, 0 0 5061)

- re-published/configed my lync, both the server certificate with the setup tool (have my own domain CA everybody trusts, it picked up all the domains in the SAN cert) AND the topolgy, just in case. all seems to be ok.

- checked the client for GAL files, there are none to delete (on the users with issues). added the 'get it now' address book reg edit.

- checked the IIS logs on the Lync server. A working users gets multiple log entries when getting the address book, first the ip conencts and then you see the users SIP name in the logs. A non-working users gets one line, like this one:
2012-04-25 00:09:51 10.3.31.36 GET /abs/handler/F-1024.lsabs - 443 - 10.3.36.117 OC/4.0.7577.0+(Microsoft+Lync+2010) 401 0 0 0
that's it, no entries after that of a conversation happening. A working users gets the same entry AND an entry right after that about web ticket service

any help would REALLY be appreciated!
- Yanıt
- Alıntı

Tüm Yanıtlar

25 Nisan 2012 Çarşamba 19:28

0

Even weirder, using an affected user credential with Test-CsAddressBookService works on the server, still no address book on the client:

PS C:\> $cred1 = Get-Credential corp\user1
PS C:\> Test-CsAddressBookService -TargetFqdn lyncserver.corp.company.com -UserCredential $cred1

cmdlet Test-CsAddressBookService at command pipeline position 1
Supply values for the following parameters:
UserSipAddress: user1@holdinginc.com
        Connecting to web service : https://lyncserver.company.com
:443/WebTicket/WebTicketService.svc
        Using IWA authentication
        Successfully created connection proxy and website bindings
        Requesting new web ticket
        Sending Web-Ticket Request: <s:Envelope xmlns:s="http://schemas.xmlsoap.
org/soap/envelope/">
<s:Header>
    <Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/
addressing/none">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</Act
ion>
</s:Header>
<s:Body>
    <RequestSecurityToken xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/20051
2">
      <TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1
#SAMLV1.1</TokenType>
      <RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</RequestTyp
e>
      <AppliesTo xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy">
        <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
          <Address>https://lyncserver.company.com/WebTicket/WebTic
ketService.svc</Address>
        </EndpointReference>
      </AppliesTo>
      <Entropy>
        <BinarySecret>hZCSTF8HZHrug638SAdmGZEJ23R5vmHwKgM5hMJyleM=</BinarySecret
>
      </Entropy>
      <KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</Ke
yType>
    </RequestSecurityToken>
</s:Body>
</s:Envelope>
        Web-Ticket response: <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soa
p/envelope/">
<s:Header />
<s:Body>
    <RequestSecurityTokenResponseCollection xmlns="http://docs.oasis-open.org/ws
-sx/ws-trust/200512" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns
:xsd="http://www.w3.org/2001/XMLSchema">
      <RequestSecurityTokenResponse Context="00000000-0000-0000-0000-00000000000
0">
        <TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1
.1#SAMLV1.1</TokenType>
        <RequestedSecurityToken>
          <saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="SamlSec
urityToken-b59c3c2f-47cb-4d26-a74c-e294c8c08204" Issuer="https://EXCHLync1.corp.
ad.aaamidatlantic.com/webticket/webticketservice.svc" IssueInstant="2012-04-25T1
9:14:57.675Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
            <saml:Conditions NotBefore="2012-04-25T19:14:57.675Z" NotOnOrAfter="
2012-04-26T03:23:29.675Z">
              <saml:AudienceRestrictionCondition>
                <saml:Audience>https://lyncserver.company.com/</sa
ml:Audience>
              </saml:AudienceRestrictionCondition>
            </saml:Conditions>
            <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:
tc:SAML:1.0:am:unspecified" AuthenticationInstant="2012-04-25T19:14:57.675Z">
              <saml:Subject>
                <saml:NameIdentifier Format="http://schemas.xmlsoap.org/ws/2005/
05/identity/claims/uri">sip:user1@holdinginc.com</saml:NameIdentifier
>
                <saml:SubjectConfirmation>
                  <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder
-of-key</saml:ConfirmationMethod>
                  <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                    <e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">

                      <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/x
mlenc#kw-aes256">
                      </e:EncryptionMethod>
                      <KeyInfo>
                        <KeyName>lyncserver.company.com:8cef12cbf8
77800</KeyName>
                      </KeyInfo>
                      <e:CipherData>
                        <e:CipherValue>nzoCuGMBSG8JonIr9UfEKTpvzf206VvWMpS/FMMGj
TPtejZA0B3Wsg==</e:CipherValue>
                      </e:CipherData>
                    </e:EncryptedKey>
                  </KeyInfo>
                </saml:SubjectConfirmation>
              </saml:Subject>
            </saml:AuthenticationStatement>
            <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
              <SignedInfo>
                <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml
-exc-c14n#">
                </CanonicalizationMethod>
                <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rs
a-sha1">
                </SignatureMethod>
                <Reference URI="#SamlSecurityToken-b59c3c2f-47cb-4d26-a74c-e294c
8c08204">
                  <Transforms>
                    <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enve
loped-signature">
                    </Transform>
                    <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n
#">
                    </Transform>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha2
56">
                  </DigestMethod>
                  <DigestValue>187WvXYDOwQt7GIue6YuUtJYFhjnkPhW1+JYbZbJ5e0=</Dig
estValue>
                </Reference>
              </SignedInfo>
              <SignatureValue>Qe2in1ocR3kPGwAzHCDJFQdERiSyMqCUfarQbrq7CZwjc68ed7
jofV52cziSJ+2cc7DRQCtoeHU3VWEJdpMUk/LLWRj1k/e1MZ5NqPFdVPZEpD65fHFLLOjj/2zdHfbYPR
w8eu+qlhXtHf2TOj9vv4KLdN+cm+XLJ1VJaKEty2rdcKOFcOQcQwPmJzFlN8UEnbqu0h99fk84/WU503
77rTS5reb+AnitvaLUq3SnW3RDKQ2Pi6BPuuCzX6n9kLHOLQx5bPxTo3bECS3FbAcLUqDallwKIfc92t
qM8j7gSDNKOcw1H07XVagdx/vyEqdAzkt45VtVCB9ejkfU+9CebQ==</SignatureValue>
              <KeyInfo>
                <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/ws
s/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                  <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oas
is-wss-soap-message-security-1.1#ThumbprintSHA1">BmwDJCEIF+pbg+oh0SvyMa7x+JU=</o
:KeyIdentifier>
                </o:SecurityTokenReference>
              </KeyInfo>
            </Signature>
          </saml:Assertion>
        </RequestedSecurityToken>
        <AppliesTo xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy">
          <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
            <Address>https://lyncserver.company.com/</Address>
          </EndpointReference>
        </AppliesTo>
        <RequestedAttachedReference>
          <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004
/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss
-saml-token-profile-1.0#SAMLAssertionID">SamlSecurityToken-b59c3c2f-47cb-4d26-a7
4c-e294c8c08204</o:KeyIdentifier>
          </o:SecurityTokenReference>
        </RequestedAttachedReference>
        <RequestedUnattachedReference>
          <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004
/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss
-saml-token-profile-1.0#SAMLAssertionID">SamlSecurityToken-b59c3c2f-47cb-4d26-a7
4c-e294c8c08204</o:KeyIdentifier>
          </o:SecurityTokenReference>
        </RequestedUnattachedReference>
        <RequestedProofToken>
          <ComputedKey>http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1
</ComputedKey>
        </RequestedProofToken>
        <Entropy>
          <BinarySecret>6aDRQZnfyM6OOWnlUN6og5TvRAiuEi1sLoQ1bY0C/IA=</BinarySecr
et>
        </Entropy>
        <Lifetime>
          <Created xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-ws
s-wssecurity-utility-1.0.xsd">2012-04-25T19:14:57.6756849Z</Created>
          <Expires xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-ws
s-wssecurity-utility-1.0.xsd">2012-04-26T03:23:29.6756849Z</Expires>
        </Lifetime>
        <KeySize>256</KeySize>
        <SignWith>http://www.w3.org/2001/04/xmldsig-more#hmac-sha256</SignWith>
      </RequestSecurityTokenResponse>
    </RequestSecurityTokenResponseCollection>
</s:Body>
</s:Envelope>

TargetUri : https://lyncserver.company.com:443/abs/handler
TargetFqdn : lyncserver.company.com
Result     : Success
Latency    : 00:00:00
Error      :
Diagnosis :
- Yanıt
- Alıntı
25 Nisan 2012 Çarşamba 20:05

0
More info, also ran Test-CsAddressBookWebQuery as the same user and it seems to fail.

Would help if I knew what to do about that. Anyone?

Correction: this command passes, I failed to put in a target. Satrting to feel like some sort of permissions issue with IIS, any ideas?

cmdlet Test-CsAddressBookWebQuery at command pipeline position 1
Supply values for the following parameters:
UserSipAddress: juser1@holding.com
        Connecting to web service : https://lyncserver.corp.company.com
:443/WebTicket/WebTicketService.svc
        Using IWA authentication
        Successfully created connection proxy and website bindings
        Requesting new web ticket
        Sending Web-Ticket Request: <s:Envelope xmlns:s="http://schemas.xmlsoap.
org/soap/envelope/">
<s:Header>
    <Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/
addressing/none">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</Act
ion>
</s:Header>
<s:Body>
    <RequestSecurityToken xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/20051
2">
      <TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1
#SAMLV1.1</TokenType>
      <RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</RequestTyp
e>
      <AppliesTo xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy">
        <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
          <Address>https://lyncserver.corp.company.com/WebTicket/WebTic
ketService.svc</Address>
        </EndpointReference>
      </AppliesTo>
      <Entropy>
        <BinarySecret>Sr+0py7FMMcxX+tCitvt27wwlrd/tJbHBV8RDFOcmWM=</BinarySecret
>
      </Entropy>
      <KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</Ke
yType>
    </RequestSecurityToken>
</s:Body>
</s:Envelope>
        Web-Ticket response: <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soa
p/envelope/">
<s:Header />
<s:Body>
    <RequestSecurityTokenResponseCollection xmlns="http://docs.oasis-open.org/ws
-sx/ws-trust/200512" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns
:xsd="http://www.w3.org/2001/XMLSchema">
      <RequestSecurityTokenResponse Context="00000000-0000-0000-0000-00000000000
0">
        <TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1
.1#SAMLV1.1</TokenType>
        <RequestedSecurityToken>
          <saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="SamlSec
urityToken-bd70e29b-eabb-4dbd-a53c-a7c97a8a8e67" Issuer="https://EXCHLync1.corp.
ad.aaamidatlantic.com/webticket/webticketservice.svc" IssueInstant="2012-04-25T2
0:02:30.968Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
            <saml:Conditions NotBefore="2012-04-25T20:02:30.968Z" NotOnOrAfter="
2012-04-26T04:06:31.968Z">
              <saml:AudienceRestrictionCondition>
                <saml:Audience>https://lyncserver.corp.company.com/</sa
ml:Audience>
              </saml:AudienceRestrictionCondition>
            </saml:Conditions>
            <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:
tc:SAML:1.0:am:unspecified" AuthenticationInstant="2012-04-25T20:02:30.968Z">
              <saml:Subject>
                <saml:NameIdentifier Format="http://schemas.xmlsoap.org/ws/2005/
05/identity/claims/uri">sip:juser1@holding.com</saml:NameIdentifier
>
                <saml:SubjectConfirmation>
                  <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder
-of-key</saml:ConfirmationMethod>
                  <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                    <e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">

                      <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/x
mlenc#kw-aes256">
                      </e:EncryptionMethod>
                      <KeyInfo>
                        <KeyName>lyncserver.corp.company.com:8cef135214
be000</KeyName>
                      </KeyInfo>
                      <e:CipherData>
                        <e:CipherValue>wRSmQeTVqmsxIeio/eEJX9/WRtvlRyU+ZyFxW2rkA
tjRakr7BLbP+Q==</e:CipherValue>
                      </e:CipherData>
                    </e:EncryptedKey>
                  </KeyInfo>
                </saml:SubjectConfirmation>
              </saml:Subject>
            </saml:AuthenticationStatement>
            <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
              <SignedInfo>
                <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml
-exc-c14n#">
                </CanonicalizationMethod>
                <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rs
a-sha1">
                </SignatureMethod>
                <Reference URI="#SamlSecurityToken-bd70e29b-eabb-4dbd-a53c-a7c97
a8a8e67">
                  <Transforms>
                    <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enve
loped-signature">
                    </Transform>
                    <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n
#">
                    </Transform>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha2
56">
                  </DigestMethod>
                  <DigestValue>+dza0YhaflIDGHMT/y/2Pxc+tOhoeZtT1p6hWFONv/Q=</Dig
estValue>
                </Reference>
              </SignedInfo>
              <SignatureValue>l7mGR2Ly/1I8H0Dt+Agaer84OVSUmJcTbwAdMSrUFeUzXw/Wly
S1hDOx1ATYyWooK1YFXWZa1+k3cGTcnHgAHGO/OcUtdeMR6b3+tbgO6EKETaDNaS9ZrDeZo05b6H7Y7k
EMTma51WeKvzBBTwAcR+37ff8pf6JjQEKjgkaWQvw8XLv4UEnqKLnOjCjP5ftGFcOrIZoK8tiV2t/gzp
MSaIVrmBxNpTdanW8Gj9bpXnq4InU/VFhpuQJTqA0Nlq2e6TOvWWoe4BmofTP1oEE2TReZ2ketC6Q/CH
lSItvoVyRR7DEj9p/3+zItbnf28xnaSEsBScR7nbjzODblJiaN2g==</SignatureValue>
              <KeyInfo>
                <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/ws
s/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                  <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oas
is-wss-soap-message-security-1.1#ThumbprintSHA1">BmwDJCEIF+pbg+oh0SvyMa7x+JU=</o
:KeyIdentifier>
                </o:SecurityTokenReference>
              </KeyInfo>
            </Signature>
          </saml:Assertion>
        </RequestedSecurityToken>
        <AppliesTo xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy">
          <EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
            <Address>https://lyncserver.corp.company.com/</Address>
          </EndpointReference>
        </AppliesTo>
        <RequestedAttachedReference>
          <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004
/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss
-saml-token-profile-1.0#SAMLAssertionID">SamlSecurityToken-bd70e29b-eabb-4dbd-a5
3c-a7c97a8a8e67</o:KeyIdentifier>
          </o:SecurityTokenReference>
        </RequestedAttachedReference>
        <RequestedUnattachedReference>
          <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004
/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss
-saml-token-profile-1.0#SAMLAssertionID">SamlSecurityToken-bd70e29b-eabb-4dbd-a5
3c-a7c97a8a8e67</o:KeyIdentifier>
          </o:SecurityTokenReference>
        </RequestedUnattachedReference>
        <RequestedProofToken>
          <ComputedKey>http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1
</ComputedKey>
        </RequestedProofToken>
        <Entropy>
          <BinarySecret>N2onQ9XckrnsBm81iIb75WB6CBzA8pIrj+4kEcqDFM0=</BinarySecr
et>
        </Entropy>
        <Lifetime>
          <Created xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-ws
s-wssecurity-utility-1.0.xsd">2012-04-25T20:02:30.9689711Z</Created>
          <Expires xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-ws
s-wssecurity-utility-1.0.xsd">2012-04-26T04:06:31.9689711Z</Expires>
        </Lifetime>
        <KeySize>256</KeySize>
        <SignWith>http://www.w3.org/2001/04/xmldsig-more#hmac-sha256</SignWith>
      </RequestSecurityTokenResponse>
    </RequestSecurityTokenResponseCollection>
</s:Body>
</s:Envelope>
Creating WebTicket security token request

TargetUri : https://lyncserver.corp.company.com:443/groupexpansion/se
             rvice.svc
TargetFqdn : lyncserver.corp.company.com
Result     : Failure
Latency    : 00:00:00
Error      : Address Book Web service request has failed with response code NoE
             ntryFound.

Diagnosis :
- Düzenleyen Jbrady33 25 Nisan 2012 Çarşamba 20:15
- Düzenleyen Jbrady33 25 Nisan 2012 Çarşamba 20:28 updated info
- Düzenleyen Jbrady33 25 Nisan 2012 Çarşamba 20:33 correction
- Yanıt
- Alıntı
01 Mayıs 2012 Salı 10:39

0

This looks to be an issue with user Authentication as you get the following in IIS logs:

2012-04-25 00:09:51 10.3.31.36 GET /abs/handler/F-1024.lsabs - 443 - 10.3.36.117 OC/4.0.7577.0+(Microsoft+Lync+2010) 401 0 0 0

and then nothing, the error code that IIS returned is "401" which basically means "Unauthorized", the message should contain a WWW-Authenticate indicating the type of authentications offered by the server. In a typical deployment you will see that you get three response headers back: NTLM-SSP, Kerberos and TLS-DSK

The subsequent WebTicket requests in the working logs indicate that the working client are using TLS-DSK to provide authentication information. Given the complexity of the scenario that you are in, forum may not be the best way to troubleshoot this issue, however, you can try the following to see if it helps/makes a difference:

1. On the client machine, check user's personal certificate store and delete/export any certificate issued by "Communications Server" and test again.
2. On the client machine, uncheck "Integrated windows authentication" and test again.
3. On the Front-End server, run Get/Set-csWebServiceConfiguration and try changing UseWindowsAuth and/or UseCertificatAuth values.

The above options basically toggle between using NTLM/Kerberos and WebTicket (TLS) authentication schemes. To actually find out where the authentication is failing you would have to look at your client's network traces, http traces (fiddler or STRACE) and client logs to figure out which authentication scheme is being used and where/why it fails.

Hope this helps.
- Yanıt
- Alıntı
02 Mayıs 2012 Çarşamba 17:44

0
Thanks for the reply.

I grabbed a copy of fiddler, all I have found so far is that I get
"502 HTTP Tunnel to holdinginc.com:443"
from fiddler. No HHTPS requests (but fiddler is working, if I go to an HTTPS site it shows everything)

What is it looking for with just the domain name like that? (no host) The _internalsip tcp dns entry?

WIll keep looking, any other advice is welcomed

PS: All clients are doing "autoconfigure" - the server name is correct and TLS is chosen. (even on manual I can't choose TCP, greyed out)
- Düzenleyen Jbrady33 02 Mayıs 2012 Çarşamba 17:45
- Düzenleyen Jbrady33 02 Mayıs 2012 Çarşamba 17:47
- Yanıt
- Alıntı
02 Mayıs 2012 Çarşamba 17:49

0

auth config:

Identity                             : Global
TrustedCACerts                       : {}
MaxGroupSizeToExpand                 : 100
EnableGroupExpansion                 : True
UseWindowsAuth                       : Negotiate
UseCertificateAuth                   : True
UsePinAuth                           : True
AllowAnonymousAccessToLWAConference : True
EnableCertChainDownload              : True
InferCertChainFromSSL                : True
CASigningKeyLength                   : 2048
MaxCSRKeySize                        : 16384
MinCSRKeySize                        : 1024
MaxValidityPeriodHours               : 8760
MinValidityPeriodHours               : 8
DefaultValidityPeriodHours           : 4320
MACResolverUrl                       :
SecondaryLocationSourceUrl           :
ShowJoinUsingLegacyClientLink        : False
ShowDownloadCommunicatorAttendeeLink : False
- Yanıt
- Alıntı
02 Mayıs 2012 Çarşamba 18:01

0

If I try to manually browse to abs/int/ or /abs/handler from ANY client, I get 403 - Forbidden Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
- Yanıt
- Alıntı
08 Mayıs 2012 Salı 04:15

0

Getting a 403 on the /abs/int or /abs/handler is expected. However, you should be able to download the file if you provide the complete path for eg: https://lyncserver.company.com:443/abs/handler/F-1031.lsabs should prompt you to download a file.

If you are running Enterprise Edition Lync server pool and have a hardware Load balancer, try bypassing it using local host files entry and see if the problem persists. Again, as per the IIS logs that you shared earlier it appeard to be authentication issue, however, more detailed log analysis might be required.
- Yanıt
- Alıntı
08 Mayıs 2012 Salı 10:47

0

Thank you, the latest:

Not definite, but it appears that some users cannot verify that the lynx cert (from my ent CA, a windows 2003 cert server and domain controller in my root domain) has not been revoked - possibly not being able to download the CRL. The cert does have a valid HTTP and LDAP paths for crl, but an internet article suggested it had to be an HTTPS link. Anyone familiar with this?
- Yanıt
- Alıntı
11 Mayıs 2012 Cuma 04:07

0

Just an idea, try disabling CRL check in IE properties and see if that helps.
- Yanıt
- Alıntı
11 Mayıs 2012 Cuma 15:29

0

Yep, been trying that, gets weirder. So far even MS support has not been able to help (have a case open)

With that unchecked, with all domains involved added in "trusted sites" (*.domain.com), all that pushed by group policy, here is where I am:

All machines can pull the cert revocation list and generally work with my internal CA (AD based running on 2003). My test accounts are regular users, user A is a member of corp.company.com iwth sip of company.com. User B is a member of corp.company.com with sip of holdinginc.com.

User 'A' works everywhere, all machine. User 'B' works on about half the machines. I'm stumped!
- Yanıt
- Alıntı
12 Mayıs 2012 Cumartesi 06:52

0
Can you e-mail the case number to me, I'll see if I can work with the engineer involved on this to find a solution.

ak ni ga m (a) microsoft.com
- Düzenleyen Akshat NMicrosoft Employee 12 Mayıs 2012 Cumartesi 06:53
- Yanıt
- Alıntı
14 Mayıs 2012 Pazartesi 13:09

0

Thanks! Email sent
- Yanıt
- Alıntı

very weird address book replication issue - 2nd SIP domain added to setup

Tüm Yanıtlar

Ürünler

Kaynaklar

Çözümler

Güncellemeler

Deneme sürümleri

İlgili Siteler

Eğitim

Sertifikalar

Diğer kaynaklar

Ürüne göre destek

Diğ. destk bğlantı