Assume system S owns a certificate C. The following quote suggests that if C is to be used by S's service apps to authenticate themselves to clients, then C should be stored in LCS. But if C is to be used by S's client apps to authenticate themselves to a service, then C should be stored inside CUS:
• The local computer store (LCS).
This contains the certificates
accessed by machine processes, such as
ASP.NET. Use this location to store
certificates that authenticate the
server to clients.
• The current user store (CUS). Interactive
applications typically place
certificates here for the computer's
current user. If you are creating a
client application, this is where you
typically place certificates that
authenticate a user to a service.
But next quote sort of negates the above, since it says if S's service is embedded in an application that runs under a user account, then certificate C should be stored inside CUS
Selecting where to store a certificate
depends how and when the service or
client runs. The following general
rules apply:
• If the service is a Windows service,
a service running in "server" mode
without any user interface under a
Network service account, use the local
machine store. Note that administrator
privileges are required to install
certificates into the local machine
store.
• If the service or client is embedded
in an application that runs under a
user account, then use the current
user store.
a) what is meant by service being embedded within an application? Is a WCF service running within Net. console application or within Asp.Net application considered to be embedded?
b) And why if app ( which embeds WCF service ) runs under the user account ( even if this account has admin priviliges ), should certificate be located in CUS? Does that mean if it is located within LCS, then S ( aka client app trying to send this certificate to the server ) won't be able to locate certificate?
thank you
a) A WCF service running within a .NET console application would be considered an "embedded" service according to that description. This is also referred to as a Self-hosted service.
If the service is running within an ASP.Net application, then it depends on what process is hosting the ASP.Net application, but normally that would be considered a service running in "server" mode.
b) In order for a service to authenticate itself to clients, the user under which the service process runs needs access to the private key corresponding to the certificate. The most convenient way to make this happen is to have the certificate (with private key) installed in the certificate store of the user that runs the process.
It is possible for an application running as any arbitrary user to access a certificate and private key stored in the local computer store as long as security permissions on them allow it.
It all boils down to the identity of the running process and whether it has permission to access the private key associated with the desired certificate.
Related
Is there any way to keep client third party service password secured from others being able to access server machine?
Password is used to send messages between two system, from A->B. There are 3 actors:
client - owner of the infrastructure and user of system A and B
provider A - author of system A which have ablitity to RDP into client server and administrate it to keep system A working
service B - service providing access to system B, secured with password known to client which provider A shouldn't directly know
Every solution based on encryption and storing password in configuration/database is not an option because provider A will always have access to decrypting algorithm and mangled password.
Best solution right know is based on keeping password in server Windows Credential Manager. Provider A can use it inside message sender process by its code but password itself is not directly visible in server. It always can be retrived by provider A but it is a bit safer.
I have a request to restrict the access (access control) to a small user community in GCP.
Let me explain the question.
This is the current set up:
A valid GCP Organization: MyOrganization.com (under which the GCP project is deployed / provisioned)
Cloud DNS (To configure domain names, A & TXT records, zones and subdomains to build the URL for the application).
Oauth client set up (tokens, authorized redirects URIs, etc.).
HTTPS load balancer (GKE -managed k8s service- with ingress service), SSL certificate and keys issued by a trusted CA.
The application was built using python + Django framework.
I have already deployed the application (GCP resources) and it is working smooth.
The thing is that, since we are working in GCP, all IAM users who has a valid userID#MyOrgnization.com can access the application (https://URL-for-my-Appl.com).
Now, I have a new request, which consists in restricting access (access control) to the application only for a small user community within that GCP organization.
For example, I need to ensure that only specific IAM users can access the application (https://URL-for-my-Appl.com), such as:
user1#MyOrganization.com
user2#MyOrganization.com
user3#MyOrganization.com
user4#MyOrganization.com
How could I do that, taking into account the info I sent earlier ?
thanks!
You can use Cloud IAP (Identity Aware Proxy) in order to do that.
Identity-Aware Proxy (IAP) lets you manage access to applications
running in App Engine standard environment, App Engine flexible
environment, Compute Engine, and GKE. IAP establishes a central
authorization layer for applications accessed by HTTPS, so you can
adopt an application-level access control model instead of using
network-level firewalls. When you turn on IAP, you must also use
signed headers or the App Engine standard environment Users API to
secure your app.
Note: you can configure it on your load balancer.
It's not clear in your question if your application uses google auth (but considering that you talk about org-restricted login I think so) - if that's the case you should be able to enable it without virtually touching anything in your application if you are using the Users API.
The best and easiest solution is to deploy IAP (Identity Aware Proxy) on your HTTPS Loadbalancer
Then, grant only the user that you want (or create a gsuite user group and grant it, it's often easier to manage)
I want to connect to a network share path '\domainname\folder-name' using domain account, without passing credentials, through my VB6 code.
My legacy VB6 application service (running on server A) currently accesses shared folder (on server B) using local account credentials(stored in encrypted .ini file). This service is running on behalf of 'LocalSystem'.
application is using 'WNetUseConnection' API to connect to shared folder.
To ensure security local account needs to be replaced by 'domain account' and password policy should be CyberArk dynamic password.
Now this credentials can't be stored in .ini file anymore. The idea that I am working on is to get service running on behalf of 'domain account' rather 'LocalSystem'. My thought is if i make service run on behalf of 'domain account, and give relevant permissions to this account on shared folder. Shared path should be accessible to service without providing credentials.
I need help to understand which API shall I use.
The API(s) you'll need for this is WNetAddConnection.
See this example.
Background info
Developed a web app that uses IIS8. Currently using IIS to perform client authentication. Server self-signs a certificate and the certificate is imported on specific PCs.
User access site from browser and browser prompts for SSL cert. (Cert is imported to Personal Folder).
For PCs with single accounts there is no issue as i just import the certificate to that account.
For PCs with multiple accounts, if i import the certificate to the Local Computer account the different accounts are unable to access the certificate.
Query
How do i allow multiple accounts to access a single certificate? Tried to grant individual permissions to the individual accounts from the Local Computer Certificates console but to no avail. I do not want to issue the certificate individually to each account.
Is there a solution or alternative to this query?
You should try and separate authentication (using client certs) from account management, meaning authorization.
A good approach might be to use client certificates only to identify the user accessing your application (with exactly 1 certificate for each user). Then setup an n:m mapping to determine that user's groups, which in turn are given specific rights within your application. This is a common way to decouple users and their rights, to facilitate managing each.
I'm trying to authenticate to Opends server using winldap , I installed my self signed certificate to system trusted root certificates,personal store etc(where ever applicable). ldp.exe which is a tool by microsoft works fine for ssl and tls connection .I have 2 user accounts in my PC(admin and Administrator) everything works fine for both user accounts , except my windows service.
My windows service(a library management program) couldn't verify the server certificate. but my sample code works(which is a small part of code similar to my windows service) ,
I have seen similar scenarios on this website and their suggestion (https://msdn.microsoft.com/en-us/library/aa702621.aspx).
My service displays Group name as N/A in services tab and user name as SYSTEM in processes tab of task manager and I'm not sure what to do , please some one help me to solve this issue.
Thanks in advance.
Actually Windows has 3 types of certificate stores Local User , System , Services .
Usually windows services run as a special account called System(we can make it run on a particular user account as well)
Self signed certificate is added to the local user account alone (for both admin and Administrator as mentioned). so the windows Service couldn't verify the certificate.
Solution is to add the certificate to the System store .
The program works fine