We are doing our first tests with EM Server 5.8.2. We only use Active Directory Authentication.
In the afternoon I tested the authentication with someone in parallel. I have privileges, he has not.
Something weird happened. On my side everything was good : my login was displayed at the upper right corner. But on my colleague's side, it was strange => he had my access and the login displayed was mine, although he should had no access at all.
I can not replicate it. We were doing the test at the same time. I think you may find in the code something wrong. It must be about the session management maybe. I see no reason why he would be able to log as myself. It was really a big security issue.
Edit : I'm interested to know what is happening when we click on "keep me signed in". This can be related to this option.
Hi
We will definitely review all possible scenarios.
Could you please provide more details about how the simultaneous login was carried out?
For example, did you use two different computers? Were there different AD user accounts on those computers?
Did you or a colleague enter the username and password for an AD account?
Also, please check the user.session.started events in the journal database for the relevant time period. The initiator_detail field will show the AD user account name, and initiator_ip_addr will show the client’s IP address.
If that option is enabled, the active session remains valid even after the server restarts.
UPD-1
Could you explain in more detail why you said “although he should have had no access at all”?
For example, did he not have an EasyMorph Server account at all? Was his account blocked? Or did he have an account but no assigned roles? Was his account created automatically when he logged into the EasyMorph Server?
It must be about the session management maybe.
Let me clarify: on the server side, the session token is stored as a hashed value, while the client still sends the unencrypted/unhashed (original) session token. Whenever the server needs to identify the user, it hashes the token that the client sends and then searches for that hash. Because the server never stores the original token value, it’s impossible for the server to assign the same session to two different clients.
He was trying easymorph server for the first time and he was not declared at all on the server : no account, no role. He is using a different computer, with different IP and different AD login, nothing related with my account/computer.
So on one side I was connected with all my privileges, and on the other side he was supposed to have no access at all, the perfect unknown. And he showed his screen to me : my login was displayed. On our side we are going to check if it comes from our architecture.
Edit : it's replicated with another user, completely unknow by the server also. He could see my login. Note that I use the "keep me signed in"' option. Also the user could see very quickly a red banner at the top of the screen but it immediately disappeared. We could not see if there was a message. Note also that the bug was short : after one minute my colleague could not replicate the issue.
Edit2 : If I remember well, the unknown user had not my privileges, it was only the display of the login that was false. So I guess the problem is on the display of the login in the upper right corner. The sessions may be well managed as you said earlier.
Edit3 : I was also able to log and see in the upper right corner the login of my colleague, so the extact opposite situation. I really think there's a bug in the display of the current connected guy. But my privileges are applied. It's just a display bug.
We are looking into the code and reviewing different scenarios to figure out why you are experiencing this issue.
it's replicated with another user, completely unknow by the server also. He could see my login.
Please note that in the top-right corner, the server can display either the userLogin or the Name (if it is set). The Name takes precedence over the userLogin. You can change both Name and userLogin in the Users section. Check that the correct values are set in the Users section.
Note also that the bug was short : after one minute my colleague could not replicate the issue.
Could you please tell us more about what changed during that minute?
Did the displayed name change to the correct value on its own?
Did the user close the session?
I was also able to log and see in the upper right corner the login of my colleague, so the extact opposite situation. I really think there's a bug in the display of the current connected guy...But my privileges are applied
Could you please clarify whether this issue occurred right after logging in, or if it happened at some point later on during your session?
How long was the incorrect name on display?
Also, how have you confirmed that the permissions were set correctly during this time?
Also the user could see very quickly a red banner at the top of the screen but it immediately disappeared. We could not see if there was a message.
This can happen if the user is already logged in.
Please double-check that your browser profiles are not syncing across multiple devices or users, as that could cause this unexpected behavior.
Filter the session start events (user.session.started) so that only those matching your IP address (initiator_ip_addr) are returned.
Review the initiator_detail field during the time period (the timestamp field) when you observed the server displaying a username that wasn’t yours.
Check if there are any rows in the table that list a different username during this time.
Below is a snippet of the relevant SQL query:
SELECT
*
FROM "main"."em_server_journal_events"
WHERE "event_name" = 'user.session.started'
AND "initiator_ip_addr" = '10.20.30.50'
ORDER BY
"timestamp" DESC
Our architecture is special. We don't connect to the server directly. In this environment we have One Load Balancer => One web front solution => One Load Balancer => EM Server. So your query will not work because the "initiator ip" is always the Load Balancer, not our IP.
Is the display of the user connected based on the property initiator_ip_addr ? I hope not because in our case this will not work.
Is the display of the user connected based on the property initiator_ip_addr ? I hope not because in our case this will not work.
Certainly not.
I just meant that using that method would be the easiest way to see which specific Active Directory user started the session.
After all, when working with Active Directory, EMS completely depends on the information it receives from the domain infrastructure.
In this environment we have One Load Balancer => One web front solution => One Load Balancer => EM Server.
So, if I understand correctly, this same infrastructure has been in use for a while now.In other words, no changes were made that could affect the NTLM challenge or any specific traffic routing scenarios?
UPD
When NTLM is used behind multiple load balancers (or even one load balancer that’s incorrectly configured), there is a risk of “challenge/response mismatch” that could cause the wrong user session to be associated with a request.
I've just confirmed that the NTLM challenge requires sticky sessions on the load balancer. Have you already configured them?
We have experts who are used to setting up this kind of architecture with load balancers but I will ask them to double check. In our first architecture we had load balancer => EM Server which was doing very well. This architecture is different : LB => Web server => LB => EM Server. Maybe it's not compatible with Easymorph ?
Edit : Note that if it was a NTLM issue, the user who saw my login on the top right corner would have had the same privileges as I have. But it was not the case : he could only see what he was supposed to see (default workspace). That's why I think it's more related to the display of the connected user.
All of the user’s session data — including display name, effective permissions (for each space and system), and the session’s expiration time — are stored together in one session object, which is associated with a session token. So far, we have not found a case where this object is built incorrectly, but we will carry out some additional checks.
This means that if you happen to see someone else’s display name, it is very likely that you are logged in under that person’s credentials.
Please ensure that the load balancer configuration is correct. If the NTLM challenge is misconfigured, it could cause sessions to be opened under someone else’s account.
To confirm, you’re currently using EMS 5.7 in a setup of [load balancer => EM Server], and that works correctly. But when you try EMS 5.8.2 with the architecture [LB => Web server => LB => EM Server], you encounter issues when signing in via Active Directory. Is that correct?
Finally we can easily replicate the issue : 2 users connected using AD authentication must click on "Sign In" several times during the same period. If they insist a bit, one will be connected as the other and vice versa.
At the beginning I thought it was only the display of the login but no : you really are connected as the other, with the privileges of the other. For example I am the only admin and I tested with another user : he could log as myself and he had all admin privileges.
Note that our achitecture does not seem to be problematic : it 's used in a lot of other solutions AND we are not able to replicate the issue in EM Server 5.7. So we are quite sure it's related to 5.8.
Note that we could replicate without checking the checkbox "Keep me signed in". It is really problematic.
It appears you haven't addressed the questions I asked in my last post.
To confirm, you’re currently using EMS 5.7 in a setup of [load balancer => EM Server], and that works correctly. But when you try EMS 5.8.2 with the architecture [LB => Web server => LB => EM Server], you encounter issues when signing in via Active Directory. Is that correct?
Please ensure that the load balancer configuration is correct. If the NTLM challenge is misconfigured, it could cause sessions to be opened under someone else’s account.
UPD
To put it another way, does the issue still happen when you connect directly to the server/WebUI instead of going through the load balancer?
FYI, we have replicated the configuration of our first platform (still in 5.7) with no web server in front of EM Server. It's working fine. So I guess we can say it's not coming from 5.8. I noticed that the web server was in HTTPS / 443 but the communication between the web server and EM Server was with port 6330. Don't know if it can explain. We get back to 443 everywhere, add the web server and see if it happens again.
Ok, it seems to come from the architecture LB => Web server => LB => EM Server. When we do LB => EM Server, no problem. I understand that you have a IIS component automatically installed.
May it come from this ? I mean if we put a web server in front of EM Server, what would be the ideal configuration to make it work ? Should we stop IIS service on EM Server in this case ?
I understand that you have a IIS component automatically installed.
As far as I know, we do not install any additional IIS components and do not use or support IIS for hosting. We do, however, rely on http.sys, which IIS also uses internally.
Right now, it’s difficult to give concrete configuration advice without knowing more about how your two load balancers are set up. Perhaps if you send a more detailed technical description to support, we can identify possible points of failure.
In any case, you’ll need to ensure that traffic is being routed correctly from the client to the final server. For NTLM challenges, your load balancer should have the appropriate sticky session configuration or other options enabled that guarantee NTLM works correctly. Sticky sessions typically rely on cookies, so make sure the necessary cookies are making it through the entire pipeline.
Can you tell me how cookies are managed on EM side ? For example when I connect to EM Server through Chrome, I see no cookie. How is it handled ? What is the ID used to identify one connected user ?
A session is established after a user successfully logs in. If the user has passed authentication (through credentials such as login/password, Active Directory, or RescueLogin) and has at least one type of resource access (for example, a space membership or administrative privileges), a session is created along with a session token. This session token is returned to the client, and an X-EasyMorph-Auth cookie containing the same token is also set. The server itself doesn’t keep the actual token, only its hash for later verification.
Each time the user’s browser makes a request to the site, it includes this cookie. In addition, every API request contains an X-EasyMorph-Auth header, and the server-side API uses the header’s content to link that request to the user’s specific session.
It’s important to note that no session is created for anonymous users, so no token is generated or sent from the server in that case. As a result, the browser does not include a session token when the user is anonymous. For each space, the anonymous user’s rights depend on the resource being accessed.
As shown in the Firefox screenshots, the cookie is passed along when the user is logged in.
It's always the same issue, we try to understand why we have an issue with a web server in front of EM and why not without. As one user can "steal" the identity of another, we thought this user could benefit from the cookie of the other. BUT the user who steal does not check the box "stay signed in". It logically means that this user generate a new cookie each time he connects. So it's difficult to think it's a cookie issue, except maybe if the web server in the middle replaces the cookie by another. Is there a way to know where the hashed cookies are stored on the EM Server ? At least we can compare the hash version with the hash version we have on our workstation browsers ?
I believe you may be focusing on the wrong area when looking for the cause. From what I understand, the issue arises when using Active Directory (NTLM) and one or more load balancers. The primary problem is that a misconfigured load balancer causes the NTLM challenge to fail, leading EMS to open a session for the wrong user.
Below is a short explanation of why this can happen.
NTLM (NT LAN Manager) is a connection-oriented challenge-response authentication protocol. Unlike stateless HTTP authentication schemes, NTLM authenticates an entire TCP connection rather than individual HTTP requests​. The NTLM handshake typically involves multiple HTTP request-response exchanges (at least 2–3 requests after an initial 401 challenge) to negotiate and validate credentials​. All steps of this handshake must occur on the same TCP connection so that the server can associate the final authenticated request with the original challenge​. Once the handshake succeeds, the underlying connection is marked as authenticated for that user.
In a load-balanced environment, this connection-oriented design poses challenges. Layer-7 (HTTP) load balancers usually treat each HTTP request independently (assuming HTTP is stateless) and may distribute requests across different backend servers or connections for efficiency​. If a load balancer directs different parts of the NTLM handshake to different servers, or breaks the single connection into multiple connections, the authentication will fail or restart.
Connection Reuse or Multiplexing Across Clients: Modern load balancers and proxies often reuse open backend server connections for multiple front-end clients to improve performance. If not configured carefully, this can cause user sessions to mix up. NTLM ties authentication to a TCP connection, so if a connection that was authenticated for User A is later reused for User B, the server will treat User B’s traffic as if it were authenticated as User A. This is a serious misidentification issue. It occurs when proxies “multiplex” or pool connections – effectively sharing an authenticated connection among different clients​.
In such cases, multiple users can end up browsing under the same account context, as noted by HAProxy’s author: using NTLM over proxies without proper tunneling can result in “multiple users browsing with the same account” if the proxy reuses connections​. An Nginx developer similarly warned that with a shared keepalive connection pool, “any authentication will basically authenticate arbitrary clients who happen to use the authenticated connection from the cache,” meaning one client can inadvertently assume another client’s authenticated session​. This misconfiguration is often triggered by enabling HTTP keep-alives or connection pooling on the load balancer without pinning each client to a unique backend connection.
These misconfigurations can lead not only to authentication failures but also the more alarming scenario of session misidentification, where one user’s credentials/session are erroneously applied to another user. Parallel login attempts are especially susceptible: if two users authenticate around the same time and the load balancer improperly intermixes their connections, User B might complete an NTLM handshake over a connection initiated by User A. The result is User B being treated as authenticated as User A, effectively logging in as the wrong user (a severe security breach). This typically happens when connection pooling is enabled and a previously authenticated TCP connection is pulled from the pool for a new user’s request​. Without safeguards, the server doesn’t realize the client on that connection has changed and continues under the old identity. Such edge cases are rare under correct configuration but have been observed as a direct consequence of connection reuse misconfigurations​.
To avoid the issues above, it’s critical to configure load balancers (and any proxies) with NTLM’s connection requirements in mind. Key best practices include:
Ensure Connection Persistence (No Shared Connections Between Clients): In addition to session affinity, the load balancer must not reuse server-side TCP connections for different clients when NTLM is used.
Use Network-Layer (Layer-4) Load Balancing if Possible: One robust solution is to avoid HTTP-level LB for NTLM traffic altogether. Using a TCP (layer 4) load balancer or a tunneling mode means the load balancer will not break or interfere with the TCP connection at all
Leverage NTLM-Specific Features or Modules: Some load balancers and proxies provide special support for NTLM
