Locked out of Admin account after changing the password

From my notes that I collected over the years

 ?func=admin.AdminUserLogin  this one will allow Login using KUAF if you remember the admin.index password.

http://<server>/otcs/cs.exe|llisapi.dll|<whatever script>?otdsauth=no-sso

bypass OTDS

forgot password

non working system

if you edit OT.ini then the seenOTDSPage flag will also need to be paid heed to

You might reach out to support as I think your OTDS interaction might be corrupted. Following my solutions sometimes requires some knowledge of the software but you may not want to learn the unsupported methods. There might be some errors occurring when you change the password in OTDS. They might help you for a faster resolution.

Nowadays this is the preferred method of setting up a content server from scratch. mentioning that in case this offers some solace

I always install and configure a TC so that I can run the OTDS server before I install CS. Make sure it is stable and running fine

I download System Center and Download CS software.

I make the SC do the installs

when prompted I point it to OTDS make sure everything is stable and even change the two default passwords that it keeps complaining about.I leave the search admin server default as it is a small VM.

Then if not prompted I check patches available for that version

I install that using SC and its agent. What it does is download all patches relevant to defects of your particular version and put it.

Most of the time one is able to work through that. What I think I learned is the OTDS server works best if it has the FQDN URL leaving it as localhost:8080 is asking for trouble :) You see that when you are in the livelink page that shows you the integration settings.

Does your integration OTDS URL look like a localhost or an FQDN? see from my server some screencaps for you to compare

OTDS Trusted Sites I run my CS on IIS on Port 90

MY CS to OTDS integration page

What happens is when you execute the URL that ends in cs.exe|llisapi.dll the livelink oscript code sees what the auth method is it is most likely "OTDS" then it says OK I am going to transfer the call to OTDS

in your case the CS server is on TC I believe in that system even on windows "contexts" matter case wise so you need to trap authentication difficulties by doing some research on the case. Cookies issued by servers are notorious in cases so in a windows/IIS offering you can call a server like HTTP:myserver/OTCS/llisapi.dll or HTTP:myserver/otcs/llisapi.dll but in TC where your livelink server is running the context is of absolute significance it will reject anything it won't like :)

all OTDS does is it takes your kerberos token and looks up the user in its DB and forwards it back to the original request. Once OTDS says it is a valid user the Oscript software crunches the token and figures out the user in this case if you logged into OTDS as the root otds user it will find 'Admin' that too is the case sensitive.CS database in an OTDS integration does not even care to look at a password :)

so in closing check your user CaSE and other things what you end up doing is not how all of us use it the adminuserlogin is a specialized RH.