Is it possible to develop a basic client/server Forms app (suppose I could develop the server side as a service, but would rather not) that can prove that a user account within a 2012 R2 Active Directory domain can authenticate with an application residing on a server on a trusted 2003 domain, using NTLM? If so, what specifically within my application would I need to do to force such a behaviour?
The detail:
I am responsible for performing an upgrade of Active Directory from 2003 to 2012 R2 (raising of the Forest and Domain Functional Level). There is a legacy application which does not support Kerberos authentication and a lot of doubt that this mission critical application will still work after the domain upgrade. To complicate the matter, the user accounts are in the domain to be upgraded and the application backend is hosted on a trusted domain that will not be upgraded.
I am required to first of all test the process and outcome within a test lab (replica of the live environment). I am unable to replicate the application as it is to big and complicated to do so. One of the tests I need to satisfy is to verify that a user can be authenticated by a trusted domain using NTLM (not Kerberos).
It turns out that you can use the age old DOS "NET USE" command to verify NTLM authentication. "NET" only uses NTLM :)
Related
Need help with connecting to SQL Server using Windows authentication by different users logging in to the clients using their domain account. We have thousands of users and is there a easy way to use a specific AD service account even though users login to these client machines using their windows account. I see some examples of that online if using IIS. But we need this to work with a client server app. Please help if there is a workaround. Thanks!
Typically you would either provision SQL Logins for the AD Groups containing the users, or (less secure) use a SQL Login with user/name and password embedded in the application configuration.
We currently have a two-tier enterprise application where a Windows desktop app connects directly to an SQL Server database. Data access permissions are set in the database using standard SQL Server features, sqlserver windows authentication is being used (users use their domain logins).
We would like to introduce an application server layer, but we need the same authentication scenario, i.e. all the queries, initiated by the desktop app, have to be run in the database under user domain account that started the app.
It is also important that users do not enter their credentials in the app, the current domain account is used.
Client application is a WPF .NET desktop app.
Is this possible using ASP.NET WebAPI as an application server?
If you're using Active Directory to authenticate users, once they've successfully authenticated into your application, you will have their domain identity. You could then pass that as a part of the connection string for every user-specific database CRUD operation.
I would recommend that you have a shared SQL login though for core things such as caching, database logging and auditing, error logging, application authentication and authorization, etc.
I have a website that is backed by a database. I requested a SQL Server login with read/write/execute privileges to be created in our Production environment, and our DBA indicated that a non-interactive service account would be preferred.
Are there any potential issues with using a service account in this manner over a SQL Server login?
According to Microsoft, it is a "best practice" to use a service account (i.e. Windows account) and use SQL logins only for legacy applications that are not able to use Windows accounts (see Microsoft Recommendation).
So, only if your website is based on a non Microsoft technology or not hosted by IIS an SQL login might be the better choice.
At my current employer's we've been using non interactive Windows accounts to connect from our ASP.NET applications to SQL server all the time without any problems. It also makes managing and deploying connection strings easier because you don't have to care about securing them.
If you have an ASP.NET application it's good to add the account under which the IIS app pool runs (or a domain group it's in) as a login on the SQL Server.
However an SQL login might also have the practical advantage to be easier to test with: E.g. you can connect to the server using this account with SQL Management Studio to check if the permissions are sufficient.
I'm researching whether or not it makes sense for my company to use Azure for some outward facing applications. We need it to integrate with Active Directory so that it knows who they are without having to login to the site, kind of a single sign-on. Has anyone done anything like this or what tools I'd need to use to do it?
To elaborate a little, currently all of our intranet apps use Window Authentication with AD groups to determine who has what access and what level of access they have to the apps. So, once they log onto their machines, they don't have to login again to access any of our home grown apps. We're looking at using the Cloud but we want to keep the same login paradigm if at all possible. Ideas?
Thanks,
Jeremy
You can federate AD to Azure - you will need at least 1 server (on premise) running Windows Server 2008 R2 to get the ADFS bits (code name was Geneva). Then on the Azure side, you use the Azure App Fabric authentication. See MSDN.
An observation on Pat's answer:
*Then on the Azure side, you use the Azure App Fabric authentication. See MSDN
That is not necessarily correct. In the simplest form, which looks like what Jeremy needs, the web site on Windows Azure would simply trust the local ADFS server on-premises. To do this you would use WIF (Windows Identity Foundation).
This scenario is extensibly described in multiple documents. Check Here
A scenario in which you would use Windows Azure AppFabric (the latest CTP) is one in which the app would trust multiple identities simultaneously, and Appfabric would act as an "Identity Hub".
We have an application, consisting of an MS Access frontend (2007, mdb format), a few .net libraries and an SQL Server (2008) backend. I am working on an installer, which automatically installs the MS Access Runtime, our application, our libraries, SQL Server Express and configures everything.
Clearly, the MS Access application and the libraries (running in a normal, non-admin user context) need access to the SQL Server database. What is the best way to grant access to the application?
This is what I came up with. Unfortunately, all of these seem to have drawbacks:
SQL Server Compact Edition: Does not support views.
Application Roles: This seems to be best practice. However, it requires executing a stored procedure before accessing the database (I cannot pass the app credentials in the connection string). Thus, I cannot use this to attach the SQL Server tables as a linked tables in the Access MDB, which is a requirement of our Access application.
SQL Server User Instance: To quote from MSDN: "This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work..."
SQL Authentication: Microsoft says: "When possible, use Windows Authentication."
Using Windows authentication and granting BUILTIN\USERS full access: This is by far the easiest solution, but somehow it "seems wrong" to do that...
The application is targeted at a non-technical audience, so asking the user to configure permissions is not an option.
EDIT: Some clarification: It's a "local" application, i.e., the SQL Server is located on the same machine as the application; SQL Server access from the network is neither necessary nor desired. The software (a regular business application for managing stocks, invoices, etc.) will be available to download for free, so it should run in a variety of environments (domain/non-domain, different operating systems, etc.), and IT knowledge should not be required to install it -- apart from the usual "click on setup.exe, confirm UAC prompt, acknowledge the installation directory, etc.". I expect the most common scenarios to be "Windows XP, local admin user" and "Windows Vista/7, local admin user with UAC enabled". Since we want to follow good practices, running the application should not require "Run as Administrator" in the latter case.
#Heinzi write:
Using Windows authentication and
granting BUILTIN\USERS full access:
This is by far the easiest solution,
but somehow it "seems wrong" to do
that...
The usual approach here is to add a custom user group (e.g., "db-users") and put the users in that group. That way you can control exactly who is allowed access.
How about:
Use an Access ADP project, pre-configured to connect to the locally installed SQL Server instance.
Connect using BuiltIn\Users group (or SQL authentication) but grant only the bare minimum credentials. Enough to logon and ...
Call sp_setappprole to "elevate" the client connection to your defined application role's identity.
If sound like you have only got the tie of the iceberg. When it comes to selling and deploying access SQL applications.
I have take a different route. I have virtual computers as standalone workstation and domain server and workstation all virtual.
I have write a scripts they are a combination of VBA and VBScript.
Ask
Is the DB and App to run on single computer or different computers.
If different computer what is the name of the computer the DB is located on.
Is the DB and App to in a workgroup, homegroup or domain environment
Is the DB computer already have SQL Express or above
Is the App computer already have Access or Access Runtime installed.
If yes which version.
Will all or only limited users have access.
If limited what is the user group name of user to be have access to the data.
Does this group already exist
If No List the Name of the Users that Should Be Added to the Group
Also questions about the Admin Users and Group
The script start the virtual machines and goes through a series of steps to rep the MDB and SQL DB for deployment. Then creates an MSI for the Server Install with include a custom script that sets up the environment. Finally packages MDB in a nice MSI.
I have since enhanced the process to allow some questions to be answered at the beginning of the server installation. This means the user groups and users can be selected from the lists in the workstation or domain depending on prior questions asked.
If user the app user is a member of the Admin Group of the Workstation or Domain. They get extra menu options. That allow them to add or remove members from the DB user group for the workstation or domain. This I find is helpful.
I am now moving to the next stage and looking at hosting my assess app as an SasS (Software as a Service) (Rental). So the app can be use in any HTML5 Browser, Windows or Mac as Virtual Desktop or Android and Apple device. Having said that Access is a bit ugly on mobile devices.
When I am up and running I will make the platform available to others.