From: cyclon on
Hello,

is this something new in small business server 2008? We have been
working with our erp program since 2001, first on small business server
2000, then on small business server 2003 and since last year on small
business server 2008. There was no problem with the previous versions
of small business server.

I also informed the vendor about this problem, and apparently we were
the first who had encountered this problem. I will ask them to search
for a solution for this problem.

Greetings,

cyclon



Cliff Galiher - MVP schreef op 20/05/2010 het volgende :


> The default time for a kerberos ticket is set that way for a reason. Changing
> this time too much exponentially increases your risk factor and is an
> insecure way to operate. Unless it is absolutely necessary, I'd encourage
> users to just log out and log back in or push back on the vendor to fix this
> bug in their software.
>
> -Cliff
>
>
> "cyclon" <cyclon(a)base.be.invalid> wrote in message
> news:mn.a2bd7da5107f61cd.85122(a)base.be.invalid...
>> Hello,
>>
>> the problem is solved, it was the default time for the kerberos ticket that
>> caused the problem. Now we have changed this time, and there is no longer
>> a problem.
>>
>> Thank you very much,
>>
>> greetings,
>>
>> cyclon
>>
>>
>>
>> Cliff Galiher - MVP schreef op 13/05/2010 het volgende :
>>
>>
>>> 10 hours is the default time that a kerberos ticket is issued for in a
>>> windows Active Directory network. That glitch is not the network
>>> dropping, but is the server replying with an explicit access denied to the
>>> client because the ticket is expired. The client automatically requests a
>>> renewal of the ticket, which is granted, so for most network activities,
>>> you never "see" that renegotiation. A network application *should* be
>>> able to anticipate and accommodate this as this is standard practice in
>>> any network.
>>
>>


From: Cliff Galiher - MVP on
It is not new to 2008. But don't forget that Windows negotiates the "best"
authentication method between supported client and server. Kerberos will be
chosen whenever possible as long as both client and server support it.
Older methods such as NTLMv2 or NTLM are only chosen when Kerberos cannot be
negotiated and when group policies allow it. This has been the usual way for
authentication for the last several versions of windows server (not just
SBS.)

-Cliff


"cyclon" <cyclon(a)base.be.invalid> wrote in message
news:mn.ac507da5a94f04bd.85122(a)base.be.invalid...
> Hello,
>
> is this something new in small business server 2008? We have been working
> with our erp program since 2001, first on small business server 2000, then
> on small business server 2003 and since last year on small business server
> 2008. There was no problem with the previous versions of small business
> server.
>
> I also informed the vendor about this problem, and apparently we were the
> first who had encountered this problem. I will ask them to search for a
> solution for this problem.
>
> Greetings,
>
> cyclon
>
>
>
> Cliff Galiher - MVP schreef op 20/05/2010 het volgende :
>
>
>> The default time for a kerberos ticket is set that way for a reason.
>> Changing this time too much exponentially increases your risk factor and
>> is an insecure way to operate. Unless it is absolutely necessary, I'd
>> encourage users to just log out and log back in or push back on the
>> vendor to fix this bug in their software.
>>
>> -Cliff
>>
>>
>> "cyclon" <cyclon(a)base.be.invalid> wrote in message
>> news:mn.a2bd7da5107f61cd.85122(a)base.be.invalid...
>>> Hello,
>>>
>>> the problem is solved, it was the default time for the kerberos ticket
>>> that caused the problem. Now we have changed this time, and there is no
>>> longer a problem.
>>>
>>> Thank you very much,
>>>
>>> greetings,
>>>
>>> cyclon
>>>
>>>
>>>
>>> Cliff Galiher - MVP schreef op 13/05/2010 het volgende :
>>>
>>>
>>>> 10 hours is the default time that a kerberos ticket is issued for in a
>>>> windows Active Directory network. That glitch is not the network
>>>> dropping, but is the server replying with an explicit access denied to
>>>> the client because the ticket is expired. The client automatically
>>>> requests a renewal of the ticket, which is granted, so for most network
>>>> activities, you never "see" that renegotiation. A network application
>>>> *should* be able to anticipate and accommodate this as this is standard
>>>> practice in any network.
>>>
>>>
>
>
From: Jim Behning SBS MVP on
Grabbing at straws. Run the SBS BPA for SBS 2008 if you have not.
There are some clicks they may want you to do that may help with
disconnect issues.

On Fri, 21 May 2010 18:24:01 +0200, cyclon <cyclon(a)base.be.invalid>
wrote:

>
>Hello,
>
>is this something new in small business server 2008? We have been
>working with our erp program since 2001, first on small business server
>2000, then on small business server 2003 and since last year on small
>business server 2008. There was no problem with the previous versions
>of small business server.
>
>I also informed the vendor about this problem, and apparently we were
>the first who had encountered this problem. I will ask them to search
>for a solution for this problem.
>
>Greetings,
>
>cyclon
>
>
>
>Cliff Galiher - MVP schreef op 20/05/2010 het volgende :
>
>
>> The default time for a kerberos ticket is set that way for a reason. Changing
>> this time too much exponentially increases your risk factor and is an
>> insecure way to operate. Unless it is absolutely necessary, I'd encourage
>> users to just log out and log back in or push back on the vendor to fix this
>> bug in their software.
>>
>> -Cliff
>>
>>
>> "cyclon" <cyclon(a)base.be.invalid> wrote in message
>> news:mn.a2bd7da5107f61cd.85122(a)base.be.invalid...
>>> Hello,
>>>
>>> the problem is solved, it was the default time for the kerberos ticket that
>>> caused the problem. Now we have changed this time, and there is no longer
>>> a problem.
>>>
>>> Thank you very much,
>>>
>>> greetings,
>>>
>>> cyclon
>>>
>>>
>>>
>>> Cliff Galiher - MVP schreef op 13/05/2010 het volgende :
>>>
>>>
>>>> 10 hours is the default time that a kerberos ticket is issued for in a
>>>> windows Active Directory network. That glitch is not the network
>>>> dropping, but is the server replying with an explicit access denied to the
>>>> client because the ticket is expired. The client automatically requests a
>>>> renewal of the ticket, which is granted, so for most network activities,
>>>> you never "see" that renegotiation. A network application *should* be
>>>> able to anticipate and accommodate this as this is standard practice in
>>>> any network.
>>>
>>>
>
See what SBS support is working on
http://blogs.technet.com/sbs/default.aspx
Check your SBS with the SBS Best Practices Analyzer
http://blogs.technet.com/sbs/archive/tags/BPA/default.aspx