Search This Blog

Showing posts with label OCS. Show all posts
Showing posts with label OCS. Show all posts

Feb 14, 2012

User unable to connect to OCS because token size was too large

Hello ALL,

A small issue that occurred and I'd like to share. Simple but sometimes you need to read.
 

Issue:

A user was unable to connect to OCS with Office Communicator.

Symptoms:

 Error message was: Cannot sign in to Communicator. You may have entered your sign-in address, user name incorrectly, or the authentication service may be incompatible with this version of the program. If your sign-in information is correct and the problem persists, please contact your system administrator.

System Event log entry was:

The kerberos SSPI package generated an output token of size 12175 bytes, which was too large to fit in the token buffer of size 12000 bytes, provided by process id 6492.

The output SSPI token being too large is probably the result of the user blablabla@mpc.local being a member of a large number of groups.

It is recommended to minimize the number of groups a user belongs to. If the problem can not be corrected by reduction of the group memberships of this user, please contact your system administrator to increase the maximum token size, which in term is configured machine-wide via the following registry value: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize.



Solution:
Reduce the number of groups to which the user belongs.

Explanation: The user is not able to authenticate because the Kerberos token that is generated during authentication attempts has a fixed maximum size. Transports such as remote procedure call (RPC) and HTTP rely on the MaxTokenSize value when they allocate buffers for authentication. In Windows 2000 (the original released version), the MaxTokenSize value is 8,000 bytes. In Windows 2000 Service Pack 2 (SP2) and Microsoft Windows Server 2003 and and still remains in Windows 7 and Windows 2008 R2, the MaxTokenSize value is 12,000 bytes.

If a user is a member of more than 120 groups, the buffer that is determined by the MaxTokenSize value is not large enough. As a result, users cannot authenticate, and they may receive an "out of memory" error message.

This is why the default value is not a hard limit, the maximum recommended configuration is 65535 bytes or 64k. It is recommended that you do not set the MaxTokenSize greater than 65535 bytes or 64k. If you set the MaxTokenSize greater than 65535 bytes applications using Kerberos authentication could potentially fail.

If you want the another solution for this same case is change the MaxTokenSize.


Articles Related
===========

New resolution for problems with Kerberos authentication when users belong to many groups
http://support.microsoft.com/kb/327825

MaxTokenSize and Kerberos Token Bloat
http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-and-kerberos-token-bloat.aspx


Dec 19, 2011

OCS Live meeting error 0x80092010

Hello,

It's a new post after moving to a new position in another company.  (it's the summary done by Microsoft Support).
This issue is interesting and very specific let's try check if it can help you.


The symptom --> External users unable to Join a Live meeting and getting an error 0x80092010. The users unable to join live meeting externally on internet.

Cause :  The Front end servers were not updating web conferencing edge server details. The front end servers has error message “Failed to connect external users because the list of proxies is empty.

Resolution   : 
Ø Verified the certificates installed  on the front and the Edge Servers.
Ø Verified that OCS Front End and Pool FQDN are added to Internal properties of the all Edge Server
Ø Verified that on Pool  web conferencing properties have correct information of Edge Server FQDN.
Ø Restarted the web conferencing services on each front end Servers in Pool.

More information:
Ø The users was not able to join live meeting getting an error message 0x80092010.
Ø We verified the MTLS certificate on the Office communication front end servers and Edge Servers.
Ø We verified the CRL using  certutil command certutil -f –urlfetch -verify [FilenameOfCertificate]
Ø We Collected the Live meeting PwConsolLog and LM UccApilog.
Ø In the uccapilog logs we noticed the following message - <key>numberOfProxies</key> <value>0</value>
Ø Based on the Event we verified that OCS Pool web conferencing properties. In the web conferencing edge server tab we verified that Internal FQDN has FQDN of two edge servers. Also External FQDN has listed the external name for web conferencing webconf.ctr.nestle.com.
Ø We verified that Edge Servers has listed on Internal Tab all the Server FQDN and pool nMae.
Ø We downloaded the CRL certificate on both the Edge Server and installed on both the Edge Server.
Ø We logged on to all front end servers tested the Telnet to internal interface of Edge Server on port 8057.
Ø We logged on to the Edge Servers and tested the Telnet to all the Front End servers on port 8057.
Ø We verified if Front End server IP address is resolvable from two Edge Servers.
Ø We checked the event logs on front End servers. Noticed event ID  41061 “Failed to connect external users because the list of proxies is empty.”
Ø We restarted Office Communications Server Web Conferencing on all the four front end servers. That updated proxies information on pool.