Unidentified user when moving the EAP file from disk

[Mauricio Moya (Arquesoft)]

I have a weird case: an EAP file in EA 14 with security enabled and integrated with windows authentication.

If the EAP opened in the original folder (a local folder in a PC), it opens the file and does autologin because the windows user matches a user in the model (the user in the model is defined as DOMAIN\USERNAME).

If I move the EAP file (by copy-pasting the file (previously closed in order to avoid conflict with temp file generated)) to another folder in the same hard disk, the file opens and autologin normally as expected.

BUT if I move the EAP file to a folder in a different hard disk (using the same methodology), when EA opens the file, it ask for the username and password, which means it does not recognize the windows user as a user in the model.

The same happens when moving the file to a network folder or uploading and then downloading to sharepoint (via web, not using a local folder for sharepoint).

The temporal solution for me was to assign passwords to each users in order they can login when prompted, but autologin doesn't work when the file has been moved from hard disk.

Why?

Any ideas?

[Geert Bellekens]

Yes, that is a known issue/feature.

I believe disabling/enabling windows authentication is enough to make it work again after moving the file.

Geert

PS. Of course the only "real" solution is to use a database instead of an .eap(x) file.

[Paolo F Cantoni]

I think this is a Windows File System issue - it's related to the bit that determines whether you get the "this file may be harmful" message.  When you move files to a different drive letter or URL, windows assumes it is potentially harmful and places restrictions on the file by setting the bit.

The problem isn't directly related to the repository type since if you moved the SQL Server DB files in the same way, you'd probably get the same (or equivalent effect).

Paolo

[Glassboy]

I think this is a Windows File System issue - it's related to the bit that determines whether you get the "this file may be harmful" message.  When you move files to a different drive letter or URL, windows assumes it is potentially harmful and places restrictions on the file by setting the bit.

IIRC that's in an Alternate Data Stream (https://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_(ADS)) not a bit in the file header.

[Paolo F Cantoni]

Yes, that is a known issue/feature.

I believe disabling/enabling windows authentication is enough to make it work again after moving the file.

Geert

PS. Of course, the only "real" solution is to use a database instead of an .eap(x) file.

It also seems to occur when you transfer a project from a Server Based DBMS to an .eapx file.  We don't have user account control on this machine so I can't use the above method to fix it.  Does anybody have a mechanism to restore autologin?

It didn't really bother me before (we'd just use a static login - not AD synchronised), but now our usage of such .eapx snapshots will be changing and we'll need it (autologin).

TIA,
Paolo

[Mauricio Moya (Arquesoft)]

@Paolo, I recommend you to:
1) open your previuous model (in the database, before transfer)
2) create a user with password
3) transfer again the model to the eapx file
4) login with your new user

[Paolo F Cantoni]

@Paolo, I recommend you to:
1) open your previous model (in the database, before transfer)
2) create a user with a password
3) transfer again the model to the eapx file
4) login with your new user

Thanks, Mauricio,

But I'm already doing that!  It wasn't a problem before, but it won't do for our future needs.  I really need autologin.

Paolo

[Eve]

This isn't what you want to hear, but you won't get auto login on a transferred file.

Windows Authentication is intentionally disabled by the process of a DB transfer.

[qwerty]

Hehe, lol. I was just stumbling over that last week. There SHOULD be a warning when doing such a transfer. Goes without saying?

q.

[Paolo F Cantoni]

This isn't what you want to hear, but you won't get auto-login on a transferred file.

Windows Authentication is intentionally disabled by the process of a DB transfer.

Hi Eve,

This was a secondary question I was going to ask for clarification.  Is the disablement by Sparx's action or as a consequence of the transfer process.  I have my guesses, but I prefer actual knowledge... 

Paolo

[Eve]

EA is checking that the source of the model is the same as what it was when the option was turned on.

[Paolo F Cantoni]

EA is checking that the source of the model is the same as what it was when the option was turned on.

Thanks for the quick response...  So if I turn it off and turn it on again, does that fix it?

That would be acceptable for us - as in the existing usages we don't really want autologin to work, but in the new ones we do and so we'd be comfortable with an additional step.

Paolo

[Eve]

Yes, I believe that will reset the option. So you need one user with simple credentials and admin rights.

[Paolo F Cantoni]

Yes, I believe that will reset the option. So you need one user with simple credentials and admin rights.

I've now confirmed this, but the process is a bit "clunky" - seems to require a couple of exits and re-entries.  Can you think of any reason why the process would not be amenable to us writing a script to restore autologin?

In any event, since a suitably configured user can both enable and disable User Security, it seems to me this should be an additional functionality (restoring autologin) on the User Security administration page.  As qwerty says, there should be an indication that autologin has been disabled and then an option to re-enable.

I'm happy to submit a feature request.

Paolo