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.
Related
I'm trying to logon to domain joined computer using certificate only,
I wonder if it's possible, i read allot on smart card and virtual smart card and both requires ping code.
From what i understand kerberos allows authentication using PKI certificate, so the basic question Is it possible to login the user to the domain using certificate only?
Thanks
Yes. You need to deploy a CA that can issue certificates for users, and configure Active Directory to support certificate authentication. This involves registering a KDC certificate on each Domain Controller and issuing certificates to users. Certificates for interactive logon can be stored in smart cards or TPMs for classic authentication scenarios as well as using e.g. Windows Hello for more modern scenarios.
The basic process is along these lines:
Spin up a Certificate Authority and generate the kerberos/user auth/smart card certificate templates (Example steps
Request certificates for each DC for KDC auth
Request certificates for a given user (enroll cert on smart card)
From there you can require certificates for interactive logons on a per-user basis. There's a bunch of guides on how to do this such as the one linked above.
for my new task I have to use SCOM to monitoring non-domain server/computer. My company told me to do it with only 1 server management that contains others SCOM features. So I have a server Windows 2016 with SCOM with a local domain, and I have to connect the others devices. It seems easy, but I have a problem with certificates: when I try to certificates my server & computers, and I'll import the certificate with MOMCertImport, in Event Viewer I see the event id 21007, that tell me "The OpsMgr Connector cannot create a mutually authenticated connection to 'PC-NAME' because it is not in a trusted domain." So I have the certificates installed but I can't anyway connect Agent to SCOM, What will I do? I search anywhere for this problem, but any solution not work with me!
There are few things you need to look at.
The certificate: must have both client auth and server auth purposes.
Authentication is MUTUAL, i.e. you agent confirms its identity to a gateway, or to a management server, AND the gateway or management server confirms its identity to the agent.
Certificates must be issued to EXACT conputer FQDN. If you rename, or join domain, or change DNS suffix => this will invalidate certificate, because FQDN changes.
Install and bind certificates at both participating servers (i.e. agent and (MS or GW)). This is because #2.
Obviously, you need individual certificates for each server, because of #3.
Ensure, that both servers can maintain trust chanin to own certificate and to other party's one. Ideally, if you have a single root/issuing CA, which used to issue both certificates. In this case, just install root/issuing CA certs in appropriate storages in local computer account. If using self-signed, you need to install them as trusted at other party.
I'm writing a utility Mac OS X app that basically acts as a web server accepting incoming HTTP requests (think of it as a mock REST API server). I want to be able to support HTTPS, but ideally I'd like to remove the requirement for my users to have to purchase their own SSL certificates.
I've been thinking a little on how I might achieve this. Let's say I register a domain called myapp.com. I then purchase an SSL cert for myserver.myapp.com that is signed by a registered CA. I ship my app with those SSL cert details embedded within it. All my users have to do is update their /etc/hosts file to point myserver.myapp.com to whatever IP address my app is installed and running on.
In fact, by far, the most common scenario would be my app running on the same machine as the client, so I'm considering updating the main DNS entry for myserver.myapp.com to point to 127.0.0.1, and most users wouldn't have to change anything.
So, that's the basic theory. What have I missed that would make this an unworkable plan? A couple of things that have crossed my mind:
I could use a self-signed cert. However, many SSL clients barf (or throw up warnings) if the cert doesn't have a valid CA chain. I'm happy to pay the money for a real cert to alleviate this inconvenience for my users.
I would be embedding the private key for my SSL cert into my app. In theory, someone could extract that and use it to impersonate my app. I guess my reaction is "so what?" My app is a small productivity app, it isn't an e-commerce site. It doesn't collect sensitive info. It literally just simulates web server responses so devs can test their apps.
Any advice/feedback would be greatly appreciated. Thanks.
This won't work - but for nontechnical reasons.
Distributing an SSL certificate to your users along with its associated key will violate the issuance terms of your SSL certificate provider, and they will revoke the certificate when they discover what you have done. (This happened, for example, when Pivotal tried to offer SSL service for developers through sslip.io.) This will, of course, cause your application to stop working.
If your users have administrative access to their machines, they can create and trust their own self-signed CA using Keychain Access. Once they have done so, they could create a certificate (again, using Keychain Access) and insert that into your application to enable SSL.
As said in the other answer you can't ship the same certificate for everybody. What you could do is generate different for everybody:
The application ask them the domain name they want to use (a domain they must own, like myapp.example.com)
The application use the ACME protocol to get automatically a trusted certificate from let's encrypt
Note: you can provide them subdomains of a domain you control (like [clientid].yourappname.yourdomain.com) ONLY of you can register yourappname.yourdomain.com in the public suffix list (because let's encrypt have rate limits)
Using a server application with C#, how is it supposed to work when accessing users in the same domain if the authentication is only possible using:
OAuth2Authenticator interface?
I'm able to access the admin of the domain's Drive, but I'm missing the 3 legged OAuth in 2.0.
Looking at this description found at this link: https://developers.google.com/drive/delegation
Since this is not executed as a Service, and is not using Google Apps and cannot then
access: https://www.google.com/a/cpanel/mydomain
Also the IP is not known from where the machine running the server-application.
Currently I'm using: "Client ID for installed applications", and it works. But what I need is to also store files in other users in the same domain.
A other solution that works temporarily is to first store them at the admin domain account and then move them to the user domain account. But this removes the possibility to direct it to a parent/folder at the end user's drive. It will always be stored in root for that end user.
Basically what I want is following:
A Server application is running on a local machine (admin domain account can be used)
The application upload files to different users that are in the same domain, but with their own email address and also then have their own Drive.
Yes, you can do that through 2 legged oauth, which can provide domain-wide authorization.
Here are some links for your reference:
https://developers.google.com/gdata/docs/auth/oauth#2LeggedOAuth
http://support.google.com/a/bin/answer.py?hl=en&answer=2538798
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.