Skype For Business Online - Frequently Asked Scenarios - Sign-In and authentication troubleshooting

Technical Level : Intermediate

Summary

How to troubleshoot Skype for Business Online scenarios for Sign-In and Authentication issues

For reference please follow our TechNet article and our wizards for Users and Admins


Details

Sometimes we have users reporting that they cannot sign-in to Skype for Business client or Office 365.

Scope

First thing to do is understand the all scenario:

  • How many users are affected or reporting the issue?
  • Is there any error/alert/message being displayed?
  • Is the issue consistently reproducible? or is it occurring intermittently? or random disconnects?
  • When did the issue started (date & time)?
    • Did this ever worked?
    • Any changes were made from your end?
  • Affected client type (if applicable)?
  • Client version(s)?
  • Account type [Managed/Federated/Hybrid]?
  • Network location (Internal or external)?
  • Are user(s) license(s) valid and correctly assigned?

Scenarios


Office 365 Managed Account

This type of account is commonly called a "cloud identity".

Is directly created within the Office 365 Admin Portal or synchronized using Azure AD Connect (or other similar service)
Authentication process involves connecting directly to the Office 365 Skype for Business service.
DNS issues are common in this scenario, especially if the tenant is newly deployed.

Troubleshooting

  1. While troubleshooting sign in issues, use the Delete My Sign In Information option every time sign in is tested to ensure cache and creds are cleared

  2. Verify DNS
    • Launch Microsoft Remote Connectivity Analyzer and run Office 365 Lync Domain Name Server (DNS) Connectivity Test
    • Enter any SIP address from the affected domain (*** Email address is removed for privacy ***)
    • Verify all four DNS entries are correct (green checks)
    • SRV record _sip._tls.contoso.com resolves to: sipdir.online.lync.com:443
      SRV record _sipfederationtls._tcp.contoso.com resolves to: sipfed.online.lync.com:5061
      CNAME record sip.contoso.com returned: sipdir.online.lync.com
      CNAME record lyncdiscover.contoso.com returned: webdir.online.lync.com
    • DNS failure messages are relevant and likely the root cause.
      See the following KBs to correct DNS configurations. 
      Check Set up Skype for Business Online and Troubleshooting Skype for Business Online DNS configuration issues in Office 365 for more information

  3. Determine Impact Location - It's a common key to quick resolution

    User Account
    If the affected user cannot sign into any machine using their Skype for Business account, but other user accounts are working successfully the impact is likely User Account.
    Troubleshooting involves verifying users SIP address is enabled for Skype for Business, and that service side account and policies are valid.
    How to test
    Try logging into an alternate machine, and if possible, an alternate network location with the same account.
    This will completely isolate the behavior to the user account and rule out other impact locations.

    User Profile
    Affected user can only repro while signed into Windows under their specific account. This could point to an issue with the Skype for business client profile, or the Windows Profile but is isolated to one of these.
    Troubleshooting is typically limited to cached information or policy settings.
    How to test
    Log into Windows on the same machine with a local admin account or other domain user and test sign in with your Skype for Business Online account.
    Note: This may not be a valid test if you are using Single Sign On (SSO) for authentication due to NT Credential policy enforcing the use of signed in credentials - by default you are not allowed to sign in with any account other than the active Windows UPN

    User Machine
    If every Skype for Business account under any Windows sign in fails, but Skype for Business account works from any other machine, the impact is User Machine.
    Troubleshooting is typically at the application level. Repair/Reinstall is a common troubleshooting step with this impact, but may also extend to machine level policy.
    How to test
    Log into Skype for Business client with an alternate account.

    User Network
    A key scoping question is whether the reported behavior reproduces from alternate network locations.
    If the problem cannot be reproduced from the coffee shop or home ISP connection, but is reproducible by multiple users in the same network, the impact location will likely be identified as User Network.
    Troubleshooting the User Network involves identifying each of the devices handling the outbound and inbound traffic for the location and verifying that they are properly configured to allow the ports and protocols required by Skype for Business client.
    How to test
    Try logging in from an alternate network location (coffee shop, home ISP, Azure Virtual Machine).

    User Pool
    When all users are clearly affected, regardless of their network location, account, machine or profile - the impact location will likely be determined at the User Pool level.
    In Office 365 service issues, this is a strong indication that there is an active Service Impacting Event in play.
    In on-premises issues, this impact often points to services being stopped on the affected pool.

Office 365 Federated Account

This type of account, commonly called a "Federated Identity" or Single Sign On, is created via Azure AD Connect where user attributes are sync'd into the service from the on-premises Active Directory.
Authentication process involves connecting to the Single Sign On server (ADFS or 3rd party) and receiving a Web ticket for Office 365 access.

By default, the signed in Windows Account UPN will be automatically passed through to the SSO server as the sign in credentials.

If these do not match the SIP account, there will be sign in failure and no rollover to credential prompt.

Troubleshooting

  1. Verify Single Sign ON (SSO)
    • Does affected user(s) fail to sign in to Office 365 portal?
    • Try also: https://<Your_ADFS_Endpoint>/adfs/ls/idpinitiatedsignon.aspx
    • Are any other Office 365 applications affected such as Outlook?
      If so, there are likely problems with ADFS - Please check here for more troubleshooting tips

  2. Verify DNS

    • Launch Microsoft Remote Connectivity Analyzer and run Office 365 Lync Domain Name Server (DNS) Connectivity Test
    • Enter any SIP address from the affected domain (*** Email address is removed for privacy ***)
    • Verify all four DNS entries are correct (green checks)
    • SRV record _sip._tls.contoso.com resolves to: sipdir.online.lync.com:443
      SRV record _sipfederationtls._tcp.contoso.com resolves to: sipfed.online.lync.com:5061
      CNAME record sip.contoso.com returned: sipdir.online.lync.com
      CNAME record lyncdiscover.contoso.com returned: webdir.online.lync.com
    • DNS failure messages are relevant and likely the root cause.
      See the following KBs to correct DNS configurations. 
      Check Set up Skype for Business Online and Troubleshooting Skype for Business Online DNS configuration issues in Office 365 for more information

      Note: On a Hybrid environment the DNS settings should be pointing to the on-premises endpoint, and the DNS errors on the above test will be expected.

  3. Verify user is signing into Windows with correct UPN.
    Open Command Prompt and run:
    whoami /upn

    The Skype for Business client uses the UPN from the active Windows login to perform authentication with ADFS / ID provider.
    This should match the UPN returned from the Powershel cmdlet get-csonlineuser 
    Local AD and Office 365 AD should have the same UPN unless customer has deployed some sort of workaround such as ADFS Alternate IDs

    Note: some 3rd party ID providers may have their own sync'd copy of the AD so you need to verify if UPN matches all around


    Try to bypass SSO with the DisableNTCredentials policy (you should create if it does not exist)
    HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Lync\
    DisableNTCredentials  DWORD value to 1

    Require logon credentials
    (DisableNTCredentials)
    Requires the user to provide logon credentials for Lync rather than automatically using Windows credentials during sign-in to a SIP server.
    Full article here
    Additionally you can use NoDomainUser which affects all Office products, not just Skype for business.

    "HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity"
    Add a new DWORD value to the registry called NoDomainUser, and then set it to a value of 1.
    Additional info here 

    Verify UPN matches in on-premises and Office 365 (unless you have deployed some UPN workaround such as ADFS Alternate ID)

  4. Verify system clock on PC, ADFS Server is not more than +/-5 minutes off.
     
    Verify the time on the ADFS Proxy Server.
     Using fiddler, capture the traffic from your browser to  https://<Your_ADFS_Endpoint>/adfs/ls/idpinitiatedsignon.aspx
    On the response headers, check the Cache->Date.
    The time shown is in UTC and it should be whiting 5 minutes from the official current UTC time

  5. Verify ADFS / ID Provider endpoints
    Compatibility List: 3rd party identity providers

  6. Determine Impact Location
     

    User Account
    If the affected user cannot sign into any machine using their Skype for Business account, but other user accounts are working successfully the impact is likely User Account.
    Troubleshooting involves verifying users SIP address is enabled for Skype for Business, and that service side account and policies are valid.
    How to test
    Try logging into an alternate machine, and if possible, an alternate network location with the same account.
    This will completely isolate the behavior to the user account and rule out other impact locations.

    User Profile
    Affected user can only repro while signed into Windows under their specific account. This could point to an issue with the Skype for business client profile, or the Windows Profile but is isolated to one of these.
    Troubleshooting is typically limited to cached information or policy settings.
    How to test
    Log into Windows on the same machine with a local admin account or other domain user and test sign in with your Skype for Business Online account.
    Note: This may not be a valid test if you are using Single Sign On (SSO) for authentication due to NT Credential policy enforcing the use of signed in credentials - by default you are not allowed to sign in with any account other than the active Windows UPN

    User Machine
    If every Skype for Business account under any Windows sign in fails, but Skype for Business account works from any other machine, the impact is User Machine.
    Troubleshooting is typically at the application level. Repair/Reinstall is a common troubleshooting step with this impact, but may also extend to machine level policy.
    How to test
    Log into Skype for Business client with an alternate account.

    User Network
    A key scoping question is whether the reported behavior reproduces from alternate network locations.
    If the problem cannot be reproduced from the coffee shop or home ISP connection, but is reproducible by multiple users in the same network, the impact location will likely be identified as User Network.
    Troubleshooting the User Network involves identifying each of the devices handling the outbound and inbound traffic for the location and verifying that they are properly configured to allow the ports and protocols required by Skype for Business client.
    How to test
    Try logging in from an alternate network location (coffee shop, home ISP, Azure Virtual Machine).

    User Pool
    When all users are clearly affected, regardless of their network location, account, machine or profile - the impact location will likely be determined at the User Pool level.
    In Office 365 service issues, this is a strong indication that there is an active Service Impacting Event in play.
    In on-premises issues, this impact often points to services being stopped on the affected pool.

Office 365 / On-premises Hybrid

In this scenario users were initially created in the on-premises environment and then moved to Office 365 via the Move-CsUser cmdlet and are not able to sign-in to Office 365

When the environment uses a shared SIP address (Hybrid) all authentication will initially be directed to the on-premises Front End (FE) or Edge server.
The user is determined by the on-premises deployment to be homed in O365 and redirected for authentication.

Troubleshooting


  1. Verify DNS
    • Launch Microsoft Remote Connectivity Analyzer and run Office 365 Lync Domain Name Server (DNS) Connectivity Test
    • Enter any SIP address from the affected domain (*** Email address is removed for privacy ***)
    • Verify if the two DNS entries are correct (green checks)
    • SRV record _sip._tls.contoso.com resolves to: sipdir.online.lync.com:443
    • SRV record _sipfederationtls._tcp.contoso.com resolves to: sipfed.online.lync.com:5061

      Note: The two CNAME entries with O365 are not required for Hybrid setups
  2. Verify certificate checks return successful in Microsoft Remote Connectivity Analyzer .
    If there are certificate errors, use the Cert Check tool from Digicert (or other of your choice) to view full certificate details.
    Check both sip.contoso.com:443 and sip.contoso.com:5061
    Validate if Common Name matches exactly (wildcard not supported here) and that the certificate is not expired.
    Verify if full certificate chain is installed into the certificate store.


    Verify if Hybrid configuration is set up correctly according to documentation
    Configure hybrid with Skype for Business Online

    Specifically, run the following:
    Get-CSAccessEdgeConfiguration
    Verify:
    -AllowOutsideUsers 1
    -AllowFederatedUsers 1
    -UseDnsSrvRouting

    Get-CSHostingProvider
    Verify:
    -ProxyFqdn "sipfed.online.lync.com"
    -Enabled $true -EnabledSharedAddressSpace $true
    -HostsOCSUsers $true
    -VerificationLevel UseSourceVerification
    -IsLocal $false
    -AutodiscoverUrl https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root

    Get-CsTenantFederationConfiguration
    Verify:
    -SharedSipAddressSpace $true


    Verify users were sync'd into O365 prior to move.
    Check KB article
    "You need to synchronize the AD accounts for all Skype for Business users in your organization between your on-premises and online deployments, even if users are not moved to Skype for Business Online. If you do not synchronize all users, communication between on-premises and online users in your organization may not work as expected."

    Verify if users were added to O365 with the Move-CsUser cmdlet from on-premises and not created directly in O365.

  3. Determine Impact location

    User Account
    If the affected user cannot sign into any machine using their Skype for Business account, but other user accounts are working successfully the impact is likely User Account.
    Troubleshooting involves verifying users SIP address is enabled for Skype for Business, and that service side account and policies are valid.
    How to test
    Try logging into an alternate machine, and if possible, an alternate network location with the same account.
    This will completely isolate the behavior to the user account and rule out other impact locations.

    User Profile
    Affected user can only repro while signed into Windows under their specific account. This could point to an issue with the Skype for business client profile, or the Windows Profile but is isolated to one of these.
    Troubleshooting is typically limited to cached information or policy settings.
    How to test
    Log into Windows on the same machine with a local admin account or other domain user and test sign in with your Skype for Business Online account.
    Note: This may not be a valid test if you are using Single Sign On (SSO) for authentication due to NT Credential policy enforcing the use of signed in credentials - by default you are not allowed to sign in with any account other than the active Windows UPN

    User Machine
    If every Skype for Business account under any Windows sign in fails, but Skype for Business account works from any other machine, the impact is User Machine.
    Troubleshooting is typically at the application level. Repair/Reinstall is a common troubleshooting step with this impact, but may also extend to machine level policy.
    How to test
    Log into Skype for Business client with an alternate account.

    User Network
    A key scoping question is whether the reported behavior reproduces from alternate network locations.
    If the problem cannot be reproduced from the coffee shop or home ISP connection, but is reproducible by multiple users in the same network, the impact location will likely be identified as User Network.
    Troubleshooting the User Network involves identifying each of the devices handling the outbound and inbound traffic for the location and verifying that they are properly configured to allow the ports and protocols required by Skype for Business client.
    How to test
    Try logging in from an alternate network location (coffee shop, home ISP, Azure Virtual Machine).

    User Pool
    When all users are clearly affected, regardless of their network location, account, machine or profile - the impact location will likely be determined at the User Pool level.
    In Office 365 service issues, this is a strong indication that there is an active Service Impacting Event in play.
    In on-premises issues, this impact often points to services being stopped on the affected pool.

 

Forum Article Info


Last updated April 6, 2019 Views 2,271 Applies to: