User created multiple times

[Geert Bellekens]

There a new version (15.2.1557) available with some more fixes for this issue:

User Login length is now detected correctly during Project Transfers
Updated the default EA Schema to support longer Login Names

Geert

[Uffe]

According to the schema release notes, they've increased the size to 255. I still say that's probably insufficient, but it should be enough for most users so should make the problem occur less frequently. Near enough, good enough.

The client history doesn't mention the fact that there is a new version of the DBMS creation scripts, which you must use to set up a DBMS repository. The base projects have been updated, so if you update the client but not the DBMS creation scripts (which are, of course, a separate download), and then try to transfer a newly created file-based project to a DBMS project initialized with the old scripts, well who knows.

/Uffe

[Geert Bellekens]

According to the schema release notes, they've increased the size to 255. I still say that's probably insufficient, but it should be enough for most users so should make the problem occur less frequently. Near enough, good enough.

The client history doesn't mention the fact that there is a new version of the DBMS creation scripts, which you must use to set up a DBMS repository. The base projects have been updated, so if you update the client but not the DBMS creation scripts (which are, of course, a separate download), and then try to transfer a newly created file-based project to a DBMS project initialized with the old scripts, well who knows.

/Uffe

I'm guessing they need a bit more time to update the database creation scripts. If that is the case we should see updates to the DBMS creation scripts, and a new update script soon.

The other option is that they reverse the change and go back to the old Domain\userName
Although that already had the same problem to a lesser extend:

Max domain name = 15 character
Max userName = 20 characters

So Domain + "\" + UserName = 15 + 1 + 20 = 36 whereas the current field stores a maximum of 32 characters.

Geert
Geert

[Uffe]

No, the creation scripts have been updated. It's just not mentioned in the client release notes.
Didn't see any patch scripts, but I might have missed them.

The other option is that they reverse the change and go back to the old Domain\userName

I don't see how that's an option. EA can't decide what the domain controller returns.

/U

[Geert Bellekens]

No, the creation scripts have been updated. It's just not mentioned in the client release notes.
Didn't see any patch scripts, but I might have missed them.

Ah, I see. Good to know, thanks.

The other option is that they reverse the change and go back to the old Domain\userName

I don't see how that's an option. EA can't decide what the domain controller returns.

It's EA that chooses to either use the Domain\userName or the "emailaddress" style username.
If EA doesn't have your email address registered, but still the old Domain\userName, then you will be logged in anyway.
This is then mentioned in the system output like this:

Login: Windows user 'Geert Bellekens ([email protected])' is not a member of the model.
Login: Logged in as Windows user 'Geert Bellekens (DOMAIN\Geert.bellekens)'.

Geert

[Uffe]

The other option is that they reverse the change and go back to the old Domain\userName

I don't see how that's an option. EA can't decide what the domain controller returns.

It's EA that chooses to either use the Domain\userName or the "emailaddress" style username.

I don't think so.

If EA doesn't have your email address registered, but still the old Domain\userName, then you will be logged in anyway.
This is then mentioned in the system output like this:

Login: Windows user 'Geert Bellekens ([email protected])' is not a member of the model.
Login: Logged in as Windows user 'Geert Bellekens (DOMAIN\Geert.bellekens)'.

That would appear to be EA checking if the account in the Windows session is stored in t_secuser. If not, and if it is a UPN, it constructs a DLLN from the simple account name and tries that. This may have security implications, and once again it would be interesting to know exactly what the algorithm is here. (Keeping your authentication algorithm obscure is a frustration for IT staff and a godsend to hackers.)

But what I meant was that EA doesn't decide what the domain controller returns when you import the user in the first place. In this case, it appears that what's been imported is a DLLN, but the Windows session returns a UPN.

/Uffe

[Geert Bellekens]

Uffe,

The behavior changed when we upgraded from 15.1 to 15.2.
We didn't change anything else except that, and suddenly we see this new behavior with the email addresses.

I'm pretty sure if I go back to 15.1, EA uses the DOMAIN\Geert.bellekens again. (I can do a test next week to be 100% sure)

Geert

[Uffe]

Hello again,

The behavior changed when we upgraded from 15.1 to 15.2.
We didn't change anything else except that, and suddenly we see this new behavior with the email addresses.

It was in 15.2.1555. And they're User Principal Names, not e-mail addresses.

Other

• Active Directory integration improved:
• Importing Active Directory users now uses 'User Principal Name'
• Auto login will now attempt to match both 'User Principal Name' and legacy NetBIOS\SAMUsername formats
• New option added. 'Allow non-domain users (insecure)'. This is off by default when enabling security but existing models it will be on

So pretty much as I outlined. But since you're presumably logging into a pre-existing project, it's got DLLNs stored and so you get that message.

However, this also makes clear that EA does in fact choose whether to retrieve DLLNs or UPNs when importing users, and it has changed from DLLN to UPN. This is a good thing, but was clearly not executed with due care and consideration, which is why they had to rush the 1557 fix.

It would have been even better if they'd included an option to re-import users so they'd retain the old GUIDs but change t_secuser.UserLogin from DLLN to UPN. You can automate it, but if you want to do it right (which, you know, we're talking about security and accessibility here, so probably just as well to make the effort) it's a fair amount of work so some support would have been nice.


/Uffe

[Geert Bellekens]

Can you explain why the change is a good thing?
Is that because UPN can stay the same even if you change domain?

In my case, since I have the groups in EA linked to AD groups, I could simply release all user locks, and then delete all users.
They will be automatically recreated (with their UPN) the next time they open the model.

I'm just not sure if I should. After all, its working now as well.

Geert

[Uffe]

Hello,

Can you explain why the change is a good thing?
Is that because UPN can stay the same even if you change domain?

No, the UPN is linked to a domain. Different domain, different UPN.
But UPNs are more readable, and can be longer. They seem to be the preferred option when authenticating in Windows, although it is hard to tell for sure.

In my case, since I have the groups in EA linked to AD groups, I could simply release all user locks, and then delete all users.
They will be automatically recreated (with their UPN) the next time they open the model.
I'm just not sure if I should. After all, its working now as well.

I wouldn't. If you want to get rid of the message, I'd modify t_secusers. You never know what might be tied to the user GUID somewhere deep down in the schema.

/U

[Geert Bellekens]

We did our weekly project transfer this morning an got error:

Database target field for t_secuser.UserLogin is too small. target length 32, required 33

This is using version 15.2.1557. I was under the impression the main point of release 1557 was to resolve this problem.

At first sight it seems the database field in the EABase.eap(x) hasn't been enlarged after all.

Geert

[Uffe]

Hi again,


Not presuming to speak for Sparx or anything, but surely the schema change only applies to new projects?

I'd be surprised if they'd implemented an auto-update in the client. For one thing, the account that runs the client might not have permission to make those changes in the database (in a file project yes, but not in a DBMS).

So you'll have to make that change yourself if you need it.

In summary, 1555 changed what gets stored in t_secuser.UserLogin when importing users from AD. Notably, the newer format (UPN) requires longer strings, but the column length was left at 32. (This was too short before as well, but usually worked due to sheer luck.)
1556 added a fix so that when storing accounts in t_secuser, the actual length of .UserLogin is used in case you've increased the length of the column yourself.
1557 updated the schema so that projects created from then on would have the column extended to 255 characters.

But if you're working with a project created with any version of the client prior to 1557, you need to extend that column yourself.
Sparx have not published any scripts to help you do that, you simply have to know a) that you need to do it in the first place, and b) how to do it in your chosen DBMS.


/Uffe

[Geert Bellekens]

Hi Uffe,

I changed the UserLogin size in my database to nvarchar(255)
Since then we have a user with a UserLogin of 33 characters.

When we now try to do a project transfer from DBMS to .eap or .eapx I get this error.

When you do a project transfer EA creates a new .eap file based on the EABase.eap file in the program files folder, and I thought it was exactly this one that should have been updated.

I'm going to investigate a bit further on Wednesday (working for another client now)

Geert

[Geert Bellekens]

It's the weirdest thing.

I checked the EABase.eap, and the field t_secuser.UserLogin is varchar(255) alright.

So I guess there's somewhere another code that checks the size of the contents before transferring.
It appears that this check is based on a hardcoded set of contraints, and not on the size of the actual database fields.
And apparently, they forgot to adjust that check as well.

I'm not sure what the testing process for this change was, but it seems to not have covered the most basic scenario: transfer a project with a user that has a login larger than 32 characters.

My current workaround is to manually update the t_secuser and set back to the old DOMAIN\userID format

Geert

[Uffe]

Hi again,


I'm wondering about the project transfer.

When you do a project transfer EA creates a new .eap file based on the EABase.eap file in the program files folder, and I thought it was exactly this one that should have been updated.

Are you sure about this?
You do need a project, not just an empty database, to transfer into, but why should it first copy EABase to the target project and then copy the source project? Remember, the target is already a project (ie has all the EA tables) and will be clobbered with the data from the source. Copying the base project first is redundant.

Presumably also the transfer process doesn't copy the schema from the source to the target but simply clears all the tables in the target and then copies the data from the source.

If this is all correct, what you need to do is update the schema in both the source and the target before you transfer.
It's only if you've created the target project with 1557 that you don't need to update it before the transfer.


/Uffe