JCI ADS Password resetting

[santhu_hardware]

Unfortunately costumer losses metasyssysagent (Admin user) password. I tried to reset password with sql tables but not succeed. Is there any otherway to reset password.

THANKS IN ADVANCE]

Santhu

[MatrixTransform]

This is a question Id like an answer to as well...

Does restoring a backup with a known good password work???

...or is that part of that weird security database backup stuff??

[berg2666]

Can he get on SCT at all ..... You could try to restore the security database but its a guess never had this problem If there is a security databse backup you may be able to restore it but had to have a password to get on SCT so is that one changed also.

[chewlak]

I think you need the metasyssysagent password to restore a security database on SCT.

[Lambo]

There may be some backdoor hacker methods out there for restoring or changing ADS/ADX/SCT/NAE passwords, but you may do more harm than good if you make mistakes in places like SQL or the Windows registry.
The most reliable way is to uninstall and reinstall software (ADS/ADX/SCT) for systems with a server, or to re-image the NAE if it is a stand-alone device that gets accessed directly from a user interface P.C.

[D1G]

Is there a reason you can't use Osql to reset the password? Logged in as admin and assuming the admin group has admin SQL privs something like:
START > RUN > cmd
Osql -S <servername> (or -p <instancename>) -E
>EXEC sp_password NULL, 'yourpassword', 'accountname'
>GO

I'm not real certain about substituting the -p flag for the -S but it should work; it's been a really long time since I've had to deal with passwords so YMMV. I'd also back up the DB before start playing with Osql.

[Lambo]

I’d have to do some searching around for some syntax examples. I assume that your SQL is below 2005. OSQL was replaced by SQLCMD at 2005. I’ve seen examples of changing the SQL SA (System Admin) password, but I’m not sure how that would relate to the metasyssysagent password. The standard SQL SA password is “MetasysPW” while the out-of-the-box metasyssysagent password is XMG3-Rel.1 as you probably know.
I’m not sure if I got the whole story, but have you lost the ability to log on to the ADS and SCT? In a pinch, you could log into each NAE individually, unless their passwords were changed as well. I would hope that there is a current backup for the site. If so, then performing an ADS/SCT uninstall/reinstall wouldn’t take that long.

[D1G]

I managed to make it seem a lot simpler than it is. I assumed the intent would be obvious but I agree it's not. I was trying to imply that between SQL's tools and access to the application it's possible to recover this data.

The equivilant command in sqlcmd would be:
start > run > cmd
sqlcmd -S server\instance
1> sp_password @new = ’yourpassword’, @loginame = ‘sqlaccount’
2> go
3> exit

This would assume that the application is using sql users/roles for auth but this is not very common (you can check by exec sp_helplogin & sp_help from a sql console, if you see user or login metasyssysagent you're in "luck"). Since typically an application will store credentials within its own store irrespective of SQL you need to find where the application is storing these. There are a couple ways to do this by either using SQL's or third-party tools and management functions to map out the tables completely. Another "simpler" approach would be to home the application to a remote DB either physically or virtualy and capture the queries passed or sp's called assuming you're not using a secure connection (which is still possible depending on the OS and packet sniffer but potentially more complicated).

You'd also need to know what, if any, obfuscation the application or SP may apply to strings like passwords and/or usernames before passing them to the DB engine to be written. In other words just because your password is "xyz" doesn't mean that the application or your browser is passing "xyz" to the database or application respectively to be either stored or hashed and stored. In the case of web applications this is sometimes handled by client side scripts (not really a good idea) which makes de-obfuscation "easier". If the data is not stored in plaintext or obfuscated by some known predictable means simply altering the password field either directly, through SQL's sp_password/alter login functions, or an sp created by your app would render the account unusable.

Doing most of the above could be viewed as reverse engineering and as such is typically not allowed per license agreements.

The problem is that if a default "backdoor" account was known or there was a simple list of commands that would do what the OP needs it would be a violation of the site's rules since that would in all likelihood "cause damage" since you'd basically be telling everyone how to gain unauthorized access.

I'd agree with Lambo; unless you really want to recover that account it's going to be easier to just blow it away and reinstall.


You can tell it's very slow at the office today
Regards,
D1G