I have an API that is hosting on IIS 7.5. The application pool is configured use a domain service account. Then, I grant the account full permission on the default site.
The API and the database are on different server.
I create a SQL Server login for the account and associate it with a user. The user is granted db_onwer to the database. SQL Server service is configured to run using that service account as well. However, The API can't connect to the database. The database log shows this error message "Login failed for user host\servername$. If host\servername$ is given access to the server, it would work fine. However, IT said no way.
Majority of the solutions that I have found online so far either gave permission to host\servername$ to the database or change the apppool to use network or local service, or use a username and password where the username is not a domain account user.
I have to use a domain name account, so I am struggling to find a solution.
There was an issue with the way the domain account was created. IT had to create another service account. Once I set up the app pool with the new server account, I had no issue.
Related
Is there an advantage in using a trusted connection vs a sql login for web application? Is there any pros/cons from one to another?
I usually use Windows Authentication, which is more secure, with a service account. If you are doing an internal application within your own domain and you want to authenticate your users to the database server, you will need to set up delegation on that service account along with the IIS and SQL services. If it is outward facing or you aren't concerned with authenticating users to the database, you simply need to give the relevant permissions to the service account login in SQL. In either case, assuming your webserver is IIS, you would change the web application to run under the service account. This will encrypt and store the credentials on the webserver.
The main reason windows authentication is more secure is it makes use of the Active Directory infrastructure to authenticate users using encrypted messages between the servers. With SQL Authentication the credentials are passed across the network. If you do use SQL Authentication, you should make sure to encrypt the connection string portion of your web config, as you would embed the credentials including the password.
I have installed an Azure MFA on our network to provide two form Id for our VPN. We are using the Azure MFA pay as you go option where users are added and charged as we add them to the server.
I have import the users from AD. Ninety percent of the users imported work file. I have both enabled an not enabled users listed on the server.
When I run a test from within the MFA server the authentication process works. The server will call the number I have listed and when I press the # key to accept the system returns that that use authenticated ok.
The ones I am have problems with will authenticate with I use the test button on MFA server, but when I try to use the same user to login to the VPN
I get this error
Pfauth failed for user 'CN=test#xxxx.com,CN=Users,DC=xxxx,DC=com' (distinguishedName format) from xxx.xxx.xxx.xxx. Call status: SKIPPED_NO_USER - "Couldn't match supplied username to a defined user".
Other users have no problem logging in.
I have tried to re-import the user, recreate the use manual in the MFA server nothing changes the results.
It looks to me that the error is that the MFA server does not recognize the server. Has anyone seen this problem or can direct me to thing to check.
It looks like you are either securing the VPN using LDAP, or are using RADIUS but doing the primary authentication using LDAP bind. After primary authentication is performed, the MFA Server needs to find the user in its data store to look up the phone number and auth method configured. It either uses Windows SIDs or LDAP unique identifiers to do that lookup. Take a look at Company Settings-->Username Resolution in the MFA Server. It is set to use Windows SIDs by default. Try changing that to use LDAP unique identifiers.
I have my sql server 2008 setup with mixed mode authentication. I went into sql server and added a new login and referenced an active directory user.
But it seems like all the windows authentication based stuff only ever works with whatever was used to login to the operating system. So I'm outside their domain on my machine and I can't connect. But even if I remote desktop into the server itself, using a seperate remote desktop login, even on that machine, I can't login using the active directory user since in the login box, if I choose window auth, I can't specifiy a different name, and sql server auth says invalid login. I don't see how to supply a windows username and password JUST when logging into sql server.
And also, what about my .net apps? I don't want to hardcode a sql server auth username/password into my encrypted connection string, i want to hard code a windows active directory username/password into the connection string.
And then reporting services, aarrghhh.. Does reporting servies ONLY work with windows logins? If so, then I'm stuck with getting the above working. If not, how do I configure a sql server login to also let me access all our reports?
This is a really broad question; I'll give a survey of some of the different topics you address. I work in a hosting provider and we have many domains with no trusts between them, so I deal with this on a daily basis.
Yes, SQL Server Windows authentication really wants to use the credentials running the client application. You can work around this with the RunAs /netonly switch:
runas /netonly /user:domain\username “C:\Program Files (x86)\Microsoft
SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe”
Authentication for .NET apps is a big topic. Lots of options and chapters, if not books have been written on this.
Regarding Reporting Services: most of this access is through a browser. So this will use whatever credentials you supply to your browser. In IE this is controlled through the security zones and settings of whether your current credentials should be used or if you should be prompted.
Some clues:
If you're external user and SQL Server is in mixed mode it will be easier for you to have SQL login not mapped to AD user (so you use SQL auth and not Windows auth). You may have two SQL Logins - one for Windows auth, second for SQL auth.
If you don't your .NET apps have hard coded passwords use Windows auth and Trusted Connection mode in your ConnectionString. If your .NET app is a service create dedicated AD user then create SQL Login mapped to this AD user. Give your SQL User mapped to SQL Login permissions whatever it needs. Run service in context of dedicated AD user. If app is directly executed by users (.EXE file) also use Trusted Connection. Create AD security group for your app users. Create SQL "group" Login mapped to this AD group. Give your SQL "group" User mapped to SQL Login permissions whatever it needs.
It's not possible to provide login and password for SQL Login with Windows auth in ConnectionString. You use TrustedConnection for Windows auth and login/password for SQL auth.
You may play with switching context inside SQL session - EXECUTE AS, see: http://msdn.microsoft.com/en-us/library/ms181362.aspx
We are developing a self registration app.
Our app allows users to register for web apps and is deployed on a weblogic 10.3.5 app server. The weblogic is connected to a local ldap system.
Once the user registeres with our app we call corporate servces to generate a user id. password activation, authentication is all handled by the corporate servcies. which also has a corporate ldap that contains all users in the company.
The approach works fine for 'new users' ie users that are not present in the corporate ldap or the local ldap: users enter their details and are issued a user id which we then copy into the local ldap once the user activates their account.
The use case we're grappling with at the moment is how to handle 'existing' users that wish to register. These are users that are currently in the corporate ldap and wish to 'register' with our applications. They get rejected during the normal registration process as they already exist in the coroporate ldap.
What i'd like to do is force them to login (simply so they don't register on behalf of somone else) and once they're logged in simply copy their data into the local ldap.
The problem is even if they are successfully authenticated by the corporate service, they don't (yet exist) as far as the weblogic server is concerned. is there a way to obtain the user id that comes with the authentication token ?
The authentication method is SAML 1.1
The application is a standard Java EE servlet based webapp using the struts2 framework.
Any ideas would be much appreciated.
Within WebLogic, you can define multiple authentication providers and set them up in the order you would like the system to use. Since you are copying data over, you would have to programmatically check for the existence of the account before attempting to create it on the LDAP server.
It would be a lot simpler if you use the external LDAP server directly instead of copying the data to the internal LDAP server, letting you attempt logging the user in and creating the account only while catching the appropriate exception.
I am using a WCF call to update my database with any changes from ActiveDirectory.
I call this WCF functin via client browser and the function trys to get details from AD within the servive itself. However the issue is AD needs UserName and Password to get any records.
Please advise how can I overcome this problem so that Windows looged in credentials are automactically accepted and AD is read.
I am using wsHttPBinding,Security: message and clientCredentials="Windows".
Thanks
Vikram
The call to Active Directory is going from the service.
The default settings for the service is impersonate=false and the identity of the application pool is NETWORK SERVICE.
Therefore, the call to AD is going in the security context of Network Service, which does not have the correct access, and cannot be given them, since it is a machine local account.
There are 3 ways to fix this.
Set Authenticate=true in the web.config to allow access to AD to be done in the security context of the calling user.
Change the identity of the application pool to that of a domain user that is allowed to access AD. Be sure to add this user to the local IIS_WPG group.
Store the username and password of a user that is allowed to access AD, in the web.config file, and use these credentials to access AD.