LOGIN objects becoming corrupted?

[Carsten Schmitz]

True story:

We have two login objects. Let's call them FLAMINGO and WOODPECKER. Both had the same Windows account with the same password stored in them. Both worked that way for many, many years, and Jobs using them successfully ran as recent as January 6.

As of today, jobs using FLAMINGO still work. Jobs using WOODPECKER suddenly started saying:

U00063031 FT '743444217': Cannot log on as user 'PLUTONIUMFACTORY\manager'. Error: '1326 - The user name or password is incorrect.'.

(obviously, I changed the domain and user name in the recreation of the errror message above)

So it would appear that someone changed the password in WOODPECKER, right? Hm, but thing is, the last modification date on WOODPECKER is 2018 and no new versions have been created in Automic since. I re-entered the password into WOODPECKER and it started working again.

Do LOGIN objects occasionally corrupt their passwords? Anyone else seen this?

Best,
Carsten

------------------------------
I will not respond to PM asking for help unless there's an actual reason to keep the discussion off of the public forums.
------------------------------
​​

[Pete Wirfs]

Only vaguely do I remember something similar, but I brushed it aside as due to some other recent change made to the system, fixed the password, and went on.  I don't remember any of the specifics of the situation.  I think one time it occurred during a DR test?

I've always wondered if the password encryption formula might include other odd things that might tie it to a machine, a database version, network address, or some other such thing.

see table: OLC

------------------------------
Pete
------------------------------

[Carsten Schmitz]

​Cheers!

Yeah, I was looking at OLC hoping to be able to duplicate the BLOB with the password from one LOGIN object to a newly created one. Because while the working password was in the first LOGIN object, initially nobody in the company had the password in plain text. I know, I know, writing the Automic DB is forbidden and I didn't go through with it (people eventually found the password in an unexpected place), but I had to investigate the possibility because it was a very vital process and an emergency. OLC being comprised of Oracle BLOBs though, I couldn't figure out on the fly how to duplicate it into a new object. It won't let you "select from OLC where FLAMINGO into OLC where WOODPECKER", I think BLOB "insert into" needs more special sauce.

Either way, I shall now treat the possibility that Automic corrupts passwords as canon. There is really no other explaination :(

[Alain Moisy]

Possibility :

Login password field has been "enhanced" to support unlimited size for passwords. This makes a modification in the database structure and was normally cared by the migration process.

I have noticed that sometimes the fact that you open the login object, make no modification and close it has an impact on content after a migration. Something maybe due to the default size, default format or some other "default" setting for this field. If the login object wasn't opened since this change of structure, maybe it was the lucky "side effect" of the structure modification =-)

Regards.

Alain

[Carsten Schmitz]

Thanks Alain!

It wasn't migrated recently, but it's certainly possible someone opened it for the first time.

@David Ainsworth would it be possible to get a word from the developers if there is any hook on opening LOGIN objects that could explain this? Any code path that re-saves a password transparently to the user? I don't think filing a ticket with a question like this will get anywhere, but at the same time, this can be a matter of rather high impact. For us, for instance, that was certainly an emergency and at some point we expected that we'd have to reset a password used on 700 machines for various services.

Cheers all.
​​