Re: Lost admin access to ADAM



I checked the event logs; all are clean but I did notice a lot of entries in
the security log; paging through them I found serveral references to dsamain:

The Windows Firewall has detected an application listening for incoming
traffic.

Name: -
Path: C:\WINNT\ADAM\dsamain.exe
Process identifier: 6140
User account: NETWORK SERVICE
User domain: NT AUTHORITY
Service: Yes
RPC server: No
IP version: IPv4
IP protocol: TCP
Port number: 389
Allowed: No
User notified: No

I thought that it might be a firewall issue but now I'm not so sure. I
checked the FW settings; it is off, but greyed out because 'some settings are
controlled by group policy'. In spite of what the log says, I can go to
another box and issue the command: telnet <my ipaddress> 389 and it will
connect (just hangs), so I'd think that the port isn't really getting
blocked, that the service is still listening to the port. Is this a log
entry really mean anything?


"Dmitri Gavrilov [MSFT]" wrote:

Something funky in auth system. Anything interesting in the system or
security logs? Is there NDS client in the picture? Did you harden the system
(or domain)?

One thing I can suggest is to use computername\administrators (builtin
admins) as ADAM admin principal, as opposed to a specific user. Then you can
use your domain account to connect (provided this account is a member of
BA).

--
Dmitri Gavrilov
SDE, DS Admin eXperience

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Andy!" <Andy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:69E96455-1855-4087-A1B0-C14122797E92@xxxxxxxxxxxxxxxx
Thanks Dmitri; That does blow away the instance, but still leaves me with
the
original problem. If I install with my account (which has has local
admin
rights) the LDIF imports fail. This is odd because as part of the
installation it asks if you want to give the logged in user admin rights
to
the instance, then it promptly fails a few minutes later when it tries to
do
the import with that same account. If I cancel the install the service
is
running (and listening on 389) but if I try to manually import I get:

C:\WINNT\ADAM>ldifde -i -f ms-user.ldf -s localhost:389 -k -j .
-c CN=Schema,CN=Configuration,O=LAB,C=US" #schemaNamingContext
Connecting to "localhost:389"
Logging in as current user using SSPI
SSPI "bind as current user" returned 'Timeout'

Clearly something is wrong with the account but what? I'm logged in with
my
domain account (no typeos) which works otherwise but it doesn't take.
Event
log looks clean.

"Dmitri Gavrilov [MSFT]" wrote:

%windir%\adam\adamuninstall.exe /force /i:instanceName

--
Dmitri Gavrilov
SDE, DS Admin eXperience

This posting is provided "AS IS" with no warranties, and confers no
rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Andy!" <Andy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:907364DB-E558-44C6-8946-6C8E1C9318D0@xxxxxxxxxxxxxxxx
I can't quite identify the cause but I no longer am able to access adam
which
is installed on XP/pro. When I bring up adsi edit it hangs and returns
"the
operation returned because the timeout period expired." so I blew
everything
away and re-installed ADAM SP1. Same problem. When I try to create a
new
instance it works but the LDIF imports fail (logfile contains:
ADAMERR_REPCREDS_INVALID) and when I try to remote the instance with
Adamuninstall (or from the control panel) I get and error 1053 (service
did
not respond). (but the intstance/service is still listening on the
specified port)

End result is that I'm stuck, can't delete it (w/o hacking the
registry),
or
access it and I haven't been able to identify was caused it. TIA -
The
data
wasn't crucial, but my application testing is dead in the water.
(Frustration level = high)








.