Access to EA with the AD account from outside (PCS?)

[Guillaume]

Hi,

I have a client that has access on 2 separate networks/Windows domains via separate laptops.
EA is hosted on a SQL DB on the 1st domain and users access it using their Active Directory session via ODBC.
Some users would like to be authenticated with their AD user account from the 2nd domain. We tried to manually enter the NNI + password but it doesn't work.
Is there a way to achieve this, bearing in mind that user locks exist so a user cannot have 2 accounts (one from the AD and an internal one).

Can we use the Pro Cloud Server to allow this? Would the IIS integration enable that (it's not 100% clear from the online doc https://www.sparxsystems.com.au/enterprise_architect_user_guide/15.2/model_repository/cloud_server_iis.html).

Thanks

[Geert Bellekens]

Guillaume,

AD accounts from different domains are different accounts.
Currently EA only support a [1]-[0..1] relation between an EA user and an AD account.
I don't think there is a way to allow windows authentication from two domains, and still have only one EA user.

You can't have your cake an eat it I'm afraid.

Geert

[Paolo F Cantoni]

Guillaume,

AD accounts from different domains are different accounts.
Currently EA only support a [1]-[0..1] relation between an EA user and an AD account.
I don't think there is a way to allow windows authentication from two domains, and still have only one EA user.

You can have your cake an eat it I'm afraid.

Geert

(my emphasis)
Hi Geert,  was that a typo?

The saying is "You CAN'T have your cake and eat it, too"

Paolo

[Geert Bellekens]

Guillaume,

AD accounts from different domains are different accounts.
Currently EA only support a [1]-[0..1] relation between an EA user and an AD account.
I don't think there is a way to allow windows authentication from two domains, and still have only one EA user.

You can have your cake an eat it I'm afraid.

Geert

(my emphasis)
Hi Geert,  was that a typo?

The saying is "You CAN'T have your cake and eat it, too"

Paolo

Yep, a typo; fixed it

Geert

[Uffe]

Hello,


This looked like an interesting one, so I did a bit of a dive.

Strap in.

AD accounts from different domains are different accounts.

True, as far as it goes.

Currently EA only support a [1]-[0..1] relation between an EA user and an AD account.

I'm not sure this entirely holds up.

An EA project user account (henceforth "project account") is stored in t_secuser, with a GUID in .UserID and the account name in .UserLogin. (Also .FirstName, .Surname, .Department and .Password; I don't know what this is used for in AD-linked accounts but there is something there.)

In the case of an AD-linked project account, .UserLogin is on the form DOMAIN\UserName; this is what Microsoft refers to as a "down-level logon name".

But there is no relationship between a project account and an AD account as such. There is nothing in t_secuser that specifies that this account is AD-linked; that is a policy on the project level (stored in t_secpolicies.WindowsAuthentication).

I'm not pointing this out to nitpick. Well, not only. There is a point coming.

I don't think there is a way to allow windows authentication from two domains, and still have only one EA user.

No, but there might be a hack to make it look like there is.

I mentioned t_secpolicies above. Well, one thing conspicuously absent from that illustrious table is any mention of the domain. The domain is instead included in t_secuser.UserLogin. At the same time, it is perfectly possible for a project to feature a mix of AD-linked and non-AD-linked accounts; for instance, you might want to retain the default non-AD-linked "admin" account just in case.

What does this tell you?

It tells me that EA checks whether a project account is a down-level logon name or not. If not, it requires a password to authenticate, but if it is, it contacts the controller for the domain to authenticate.

The thing is, since the domain name isn't in t_secpolicies, it's altogether possible that EA could handle a situation where different project accounts are linked to different domains. And there's nothing stopping two project accounts from having the same .FirstName, .Surname and .Department.

So provided the project admin can access the project from machines in two domains (not necessarily a single machine connected to both at the same time), it should be possible to import the same person's account details from both.

If this works, there will then be two rows in t_secuser with the same .FirstName and .Surname, but different .UserID and different UserLogin.
The project accounts would not *be* the same, but the .UserID and .UserLogin aren't very visible in the GUI so they'd essentially *look* the same.

Of course, the two accounts could end up in different groups if you're not careful -- or perhaps you'd actually like them to be.
User locks are connected to project accounts, so a person could not lock a package using one account and unlock it with the other.
If you're using group-based authentication for the underlying database, and please don't tell me you're not, you'd need to manage that as well. This might be the hard part.

But based on what I can see in the database schema I can find no reason why you couldn't have project accounts linked to different domains, and have EA automatically validate credentials with the correct domain controller for each user.
And if that's possible, then two accounts in different domains can be associated with the same person.

Yummm, that's good cake. Which I still haven't eaten.


/Uffe

[Geert Bellekens]

Uffe,

I agree that you probably have AD users from different AD domains your repository, and have them authenticate automatically, but they indeed would still be different user, that happen to have the same firstname/lastname.
In this case Guillaume explictly mentioned the user locks, so this approach wouldn't be very useful in his scenario.

Geert

[Sunshine]

We had two AD domains, Production and Development. Some users resided in production and some in development. Where users had accounts in both we did indeed need to add both of the dev and prod AD accounts into Sparx EA. A pain to manage. We had to set up user groups in both domains to provide access to the SQL Server which was located in Dev. Figuring out which ports to open in the firewall between the two networks was painful and time consuming.

[Uffe]

We had two AD domains, Production and Development. Some users resided in production and some in development.

That's... hm.

Where users had accounts in both we did indeed need to add both of the dev and prod AD accounts into Sparx EA. A pain to manage. We had to set up user groups in both domains to provide access to the SQL Server which was located in Dev. Figuring out which ports to open in the firewall between the two networks was painful and time consuming.

But interesting to have it confirmed that a single project can indeed authenticate users from multiple domains. The documentation is pretty reticent on the subject.

@Sparx: when I rant about EA's poor security and how it isn't ready for the enterprise, this is what I'm talking about. You need to document clearly exactly how authentication works, not from the perspective of a barely-IT-literate modeller working in EA, but from the perspective of the enterprise IT professional who needs to know how to integrate this tool into their domain.

/Uffe

[Sunshine]

We had two AD domains, Production and Development. Some users resided in production and some in development.

That's... hm.

Yeah I know. Inherited that set up so wasn't my choice. However have recently moved all users to Production now so all good.

[Paolo F Cantoni]

More on this...  When we add a new user as AD-Linked, instead of getting <domain>\User we got the user's email address.  Unfortunately, it breaks the 40 character barrier in t_secuser.UserID and consequently, he CAN'T Log in!

This needs to be fixed!  If you're going to use email address, 40 chars are NOT enough!

Paolo

[Uffe]

Hello,

More on this...  When we add a new user as AD-Linked, instead of getting <domain>\User we got the user's email address.  Unfortunately, it breaks the 40 character barrier in t_secuser.UserID and consequently, he CAN'T Log in!

Strictly speaking, and I know you don't mind speaking strictly, it's not an e-mail address but a user name in User Principal Name format, as opposed to the Domain\User style, aka Down-Level Logon Name. UPN user names are on the same form as e-mail addresses, but they aren't the same thing.

This needs to be fixed!  If you're going to use email address, 40 chars are NOT enough!

No indeed. I'd set it to no less than 360 and would recommend you go to 512 or something. This isn't something that needs to be hard-optimized in the schema -- it's not referenced often and there aren't typically thousands of users in a project -- and you don't want to have to deal with it more than once.


/Uffe

[Uffe]

For future reference, I should also add that it's not the 40-character limit of t_secuser.UserID that gets broken, but the 32-character limit of t_secuser.UserLogin.

.UserID holds a GUID. That's fine in a 40-character space, it's a GUID and 40 characters is what's used for GUID columns throughout the EA schema. The GUID is the in-project identity of the user, it's nothing to do with anything external.
If you're using Domain or OpenID authentication, the external user name is stored in .UserLogin. That's what breaks, and since it's only 32 characters that's hardly surprising.

More discussions on this particular topic in this thread.

/U

[Paolo F Cantoni]

Hello,

More on this...  When we add a new user as AD-Linked, instead of getting <domain>\User we got the user's email address.  Unfortunately, it breaks the 40 character barrier in t_secuser.UserID and consequently, he CAN'T Log in!

Strictly speaking, and I know you don't mind speaking strictly, it's not an e-mail address but a user name in User Principal Name format, as opposed to the Domain\User style, aka Down-Level Logon Name. UPN user names are on the same form as e-mail addresses, but they aren't the same thing.

This needs to be fixed!  If you're going to use email address, 40 chars are NOT enough!

No indeed. I'd set it to no less than 360 and would recommend you go to 512 or something. This isn't something that needs to be hard-optimized in the schema -- it's not referenced often and there aren't typically thousands of users in a project -- and you don't want to have to deal with it more than once.


/Uffe

(my emphasis)
Learn something new every day...  (I'm just aData Architectect, not an infrastructure specialist...  )

Paolo