Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Connection could not be established
#1
I need help to come around a problem.

ASG: V13.0.6888.1

MSSQL

1Year Subscription until March 31 2021



We have different levels of user accounts for different purposes in our company.

On my PC i'm logged in with my "basic user" but on servers i use my "administrator user".



If i open ASG as my "basic user" on my PC the "Login To..." window appear (Pic1).

here i have the option to chose a different user to log in to ASG with but that does not work.

If I uncheck the "Integrated" checkbox and enter my "administrator user" and press login i get the error message in Pic2.



If i instead open the ASG application as the "administrator user" and just press login (with integrated credentials) it works fine.



I wish to be able to run ASG as my "basic user" and use my "administrator user" to login to ASG(database). Is this possible? Is there any drawbacks?




[Image: RnUOsmp]
[Image: pPzX9yD]
pics


Attached Files Thumbnail(s)
       
Reply
#2
Hi, could you please reedit your post and remove the image part otherwise I could do it for you..it's not usable for us and takes too much place. Just attach the images via button.. this should create t small icons . Thanks and best regards,
Michael
best regards,
Michael -- michael.scholz@asg.com --
Reply
#3
(16-02-2021, 01:27 PM)Michael Scholz Wrote: Hi, could you please reedit your post and remove the image part otherwise I could do it for you..it's not usable for us and takes too much place. Just attach the images via button.. this should create t small icons . Thanks and best regards,
Michael

Hi! Sorry I did not review the post after i posted it. in my editor it looked good. when i pressed edit post i could se the pictures again..
i did copy/past them in..

now i have attached them and used imgur
but i can't get your attach picture button to work.
Reply
#4
There are two different logins - the first one is the user that is used to login to the database (server/instance) - that is specified in your environment - you can choose between "Integrated Auth" and "internal database user" - if you choose "Integrated Auth" the Connection String for accessing the database will just have the "Integrated Auth" option - no user - so the user you are running when you start ASGRD is used for the connection to the database!

The login dialog is used after the connection to the database for internal ASGRD user mapping!

If you get the message that a connection can not be established - the user you are running (I think the environment is using Integrated Auth) does not have permission on the SQL instance!
Regards/Gruss
Oliver
Reply
#5
Hi now i have it working. Thanx for the info!

What is the lowest Database permission the user account needs to be able to start the application?
Reply
#6
You can read the necessary permissions in the help

Working with environments=>Working in database mode=>Necessary permissions on SQL server instance
Regards/Gruss
Oliver
Reply
#7
Some of my users still have problems.. really strange ones.

they get the error message: 

"Log on not possible
login failed. Please verify username and password!
LogonUser failed with error code 1385, msg: (the following part is translated from swedish) loginerror:
The user have not been granted requested logintype on this computer."

(this is not the same as wrong username and password.. it does not have the same error code or information text)


If they start ASG via citrix where they start the application with there admin account it works. there admin user have permission to access the database.

if they try it from there PC where they open the ASG application with useraccounts and de-select "integrated" and enter their admin account they get the error.

If they open the ASG application with their user accounts and de-select "integrated" and I enter my admin account i can login..

my conclusion: the admin accounts have access, the user accounts have access, no firewall problem and no wrong usernames or passwords.


Attached Files Thumbnail(s)
   
Reply
#8
I tried to find the reason - and the error is thrown by the logon process of the SQL Server - if you just search for the error code or for "LogonUser failed with error code 1385" you will find some solutions how to fix it - seems to happen after users were migrated from one domain to another :-)
Regards/Gruss
Oliver
Reply
#9
https://www.sqlservercentral.com/forums/...5%E2%80%99
Regards/Gruss
Oliver
Reply
#10
I don't think that that is the case. we have not made any changes in our domain name..

I found out that if i made the admin account administrator on the PC it works. But that is not a solution for us the reason that we don't use "integrated" account is that we do not wish to login to PCs or launch apps with our admin accounts. 

What permissions on the local client is required for this to work?
Reply
#11
I don't think that there are any permissions on the client required...

I try to explain again how it works - to connect to a database you need a connection string - this connection string can use "Integrated Auth" that means that the User who is logged on to the client will be used to authenticate against the database server - or you can specify a user (internal Sql user) to authenticate against the database server - but this has nothing to do with the Login-User to ASGRD - this user is not used for the connection string! If I think about it, should be also possible, but currently not implemented.
Regards/Gruss
Oliver
Reply
#12
(04-03-2021, 03:42 PM)DevOma Wrote: I don't think that there are any permissions on the client required...

I try to explain again how it works - to connect to a database you need a connection string - this connection string can use "Integrated Auth" that means that the User who is logged on to the client will be used to authenticate against the database server - or you can specify a user (internal Sql user) to authenticate against the database server - but this has nothing to do with the Login-User to ASGRD - this user is not used for the connection string! If I think about it, should be also possible, but currently not implemented.

I have an awsome guy working here. his name is John Wick and he has two accounts.
Both JohnWick1 and AdmJohnWick1 have access to the database. but only AdmJohnWick1 have permissions inside ASG.

If John logg in to a pc with AdmJohnWick1 and open ASG application and make a login to the ASG database with the AdmJohnWic1 it Works.

If he log in to a pc with JohnWick1 and open ASG (RunAs) as AdmJohnWick1 and make a login to the ASG database with the AdmJohnWic1 it Works.

If he log in to a pc with JohnWick1 and open ASG (as JohnWick1) and make a login to the ASG database with the AdmJohnWic1 he get the error "1385"

If I add the AdmJohnWick1 users as "Local Administrator" on the PC and he log in to a pc with JohnWick1 and open ASG (as JohnWick1) and make a login to the ASG database with the AdmJohnWic1 it works.


i cant see how this can be anything else than a local permissions problem.
could it be that the ASG needs to be able to "run as a service" or "run as a batch" as the user AdmJohnWic1
do you have any other ideas?

/Martin

Ps. our users or admins are never local administrators on clients.
Reply
#13
Hi Martin,

sorry for my two cents here : the user doesn't need local admin rights - just ASG-RD permissions via security group if permissions are activated and database access ( if configured in environment) . But I miss the info that the user(s) (JohnWick1) have been granted access to login to ASG-RD by assigning them to their (ASG-RD) security group. Maybe I have missed it in the thread then forget my comment - but if not maybe it helps ;-)
Best regards,
Michael
best regards,
Michael -- michael.scholz@asg.com --
Reply
#14
Martin,

can you please try to use the Environment Manager - there is a "Test Connection" button - perhaps you get some more detailed results if you use this test button - and it will be easier to "play" with different settings...

I have no more idea - but I know it is the SQL Server that denies access to the database! But don't know why...
Regards/Gruss
Oliver
Reply
#15
(09-03-2021, 03:26 PM)DevOma Wrote: Martin,

can you please try to use the Environment Manager - there is a "Test Connection" button - perhaps you get some more detailed results if you use this test button - and it will be easier to "play" with different settings...

I have no more idea - but I know it is the SQL Server that denies access to the database! But don't know why...

I will test different settings with the "Test Connection" button. Good idea!
I will also test with adding AdmJohnWick1 as "logon as Batch" & "Logon as Service" permissions.
i'l write here if there is any changes or not. Wink

/Martin
Reply
#16
(09-03-2021, 05:47 PM)martinrjl Wrote:
(09-03-2021, 03:26 PM)DevOma Wrote: Martin,

can you please try to use the Environment Manager - there is a "Test Connection" button - perhaps you get some more detailed results if you use this test button - and it will be easier to "play" with different settings...

I have no more idea - but I know it is the SQL Server that denies access to the database! But don't know why...

I will test different settings with the "Test Connection" button. Good idea!
I will also test with adding AdmJohnWick1 as "logon as Batch" & "Logon as Service" permissions.
i'l write here if there is any changes or not. Wink

/Martin

I have tested this on several users same result each time. as soon as i add the "domain\AdmJohnWick1" to the local administrator group the user can start ASG. (this is only a workaround not a solution)

I have also reversed the workaround and removed the admin access for "domain\AdmJohnWick1" on my PC and then i also get the error.

I have tested run as batch and run as a service permission without success.

If i use the "Test Connection" button as integrated i get success, as AdmJohnWick1 "Connection check Failed", domain\AdmJohnWick01 "Connection check Failed"

I have tested to add "domain\ADMJohnWick1" to the local group "remote desktop users" witch also solved the problem. this means that its not necessary to use the local administrator group. but still not 100% good.
i will try to make this work with this group.. if you have any ideas to why this is needed please give me some more info.

My end goal is to protect the PC from users with admin privileges and not leave any cached (hashed) credentials on any PC with our admin accounts.

/Martin
Reply
#17
I have no idea - it makes no sense to add a user to a local group to have remote access on the sql server - I do not understand that (same as you!)! Perhaps any firewall rule that is different for the local groups?
Regards/Gruss
Oliver
Reply
#18
(17-03-2021, 01:31 PM)DevOma Wrote: I have no idea - it makes no sense to add a user to a local group to have remote access on the sql server - I do not understand that (same as you!)! Perhaps any firewall rule that is different for the local groups?

No firewall involved what i can see. I have tried with the windows firewall disabled. same problem.
our other firewall don't care about usernames or windows permissions or any thing like that.

if i remove the "remote desktop permission" the moment after i click "Login" i can be logged in to ASG and work without problem. It's just in the connection moment i need the permission.+

btw the "remote desktop permission" is instant so i can try login with several fails. add the "remote desktop permission" and it works instant. if i remove the permission and restart ASG the problem is there.

I can have several instances of ASG working and remove the permission, they will not be affected but if i try to open a new instance it wont work.

We will go with this (remote desktop permission) as our final solution. we will add it with a GPO or a SCCM-package its not great but its not worth more of our time. If you have any more ideas we are ready to try them out!

/Martin
Reply
#19
Sorry, currently we are in the final development cycle for the version 2021 - after that main release we can try again to find a better solution or just the reason for it... Currently dev is very busy :-)
Regards/Gruss
Oliver
Reply
#20
(30-03-2021, 02:25 PM)DevOma Wrote: Sorry, currently we are in the final development cycle for the version 2021 - after that main release we can try again to find a better solution or just the reason for it... Currently dev is very busy :-)


Is there any chans that you can provide a Beta for the new version? If the new version is a solution for this problem or my other case regarding slow citrix performance then i can stop trubleshooting. Wink
Reply




Users browsing this thread: 1 Guest(s)