v16.1 - Can't login as admin

[Paolo F Cantoni]

When you change the password of a local account in a repository, EA updated t_secuser and posts an entry in t_xref.  We changed the admin password - the ONLY local entry; the rest are AD imports.  And we can't log in as admin!

Everything appears OK, apart from the observation that the t_xref value is placed in the supplier field rather than the more usual description field.  What could be causing the problem?  Is there some "secret sauce"?

NOTE: This affects both 32-bit and 64-bit (and v15.2)

Reported,
Paolo

[Modesto Vega]

Looks like it could be a nasty bug. The fact that it is still not possible to map the repository admin account to an AD account or group is beyond me. The same applies to PCS by the way.

[Geert Bellekens]

The fact that it is still not possible to map the repository admin account to an AD account or group is beyond me. The same applies to PCS by the way.

I think that's a good thing.

In case the connection to AD fails for some reason, you still have a way to get into the model with the admin account.

We have an admin group, that has all the rights, and is linked to an AD group. The admin account is simply an emergency backdoor.

Geert

[Paolo F Cantoni]

Is anyone prepared to confirm the behaviour?  I suspect that the admin account won't work even if you haven't changed the password.

Paolo

[Geert Bellekens]

Is anyone prepared to confirm the behaviour?  I suspect that the admin account won't work even if you haven't changed the password.

Paolo

Just did a quick test with version 16.1.1622 on a .qea model.
I could change the password of the admin user without any problem (and I could change it back the the original password again as well)

Geert

[Eve]

The fact that it is still not possible to map the repository admin account to an AD account or group is beyond me. The same applies to PCS by the way.

I think that's a good thing.

In case the connection to AD fails for some reason, you still have a way to get into the model with the admin account.

We have an admin group, that has all the rights, and is linked to an AD group. The admin account is simply an emergency backdoor.

Geert

Exactly. You can still associate a given AD group with the Administrators group (or any the you've given permissions to) and have admin rights in an AD login. There needs to be a way to get into the model if something goes wrong with the AD logins.

[Paolo F Cantoni]

Is anyone prepared to confirm the behaviour?  I suspect that the admin account won't work even if you haven't changed the password.

Paolo

Just did a quick test with version 16.1.1622 on a .qea model.
I could change the password of the admin user without any problem (and I could change it back to the original password again as well)

Geert

Thanks, but any chance you could try it on a SQL Server model?  We don;t use .qea (or .qeax) models yet, and the problem occurs on our main SQL Server repository and the .eapx snapshots we take of it.


Paolo

[Geert Bellekens]

Same thing on SQL Server. Works as expected, without issues.

Geert

[Modesto Vega]

The fact that it is still not possible to map the repository admin account to an AD account or group is beyond me. The same applies to PCS by the way.

I think that's a good thing.

In case the connection to AD fails for some reason, you still have a way to get into the model with the admin account.

We have an admin group, that has all the rights, and is linked to an AD group. The admin account is simply an emergency backdoor.

Geert

Exactly. You can still associate a given AD group with the Administrators group (or any the you've given permissions to) and have admin rights in an AD login. There needs to be a way to get into the model if something goes wrong with the AD logins.

Not sure "emergency backdoor" are 2 words anybody working on cybersecurity wants to hear. In my opinion, it should be possible to disable the admin account. Also, since this is not an AD or OpenID account, it could be confusing to have the same Global options for this and other Sparx accounts.

[Geert Bellekens]

Not sure "emergency backdoor" are 2 words anybody working on cybersecurity wants to hear. In my opinion, it should be possible to disable the admin account. Also, since this is not an AD or OpenID account, it could be confusing to have the same Global options for this and other Sparx accounts.

Indeed, but on the other hand you could ask yourself, what are you really protecting here.

If you don't want anyone other than a certain AD group to be able to access the model, you can protect your database and/or PCS.

So it's only if you already have access to the database that we can access the model as admin.
Usually there are no real secrets in the model for users that have access anyway; and if they are real savvy, they can "hack" themselves in anyway once they have database access.

So it's more of a convenience backdoor than anything else.

I don't consider EA's internal user management as "security". It's unfortunately named that way, but it's more like "user management".
It doesn't really provide any real security. It merely protects us from accidents (e.g. users changing things they shouldn't have)

Geert

[Paolo F Cantoni]

Same thing on SQL Server. Works as expected, without issues.

Geert

Thanks,

Looks like I'll have to look deeper...

Paolo