Tag: SSO

[Solved] Single sign-on users in Office 365 can’t sign in to Lync Online from inside their corporate network

Lync 2013 Fails to connect to service.

You installed Lync 2013 on a domain computer and it fails to connect to the Office365 Lync service. Users who connect from inside their corporate network can’t sign in to Lync Online from Lync 2013, and they receive the following error message: Cannot sign in because the server is temporarily unavailable.  This issue only applies to Enterprise SSO users who sign in to Microsoft Lync Online by using Microsoft Lync 2013 from inside their corporate network.   If you modify the DNS of the computer to use a public DNS address the lync client connects for 8 hours and then fails if DNS is pushed back to the domain level DNS. All internal computers have this problem with connecting where external systems do not.

AD FS 2.0 utilizes the HOST service type for SPN registration because of default Windows Communication Foundation (WCF) SPN requirements. While HTTP makes sense for web-based applications, it does not satisfy rich clients who use the WS-Trust protocol.

 

When you deploy an AD FS 2.0 Federation Server farm, you must specify a domain-based service account that needs a registered SPN to enable Kerberos authentication to function correctly.

Log in to you ADFS server and set a HOST SPN.

setspn -s host/{your_Federation_Service_name} {domain_name}\{service_account}

Make sure that the AD FS 2.0 service is running under the domain-based service account that was mentioned in the previous step. Afterwards you will need to set the service account on the ADFS service to use the same domain service account and restart the ADFS2 services.

Configure the AD FS 2.0 server to accept request headers that are larger than 40 kilobytes (KB). Microsoft says -> The HTTP request that the user sends to the Internet Information Services (IIS) server contains the Kerberos token in the WWW-Authenticate header. Therefore, the header size increases as the number of groups increases. If the HTTP header or packet size increases beyond the limits that are configured in IIS, IIS may reject the request and send an error as the response. If the previous solutions didn’t resolve the problem, downgrade to Lync 2010 or try running Lync2013 as a Local administraor.

 

 

 

Quick and Easy Setup of Active Directory Authentication for VMware vSphere 5.1 SSO (Single Sign On)

VMware vSphere vCenter Server 5.1 now uses a new SSO (Single Sign On) service to authenticate with Microsoft Active Directory when deploying vCenter. If you do not install this services and configure it for AD then you will not be able to use your domain accounts with vCenter 5.1  During the initial install you may get errors when installing SSO.  KB 2034374 reports that a error of  ” Error 29155 Identity source discovery error”  is due to a failed attempt to automatically discover your Active Directory domain. Verify that the domain name and DNS are setup correctly.

Now lets setup an AD server in vCenter to allow our Domain Accounts. First we will login to vCenter Web Client (https://127.0.0.1:9443) if you used the default ports for the web client installs. The default login is admin@system-domain  and the password you set for SSO during the install process. Once you are logged in to the web client you can continue.

Now Select [Administration]

vCenter SSO-login

 

 

 

 

 

 

 

 

 

Now Select [Sign-On and Discovery] -> [Configuration]

SSO Configuration

 

 

 

 

 

 

 

 

Under the Identity Sources Tab in the right pane select the PLUS symbol to add a new AD source. This will pop up a “Add Identity Source” window, select the active directory radio button and fill out the requested information with you AD Domain name and the “OU” the holds your users and groups.

Here is the generic information you will need just replace the sesenviron.local with your domain and then place your AD credentials at the bottom.

Adding identity source

 

 

 

 

 

 

 

 

 

 

Now that we have a AD server assigned as a source we must now add this newly created connector to our “Default Domains ” list.

Add AD to Default Domains list

 

 

 

 

 

 

 

 

Now that we have it in our Default Domains list lets move it up to be our primary source. To do this highlight the AD domain name and select the blue arrow head pointing up and move the domain name to the top of the list .

Set priority of the domains

 

 

 

 

 

 

 

 

 

 

Now lets select the small floppy disk icon to save the changes to the default domain list box. Once this is complete we should be able to open up the vSphere client application and log in with domain access. You should be using a domain level admin to access vCenter.

 

I hope this helps some people out there.

Cubert 😎