Re: SSL LDAP intermittent failure to bind
- From: "Paul Bergson [MVP-DS]" <pbbergs@xxxxxxxxxxxxxx>
- Date: Fri, 5 Jun 2009 07:45:09 -0500
Just live with the error, it isn't hurting anything and you know what it is.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
http://www.pbbergs.com
Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
"apex52" <apex52@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:BCECE780-61FB-4C09-B698-26256AF45E74@xxxxxxxxxxxxxxxx
I have found that the failures are actually due to the enchancements in
2008
Kerberos in regard to AES.
"This error was caused by Kerberos Enhancements in Windows Server 2008.
The
base Kerberos protocol in Windows Server 2008 supports AES for encryption
of
ticket-granting tickets (TGTs), service tickets, and session keys.
But old systems don't support this new encryption type. So the first try
failed and you can find a Success 4768 after this failure. "
It is a linux box which does not require a kerberos ticket so I am trying
to
figure out if there is a way to manage the service to either revert back
to
2003 or stop sending the ticket. I don't want to give up the funtionality
of
my 2008 DC's.
"Paul Bergson [MVP-DS]" wrote:
This is referencing a group that contains no members. I'm guessing these
are not related.
ServiceSid S-1-0-0
http://msdn.microsoft.com/en-us/library/aa379649.aspx
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
http://www.pbbergs.com
Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
"apex52" <apex52@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:42493D24-66F5-479B-A33E-00AC5C0239A2@xxxxxxxxxxxxxxxx
I was able to get an error message. When it fails, I receive the
following
failure in Security logs. I am hoping this will shed some light on the
problem.
- Provider
[ Name] Microsoft-Windows-Security-Auditing
[ Guid] {54849625-5478-4994-a5ba-3e3b0328c30d}
EventID 4769
Version 0
Level 0
Task 14337
Opcode 0
Keywords 0x8010000000000000
- TimeCreated
[ SystemTime] 2009-06-04T19:09:55.319Z
EventRecordID 588504
Correlation
- Execution
[ ProcessID] 592
[ ThreadID] 684
Channel Security
Computer "domain name"
Security
- EventData
TargetUserName "domain name"
TargetDomainName "domain name"
ServiceName krbtgt/"domain name"
ServiceSid S-1-0-0
TicketOptions 0x60810010
TicketEncryptionType 0xffffffff
IpAddress ::1
IpPort 0
Status 0xe
LogonGuid {00000000-0000-0000-0000-000000000000}
TransmittedServices -
"Paul Bergson [MVP-DS]" wrote:
I don't know of anything that could be blocking this.
Maybe this ties into an issue with the lssas service? I don'r have
much
to
go on this for you. You could try running wireshark to see if
something
is
being dropped on one side or the other, but that could be extremely
difficult to track.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
http://www.pbbergs.com
Please no e-mails, any questions should be posted in the NewsGroup
This
posting is provided "AS IS" with no warranties, and confers no rights.
"apex52" <apex52@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D7253BA2-04D5-4ABC-A9F7-B91E5EB89195@xxxxxxxxxxxxxxxx
Thanks for the reply. My PDC emulator is pulling NTP off of an
internal
Time
server and the linux box running PHP is pulling from it as well. The
other
three domain controllers are pulling time from the Domain Hierarchy
and
sync
correctly. I still get intermittent failures. Is there a security
mechanism
that blocks LDAP\SSL connections if it gets bombarded with requests?
Is
it
possible to log the denials, either within Windows or though a
different
utility? It seems like once I get a failure, it is unable to connect
for a
short period of time. I wish I could be more precise, but there does
not
seem
to be a pattern.
"Paul Bergson [MVP-DS]" wrote:
My only thought is time skew, but I doubt it since you do get some
successful connections. How close are the two clocks? I believe
this
could
also be caused by lag time between packets sent out and recieved,
but
again
it would be extermely odd if you had many hops in an internal
environment.
--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
http://www.pbbergs.com
Please no e-mails, any questions should be posted in the NewsGroup
This
posting is provided "AS IS" with no warranties, and confers no
rights.
"apex52" <apex52@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D4E81161-D1E1-4F52-9B68-6585881524CE@xxxxxxxxxxxxxxxx
I have four 2008 Domain Controllers in a single domain and a 2008
CA.
I
am
connecting from a linux machine to ldap over ssl using a Domain
Controller
Certificate issued by the CA. I can connect with no failures over
389,
but
when I connect over 636 I get random failed to bind messages. The
security
log in event viewer is not logging any failed events. This is a
non
production domain so I know it is not reaching the 5000
connection
limit.
I
am not sure where to look next. The PHP application connects to
all
DC's
for
testing and they fail at the same time.
.
- References:
- SSL LDAP intermittent failure to bind
- From: apex52
- Re: SSL LDAP intermittent failure to bind
- From: Paul Bergson [MVP-DS]
- Re: SSL LDAP intermittent failure to bind
- From: apex52
- Re: SSL LDAP intermittent failure to bind
- From: Paul Bergson [MVP-DS]
- Re: SSL LDAP intermittent failure to bind
- From: apex52
- Re: SSL LDAP intermittent failure to bind
- From: Paul Bergson [MVP-DS]
- Re: SSL LDAP intermittent failure to bind
- From: apex52
- SSL LDAP intermittent failure to bind
- Prev by Date: Re: AD transition from w2k3 std to w2k3 std R2
- Next by Date: Re: 1 of 2 domain controllers down and users cannot login to the d
- Previous by thread: Re: SSL LDAP intermittent failure to bind
- Next by thread: Ad GP and regional settings
- Index(es):
Relevant Pages
|
