locked
S4B 2016 not signing in seamlessly via ADFS RRS feed

  • Question

  • Well, it used to work fine. For about a year. But now users are being asked for a password when Skype for Business 2016 starts and tries to log them in.

    This is not where it asks for a username and a password, it has the sign in address at the top (which is the UPN from Active Directory), but has a password text box underneath, including a "Save my password" tick box.

    If the AD password is entered, the sign in works.

    I've tested my internal and external STS/ADFS and it seems to be fine.

    IE will sign me straight in to https://sts.myco.com/adfs/ls/idpinitiatedsignon without needing a password. Likewise I can get through to portal.office.com without needing to type a password. So if those still work, why not Skype for Business?

    Any suggestions?

    Tuesday, August 22, 2017 9:42 AM

All replies

  • Is this the pop-up password after Skype is logged in?  If so, it's requesting credentials to talk to Exchange in the background and you've got an Exchange\EWS authentication issue, not a Skype one.  If Skype isn't logged in, make sure the Save my password box is checked the first time for certain.

    Please remember, if you see a post that helped you please click "Vote" on the left side of the response, and if it answered your question please click "Mark As Answer". SWC Unified Communications This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, SWC, their employees, or other MVPs.

    Tuesday, August 22, 2017 3:28 PM
  • Thanks for the reply.

    No, it's not a separate pop-up credentials prompt. See image:

    Note that this used to work fine, no password needed. And as per my original post, that still functions fine in IE for the "raw" idpinitiatedsignon page, and for the Office 365 website. It is only Skype for Business that is no longer seamlessly logging users on.

    Yes, I can enter my password and tick the "save my password" box, but I (and other users) didn't used to have to. The whole point of using ADFS was that the sign on process would be seamless. And it has been, until a few days ago.

    I'm considering trying Wireshark or something to see what's going on under the hood. Are there any logs that might be worth looking at though?

    Wednesday, August 23, 2017 9:02 AM
  • Hi robincm,

     

    1.Please check the user’s SIP proxy address in attributes editor.

    2.Please check if there is an OC credential in Windows Credential Manager.

    3.If there is an OC credential, I suggest you analyze the client .UccApiLog file for detailed logon process via Snooper, so that we can figure out which step it got stuck in.

    .UccApiLog file path: C:\Users\username***\AppData\Local\Microsoft\Office\15.0\Lync\Tracing

    For the usage of Snooper, please refer to the documents from following website.

    https://gallery.technet.microsoft.com/lync/Step-By-Step-Guide-Lync-4aaedb2b


    Best Regards,

    Leon-Lu
    TechNet Community Support


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, August 23, 2017 9:48 AM

  • Are there any update for this issue, if the reply is helpful to you, please try to mark it as an answer, it will help others who has similar issue.

    Best Regards,

    Leon-Lu
    TechNet Community Support


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, September 6, 2017 9:42 AM
  • Sorry for the delay.

    There is a sip address in Azure AD, yes. I can see various sip-related things using the Get-CsOnlineUser cmdlet. e.g. there's a sip: address in ShadowProxyAddresses, ProxyAddresses, SipAddress. The RegistrarPool attribute also has sippoolxxxxxxx.infra.lync.com, HostingProvider is sipfed.online.lync.com.

    I've no sip stuff in my on-prem AD, but we're not running S4B server in house, only via Office 365.

    I can't see a Microsoft_OC1 credential in credential manager. Would/should this be there for ADFS authentication though?


    Wednesday, September 6, 2017 12:32 PM
  • In the log file you suggest, on the Messages tab, I can see three events within a few milliseconds of each other with the StartLine of: SIP/2.0 401 Unauthorized

    I'm not sure how sensitive the contents of these messages is but here's the first one, with some redaction of potentially sensitive data:

    09/06/2017|09:22:08.730 21A4:1C90 INFO  :: Data Received -52.112.194.22:443 (To Local Address: 127.0.0.1:50250) 712 bytes:
    09/06/2017|09:22:08.730 21A4:1C90 INFO  :: 
    SIP/2.0 401 Unauthorized
    ms-user-logon-data: RemoteUser
    Date: Wed, 06 Sep 2017 08:22:08 GMT
    WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="xxxxxxxxxxxx.infra.lync.com", version=4, sts-uri="https://webpoolxxxxxxx.infra.lync.com:443/CertProv/CertProvisioningService.svc"
    From: <sip:me@myco.com>;tag=xxxxxxxxxx;epid=xxxxxxxxxx
    To: <sip:me@myco.com>;tag=xxxxxxxxxxxxxxxxxxxxxxxxxxx
    Call-ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    CSeq: 1 REGISTER
    Via: SIP/2.0/TLS 127.0.0.1:50250;received=13.100.5.254;ms-received-port=26907;ms-received-cid=xxxxxxxx
    ms-telemetry-id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    Server: RTC/7.0
    Content-Length: 0

    09/06/2017|09:22:08.730 21A4:1C90 INFO  :: End of Data Received -52.112.194.22:443 (To Local Address: 127.0.0.1:50250) 712 bytes

    The next message contains a large chunk of what could be Base64 data following gssapi-data=

    The third message looks similar to the first, with a few differences, e.g. CSeq: 3 REGISTER

    Thanks.


    • Edited by robincm2 Friday, September 8, 2017 8:44 AM remove personal info
    Wednesday, September 6, 2017 1:22 PM
  • I used the Office 365 Single Sign-on test from the Remote Connectivity Analyser, that initially came back with an error of:

    The Integrated Windows authentication endpoint is missing on the internal metadata document.

    Which I've resolved by using Update-MsolFederatedDomain.

    However I'm still getting the original problem signing in to Skype for Business.

    Friday, September 8, 2017 10:31 AM
  • Found this in the log via Snooper:

    09/08/2017|12:34:52.208 FB8:3110 TRACE :: 
    SIP_AUTH::ProcessAuthRequired result:nego fail

    Might be relevant?

    Friday, September 8, 2017 11:51 AM
  • I've turned on the CAPI2 operational event log.

    There's a few errors which seem a bit odd, e.g.:

    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-CAPI2" Guid="{5bbca4a8-b209-48dc-a8c7-b23d3e5216fb}" />
        <EventID>30</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>30</Task>
        <Opcode>0</Opcode>
        <Keywords>0x4000000000000001</Keywords>
        <TimeCreated SystemTime="2017-09-08T12:01:07.502011400Z" />
        <EventRecordID>2331</EventRecordID>
        <Correlation ActivityID="{0EF95600-287A-0002-0356-F90E7A28D301}" />
        <Execution ProcessID="552" ThreadID="6080" />
        <Channel>Microsoft-Windows-CAPI2/Operational</Channel>
        <Computer>xxxxx.yyyyy.local</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <UserData>
        <CertVerifyCertificateChainPolicy>
          <Policy type="CERT_CHAIN_POLICY_MICROSOFT_ROOT" constant="7" />
          <Certificate fileRef="6A8AD30E55D8B492CF48688D89DBBD6705A5F39D.cer" subjectName="*.online.lync.com" />
          <CertificateChain chainRef="{E1F7FC74-839B-4522-A12C-CB102FF46DC0}" />
          <Flags value="0" />
          <Status chainIndex="0" elementIndex="2" />
          <EventAuxInfo ProcessName="lsass.exe" />
          <CorrelationAuxInfo TaskId="{31E3C8E9-C4DC-40F1-B4A4-A1E621AAAE12}" SeqNumber="1" />
          <Result value="800B0109">A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.</Result>
        </CertVerifyCertificateChainPolicy>
      </UserData>
    </Event>

    and

    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-CAPI2" Guid="{5bbca4a8-b209-48dc-a8c7-b23d3e5216fb}" />
        <EventID>30</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>30</Task>
        <Opcode>0</Opcode>
        <Keywords>0x4000000000000001</Keywords>
        <TimeCreated SystemTime="2017-09-08T12:01:07.502054900Z" />
        <EventRecordID>2332</EventRecordID>
        <Correlation ActivityID="{0EF95600-287A-0002-0356-F90E7A28D301}" />
        <Execution ProcessID="552" ThreadID="6080" />
        <Channel>Microsoft-Windows-CAPI2/Operational</Channel>
        <Computer>xxxxx.yyyyy.local</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <UserData>
        <CertVerifyCertificateChainPolicy>
          <Policy type="CERT_CHAIN_POLICY_MICROSOFT_ROOT" constant="7" />
          <Certificate fileRef="6A8AD30E55D8B492CF48688D89DBBD6705A5F39D.cer" subjectName="*.online.lync.com" />
          <CertificateChain chainRef="{E1F7FC74-839B-4522-A12C-CB102FF46DC0}" />
          <Flags value="20000" MICROSOFT_ROOT_CERT_CHAIN_POLICY_CHECK_APPLICATION_ROOT_FLAG="true" />
          <Status chainIndex="0" elementIndex="2" />
          <EventAuxInfo ProcessName="lsass.exe" />
          <CorrelationAuxInfo TaskId="{5A758C39-7742-4788-823C-8E8A887C534B}" SeqNumber="1" />
          <Result value="800B0109">A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.</Result>
        </CertVerifyCertificateChainPolicy>
      </UserData>
    </Event>

    These events also exist for subjectName of: *.pipe.skype.com, stamp2.login.microsoftonline.com, *.myco.com, ols.officeapps.live.com, 

    Plus similar events where the CertChainCertificateChainPolicy - Policy - Type = CERT_CHAIN_POLICY_SSL

    • Edited by robincm2 Friday, September 8, 2017 12:54 PM correction
    Friday, September 8, 2017 11:59 AM
  • Is it affecting a certain user or some users or all users? Did you or someone in your company recently enabled MFA in Office365?
    Friday, September 8, 2017 12:42 PM
  • Can you tell us the registry settings of Computer\HKEY_Current_User\Software\Microsoft\Office\16.0\Common\Identity

    EnableADAL Parameter is there or not & value


    Whenever you see a helpful reply, click on Vote As Helpful & click on Mark As Answer if a post answers your question.

    Friday, September 8, 2017 2:41 PM
  • As far as I can tell, it's all users. without being able to track it centrally it's not easy to see who's just been doing what Skype4B says and putting in their password, vs people who are still being signed in seamlessly like they always used to be.

    We do not have MFA enabled for Office 365.

    Wednesday, September 13, 2017 10:22 AM
  • I've no EnableADAL value in that reg key.

    I do have a ConnectedADALIdentity value, which contains my UPN of me@myco.com and an ADUserName value which is set to me@myad.local

    Thanks

    Wednesday, September 13, 2017 10:55 AM