DCOM Autho Error 529 and 681 with Default Authentication Level = N

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Since IS moved our server out of it’s trusted domain into it own workgroup,
what we see is that when ever our remote VB application application does a
dcom CreateObject on the server MTS dlls, we get many of the following
errors Authentication security errors 681, 529, 681, 529 and the the
application continues w/o problems except slowly. We have turned off DCOM
Authentication which had no effect. We have a slowdown problem even if event
logging is turned off. There are 2 other servers (NT4 and W2K) experiencing
this problem. Is there anyway we can stop to Authentication checks and speed
up our application?

Our VB 6.0/DCOM/MS SQL application has been in production for 5 years. The
MS MTS / DCOM/ MS SQL 2000 is running on one W2K Server with SP 4. IS just
changed the server configuration from a Domain with trusts to the main
company domain to its own workgroup w/o trusts. Since that time, we are
getting a large number of Security Errors (Event ID 529 and 681 (error code =
3221225572) and system access has gotten very slow.

Default Security Properties for using dcomcnfg are Default Authentication
Level = None and Default Impersonation Level = Anonymous or Delegate, or
Identify, or Impersonate (have tried them all).

At the Component Services level Authorization Enforce Access Checks is
unchecked and Security Level = Perform Access Checks only at the process
level and Default Authentication Level = None and Default Impersonation
Level = Anonymous or Delegate, or Identify, or Impersonate (have tried them
all).
 
Default Authentication Level = None
means that no auth level has been set which will be used
only when the individual applications do not set an auth
level. You really need to look at the dcom permissions
of the specific components.

You really need to let your "IT" know that they have
hosed your line of business application, which likely
used to depend on domain credentials but now must go
through a list of negotiations before apparently finding
a way that will work (and which by the way is likely
very non-secure). If you are being able to use this now
without having adjusted the way the remoting is able
to authenticate, you may be relying on anonymous
access, which means you / your DB data is wide open
to malicious examination/poking/corruption/etc..
 
Back
Top