Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SCCS 5.0 in 2003 Domain - Kerberos Authentication Problem

Status
Not open for further replies.
Mar 14, 2007
7
CA
We have our SCCS server configured to Nortel's specifications. It is set to sync it's time with the PBX using MAS time service, Windows Time service is disables and the "Adjust DST Time" option is not enabled.

Nortel's recommended configuration is the root of our problem. We are running a Windows 2003 domain using Kerberos authentication. All our workstations and servers are set to sync their time with the domain controllers and have the "adjust for DST" option enabled. There are a number of factors that must be considered to understand domain time and security. The time on the domain takes into consideration the time zone and DST settings but ultimately it is based on GMT time. During the summer months outside of DST we are -7 hrs GMT. By having the "adjust for DST" option enabled, all the computer and server clocks stay in sync at -7 GMT. This is critical for Kerberos authentication because by default Kerberos only allows a 5 minute discrepancy in time between servers and the domain controllers. The situation with the SCCS server is that because the "adjust for DST" is not set the difference in GMT time never changes staying at - 8 hrs GMT. This causes the problem with Kerberos because the SCCS server is out of time sync with the domain time by 1 hr. It has nothing to do with the time that is displayed on the desktop….

It would seem that this may be a design flaw. When configured to Nortel's specifications, as is our situation, we have domain security \ authentication issues on the SCCS server. If we were to enable the "adjust for DST" on SCCS it will throw reporting off by an hour.

The production problem we are having is that when the Domain realizes the discrepancy in the time it denies users access to shares on the SCCS server.

The error reported in Event Viewer is Event ID:40960 Source: LSASRV and reads as follows:

The Security System detected an authentication error for the server cifs/VCHODC3 The failure code from authentication protocol Kerberos was "The time at the Primary Domain Controller is different than the time at the Backup Domain Controller or member server by too large an amount.
(0xc0000133)".


Nortel seems to be scratching their heads on this even though it only makes sense based on how the OS operates. Anyone else seen this and been able to resolve it?
 
Well, first of all, correct the Daylight Savings Time settings on the PBX. There have been a number of posts here in the last couple of weeks explaining how to do that. There is no reason your PBX should not change automatically.

Then, make sure the clock on the PBX is accurate and keeping time. It may be necessary to have a technician adjust it if it is running fast or slow (this is a software change).

Finally, if johnpoole is reading this, he may repost his thread for have a procomm script periodically update the PBX time. Or do a search on the forum, there are a couple of them out there. This may not be a practical thing to implement in your circumstances, I don't know.
 
Thanks sandyml...The problem is not with the time on the PBX or if it adjusts for DST or not. The problem is with the Nortel recommended configuration in a Windows 2003 Domain environment using Kerberos authentication. In order for the SCCS server to stay within the 5 min time skew allowed by Kerberos the server must adjust it's time for DST along with all the other servers and workstations in the domain. The Nortel configuration is to not check the "Automatically sajust clock for daylight savings changes" in the Date and Time Properties on the SCCS server. So the problem is when the GMT time (which domain authentication is set against, not the actual time displayed on the desktop) shifts 1 hr the domain and the SCCS server are out of sync by 1 hr. Thus causing the server to exceed the 5 min max time skew allowed for Kerberos.

If we check the DST adjsut option on the server it throws reporting out by 1 hr....


 
OK, maybe I'm not following you. I know the deal about Kerberos. The PBX should shift at the same time as your domain time server, and the Symposium takes its time from the PBX. Is this not occurring? Or if it is, what is the lag time?
 
Our Domain time synch's with an external time source however our PBX time is set manually on the switch. Our PBX is a Meridian 1 switch and that's the way it needs to be done at this point. The problem still remains that regardless of how the PBX time is set, we cannot set the SCCS server to adjust for DST without throwing reporting off by 1 hr. In order for the SCCS server to stay compliant for Kerberos we would need to set it to adjust for DST. The PBX time and how it is set has nothing to do with this problem. The way I see it at this point is Nortel needs to come up with some type of patch that allows the DST adjust option to be set and that will correct the 1 hr reporting descrepancy created by the 1 hr shift in GMT.
 
OK, after this I will quietly drop out of this discussion. Here are a couple of threads that will help you. First, trust us, you do NOT have to manually change your PBX time; it can be set to do this for you automatically. Here is the thread for that:

thread798-1295972

Next, I mentioned a script to ensure that any time drift from the domain gets corrected. Here is that thread:

thread798-1319828

Paste those into the search window. Good luck to you.
 
Thanks again sandyml for your input. The threads provided would be helpful if the time displayed on the desktop clock of the server was actually the problem. This is not the case.

The PBX, Domain and Server all display the same time within 10 seconds. I need to fix the 1 hr GMT difference between the server and the domain to fix this issue. Take the PBX out of this all together...it has no bearing at all on Kerberos authentication in the doamin. GMT time, not desktop clock display, is what the Kerberos time skew is based on. My server is out 1 hr because GMT in our time zone is currently - 7hrs. The SCCS server is at - 8 hrs GMT because I cannot set the adjust for DST option on the server without breaking Symposium reporting. This is Nortels recommended configuration and it does not work.

Anyway....Thanks for your time. Perhaps we will just end up hacking the system ourselves to make it work. Nortel has been of no help thus far. FYI We been after them for a year on this.....
 
But the SCCS has a service running that matches thei time to the PBX - it needs to stay that way. The Call Timestamps must match

Jeff
 
Hi Jeff... Our configuration uses MAS time service to sync with the PBX and Windows time service is disabled (Nortel's recommended configuration). This is a good point and honestly have not looked at what happens specifically with call timestamps if we check the adjust for DST option on the SCCS server. It fixes the Kerberos problem and skews the reporting time stamps by 1 hr, this I do know.




 
Maybe time zone settings...

Did you check the time zone on the SCCS? Is it the same as the rest of the domain?
If it's an hour ahead of the time from within the PBX (which you want to leave out but you can't in this case) is added with this hour, which leads to your 1 hour time difference.

Supernn
 
Thanks but no...SCCS time zone is same as all other servers in the domain. The issue is strickly the difference in GMT between the SCCS server and the DC's within the domain.
 
Thanks but no...SCCS time zone is same as all other servers in the domain. The issue is strictly the difference in GMT between the SCCS server and the DC's within the domain.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top