Skip to main content

I'm trying to deploy an application to Azure using App Services and a Azure SQL database. We want users to log in with their e-mail address, such as user@company.com and john@doe.com both on the same application / database. The user id in IAM is an e-mail address and the users in the SQL database are also.

Only when trying to log in, the login with the e-mail address user@company.com fails:

Cannot open server “company.com” requested by the login. The login failed.

When I add the database server address to the e-mail address (user@company.com@my-database.database.windows.net), then the login succeeds.

How can I fix this that the user doesn't have to add the database server address?

Please note, when connecting with this user via SQL Server Studio Management Tools it also requires the postfix of the database server address in the user name, despite the fact that the user / login in the database is only iuser@company.com].

Hi René,

It's enough to provide the user an email address in IAM, while its usr_id is something else. Before the user logged in the GUI requests user information to IAM to know which user its working with. Providing the email address and the correct password will also allow the user to login.

We have to investigate why the strange behaviour you subscribe occurs.It seems like the part behind the '@’ is interpreted different from what we would expect.

Regards, Erik

The weird thing is I would expect the connection initially would be established via the connection string provided in web.config, which is an non e-mail address.

https://office.thinkwisesoftware.com/docs/docs/deployment/web_gui.html#webconfig

But because the roles and rights assignment is done per user (and not on TsfGlobalUser), it's quite likely that the next connection is established via the user account (which is ok I guess).

In IAM we support different types of authentication. For type RDBMS we have to validate the users credentials against the RDBMS, which is probably the statement which is failing. The rest of the connections for queries the GUI fires will use the pooling credentials indeed. 

Maybe authentication type=IAM suites you better? You only have to register your users in IAM and they do not need to have a account on the database. Note: our Windows GUI doesn't support this type of authentication.

In IAM we support different types of authentication. For type RDBMS we have to validate the users credentials against the RDBMS, which is probably the statement which is failing. The rest of the connections for queries the GUI fires will use the pooling credentials indeed. 

Maybe authentication type=IAM suites you better? You only have to register your users in IAM and they do not need to have a account on the database. Note: our Windows GUI doesn't support this type of authentication.

Looks like I haven't payed enough attention during IAM training or haven't noticed it, this fixes it 🙂.

 

Reply


Terms & ConditionsCookie settings