I have a .NET application that runs in the background and collects information from Windows client workstations. It needs to send this information to a server in a different Windows domain. The application behaves similar to a Windows service (although it is not a true Windows service) in that it runs behind the scenes without the user's knowledge. Therefore, when my server needs to authenticate the workstations, the user cannot be prompted to enter a password or select a certificate--the authentication needs to happen without bothering them for input.
If both the workstations and the server were in the same domain, then I'd probably just use WCF with Windows Integrated Authentication aka Kerberos. But since they're not I need a different strategy. Any ideas?
If you establish cross-realm trust between the domains, you can use Kerberos. In this case, the minimum needed is for the realm of the server (B) to trust the realm of the clients (A). This allows foo#A to acquire a ticket for bar#B.
Related
Details: I have hosted internal application on IIS 10. One of functionality requirement is open the one of the form to external users (out of our organization). To achieve this, DNS entry done with internal IP and external IP. I have bind internal IP with DNS name in IIS. This application work on SSO so no user creadtianls required to login to application. “Windows Authentication” configure in IIS
Problem: Username and password pop up comes when try to run the application when VPN is connected (within organization)
Note: We have done similar functionality many times, but first time stuck on this issue for long time. This time difference is hosted it on new dedicated VM
On one side I have a Windows service that uses Entity Framework to connect to a SQL Server instance and work with a database there.
On the other side I have a WIX based installer which has a bootstrapper .NET based GUI in which the user can enter connection details to be used in the connection string by the service. In this installer GUI I am also performing a check on the user provided data and check the database connection (using SqlConnection.Open() and even creating/dropping a database).
The issue appears in a workgroup environment, no domain controller present, and when the user chooses Integrated Security as an option. The bootstrapper application successfully connects to the SQL server and performs some operations with it, but then the Windows service fails to connect to the SQL server using Integrated Security. If I follow up by changing that to user and password authentication, the service works correctly.
Is there any way to have the bootstrapper fail connection if the service would fail, or the other way around?
Thanks.
The most likely cause is the user the service is running under and the user the installer is running under are different.
If the User running the installer has access to SQL Server through windows authentication the connection would succeed. Then if the service runs under a different account (Say LocalSystem) the user the service is running under does not have permissions to use integrated security.
The way around this to use a service account which has permissions on the server or use SQL Authentication.
I ran into this recently when deploying a service. The only way to fail the bootstrapper connection would be to run it as the account the service will run under (impersonation is one way to accomplish this) otherwise there is no way you can test the connection correctly.
Since you mention workgroups and no domain controller there may be some pass through going on with the user names and passwords. At one place I worked, on one of the SQL boxes (off the domain) each developer had a local windows account with the same password as their domain account. This allowed a pass through authentication (due to the username and passwords matching) and access to SQL Server. That may be what is going on.
I've been asked to write a C# application to run on a Windows 7 machine to display the time of day, weather, etc.. That I can do. What I'm looking for is guidance to run the application on a Windows7 machine without logging as a user. In essence the machine would simply be a CPU with a screen. No keyboard or mouse. I've seen deployments done on MS-PixelSense (use to be MS-Surface) using a service ID.
If I need to signin, user policies kick in, screen savers enable, etc.. I'm assuming if I use an automatic Service ID, I can let the application override most of the settings keeping the screen on and needed privileges assigned / locked down to the service ID.
Any information / suggestions are appreciated....
First, some background informations:
Accessing a network share
If a process running on your client wants to access a (CIFS) share, it has to be run under a user account (or "Service ID") which has access rights to this share. There is a way (if the client is a member of Active Directory) that the machine name appended with $ (which is in fact the machine account’s name in AD) has to be entered in the ACL (Share / NTFS), but this is not a very "usual" way.
See also https://serverfault.com/questions/41130/network-service-account-accessing-a-folder-share
Windows Service running under a user account (aka technical account or Service ID)
A service running under a user account cannot access the GUI. There are some tricks, and some years ago I wrote a tool which allows a service to start another GUI program, where the GUI is displayed above the Ctrl-Alt-Del dialog. But this does not work under Windows 7 anymore.
But even a service which runs under local system cannot display a GUI on the logon screen.
You would have to write a Credential Provider.
See
Windows service showing a GUI when no user is logged in
https://stackoverflow.com/a/3074040/4547223
Another very deep technically article. It says it is possible to display a GUI on the secure desktop / logon screen. I have not yet tested this myself:
http://calebdelnay.com/blog/2012/01/displaying-a-program-on-the-windows-secure-desktop
Autologon
The most well known way is still the "classic" autologin.
See https://security.stackexchange.com/questions/10170/how-secure-is-windows-auto-logon for some explanations and links.
The medium secure way is to store the password as LSA secret (can be done in C# with P/Invoke or with some tools).
If I need to signin, user policies kick in, screen savers enable, etc.
Yes, but this can be handled, you probably have to create an own AD OU with an own policy for that.
I'm assuming if I use an automatic Service ID, I can let the application override most of the settings keeping the screen on and needed privileges assigned / locked down to the service ID.
A service ID /technical account is basically the same as a normal personal user account.
In some Active Directory enterprise environments a technical account has restrictions that it cannot log on interactively and other restrictions. But it still IS a "user account"
Logonexpert (http://www.logonexpert.com/)
I tested this (trial version). It is a nice, small tool which does it’s job. It is more safe than "normal autologon", however in the end, it is not much different from normal classic autologon. One benefit: it stores the password more recurely, but in theory, some hacker may still decompile the program and find out a way to decrypt it. And more important for you: Beside the more safe password store, it does not gain you much. You still have a user login same as normal autologon.
A few suggestions
Probably you can use a local user account on the client system and use normal autologon mechanism. And then you should consider that the client system does not poll for new data on a network share, but instead another server program (implemented as a service, running under a technical domain account) pushes data on a network share on the client.
Doing it this way, the client code does not need to access network shares, with the benefit, that a malicious attacker also has no access to network shares.
If you really need to access a network share from the local user context, you can probably logon to the server, as explained in my answer here:
https://stackoverflow.com/a/28749093/4547223
You have to to change the registry code part with the access to the CIFS share.
But doing it this way, you again have a password, which you have to encrypt and store. I do not recommend this.
In the end...
Windows does not make it easy what you want to do. If you are not strictly bound to Windows, you can consider using a Raspberry Pi with Raspbian (a Debian derived Linux). You can install Chromium browser, which displays a web page on the server and updates automatically. We use this with great success for some time.
I'm trying to create a client-server app where the server runs on the user's machine. I'm looking into either using WCF or Sockets but I have a couple of questions.
I'd like to use WCF but it seems that the user needs admin rights in order to launch the service. Would the user need admin rights if the WCF service was running within a managed application (e.g. a Windows Service)? With sockets it seems that admin rights isn't required to open the relevant port.
How would HTTPS security work in WCF? Since this is a LAN program (user talking from client to their own machine), do I need to purchase a certificate and install it on their machines? I'd rather avoid this if possible as the data being transferred isn't sensitive. Would this be the same if I use SSLStream for sockets?
There are a lot of questions, :), so very short answer on part of them:
You can host WCF even in console application. Windows Services may not require admin properties to be installed on pc.
For HTTPS - you does not have to buy certificate, you can crate your own - there are a lot of examples in the net. But - if your data is not sensitive - you can probably use simple http.
WCF Service
I am developing a WCF Service and it needs to communicate with a com application running on the system.
I have tested the service with ASP.net development server it works fine. now when i run it from IIS the service can't communicate with the com application.
Issue is IIS runs in a different user account 'Application pool', than the one user is logged in. The COM file run on the user account user is logged in. So the that is the reason they have issue communication. Or at least that what i think.
What i did was i created a new application pool in IIS and in advance setting i changed the process model identity to local system. but it did not work....
i need ideas how to make the make the com and the service to run in the same account.
Any idea will be much appropriated.
IIS not only runs under a separate account, but also runs under a separate login session that is completely separated from the interactive users session. The COM object must be possible to invoke without a user even being logged on if you are to use from IIS.