Login in issues using windows log in.

[Fefceac]

Hi guys,

I encounter a problem and I do not posses the knowledge to surpass it. We are using EA with Pro Cloud Server and two repositories one older on Oracle SQL and a new one on PostgreSql. We use Windows authentication on both repos but on the new one some users cannot login using the domain credentials. They get a pop up requiring user and password and after introducing the domain user and password a incorrect user/password massage is shown. the users are added in users and have assigned groups, also they can log in in the old repo.  Also the system output panel displays an additionl login message "login: Windows user xxxx\john.doe is not a member of the model."

I've removed the users from EA, they get deleted from t_secuser and try adding them manually or whit import from AD with no success.

Can you help me get out of this?

[Modesto Vega]

Have you enabled model security and assign AD users the relevant permissions?

[Fefceac]

Hi,

Enable security is done as it is mandatory in order do define groups and add users.
Can you provide more details on the part with the AD permission?

[Modesto Vega]

You need to import the AD users and/or user groups and assign them permissions to perform different operations on the model.

Please see https://sparxsystems.com/enterprise_architect_user_guide/15.2/modeling/managingusers.html and https://sparxsystems.com/enterprise_architect_user_guide/15.2/modeling/managinggroups.html.

We used AD groups with some success.


Edit: I forgot to say that the out-of-the-box Sparx groups are linked to AD groups.

[Fefceac]

I believe that I've performed this steps correctly. I've created groups in EA without AD link and then in users I've used import to get AD users for each group. The problem is that some users in the same group can log in and others can not.  The users were imported at the same time. I'm stuck.

[Modesto Vega]

Have you compared the actual AD group membership against what Sparx "thinks" is the group membership? I think that Sparx does not automatically synchronises the group synchronising requires pressing the Sync button in the Security Groups window.

If this is not the problem, I understand from your last post that you are using multiple groups. Have you checked if all users in a single group can login? Have you isolated if there is a problem with a specific group or it affects all groups.

[Fefceac]

Groups are not link to AD (the check box is not checked in groups) only the users are imported and have Accept windows login enabled. In some cases some but not all user groups can log in, for some other groups all users can log in.

[Fefceac]

The same config with groups defined in EA and users imported from AD is on both repos all user can log in on one, and some cannot on the second.

[Geert Bellekens]

The same config with groups defined in EA and users imported from AD is on both repos all user can log in on one, and some cannot on the second.

What error are you getting? There's a good chance they don't have access to the actual database (on the database level)
In those cases EA will present you with "Enter password" box (without user)

Geert

[Fefceac]

Thank you Geert, can you take the time and guide me on where to check this permissions. I suspected this might be the case due to the error about user not having access to the model.

[Geert Bellekens]

Thank you Geert, can you take the time and guide me on where to check this permissions. I suspected this might be the case due to the error about user not having access to the model.

Ask your database people
I'm not sure if that is the case though, since you still haven't told us exactly what is happening.

Geert

[Modesto Vega]

If the connection between Sparx EA - i.e., the desktop client - is via ProCloud Server, my understanding is that the service account running the ProCloud Server windows server needs to have permissions on the database.

If the connection between Sparx EA is direct to the database, each windows user must have permissions on the database. Your DBAs should be able to tell you who has permissions to the database.

Having said this you need to start from basics, are your users connecting to a database or the ProCloud Server endpoint? A ProCloud Server endpoint looks like http://[servername], https://[servername].[domain name] with or without a port.

[Fefceac]

Hi,

Users connect through Pro Cloud (pro cloud is connected with technical user to the DB).

the error in system output is: "login: Windows user xxxx\john.doe is not a member of the model." followed by the login window

[Geert Bellekens]

So it's not a database permissions issue.

Have you updated the schema on both databases to the latest version?
In a previous version there was an issue when user names got too long. (max 32 characters I believe)
So it didn't work for users with long names

So if one database is still using the old schema, you might have the issue there, where the other one doesn't.

EA also has changed the userID it uses to connect to the database.
In the more recent versions it's [email protected] and no longer MyCompany\John.Doe
This change made the problem with the limited usernames a bit worse, since something like jan.hendrik-willem.vandercruisen-versteeg@mycompanyWithaLongName.com  is easily longer than 32 characters.

Geert

[Modesto Vega]

In addition, I suggest you do the following: change the logging level of ProCloud Server to TRACE, restart the service, and look for any errors in the ProCloud Server logs that may shed further information on the problem.

[SNIP]
EA also has changed the userID it uses to connect to the database.
In the more recent versions it's [email protected] and no longer MyCompany\John.Doe
This change made the problem with the limited usernames a bit worse, since something like jan.hendrik-willem.vandercruisen-versteeg@mycompanyWithaLongName.com  is easily longer than 32 characters.

I am not sure how well ProCloud Server adheres to this. Our logs show plenty of successful uses of user names with the e-mail format but were also seeing quite a few failed attempts to use the old format [Domain]\[User Name]. We cannot trace where the failed attempts to use the old format are coming from, we have an unresolved support case regarding this very same issue.