One of my setup is the following:
*An offline root CA.
*An online SubCA.
*A server with the CRL.
*A domain controller.
*Domain-joined Windows client machines that are able to receive certificates and renew them only if their current certificate is valid (not expired and not revoked), if the cert is revoked, the renewal fails.
*A server configured with the NDES role.
*Realm-joined Linux client machines that are able to receive and automatically renew their certificates via the NDES server.
The first certificate enrollment by the linux client machine requires the use of the one-time password retrieved at http:///certsrv/mscep_admin using the NDES service account credentials. Then, the certificates are renewed automatically if their currently installed certificate is valid (no new password retrieval needed and no manager approval needed).
My problem: If from the SubCA I revoke the linux client certificate and manually publish the CRL to make sure that the revocation appears in it immediately, then the automatic renewal still succeeds.. and the renewed certificate is not in the CRL so the client machine ends up having a truly valid cert.
I have tried clearing the CRL cache at the NDES server and redownloading the CRL: the serial number of the revoked certificate is in it but still it gets renewed.
I have tried playing around with the values at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP with the registry editor, hoping to enforce CRL checking via a CRLFlags value but did not succeed.
I've tried many things, read through all the content that I could find on NDES but I am running out of ideas of things to try.
In another setup, with a Radius server we noticed something similar: if a client certificate is valid in terms of expiration date but manually revoked, then it still gets accepted by the radius server as if it was never revoked. Similarly, the crl cache does not seem to be the issue.
Any help would be greatly appreciated.
Related
I understand that the principle of Kerberos is to allow authentication between users and services on an unsecured network. Tickets generated by the authentication and ticket-granting service support secure communications and don't require a password to be transmitted across the network.
The flow relies on the auth server in the KDC (s) having a shared secret with the client (c).
However, at some point, the user itself must have been created and generally, users are created from client machines (you don't usually log onto the domain controller to create users)
So how do the user and secret key (Kac) get created in the first place and stored in the KDC database if the password/secret is never sent across the network?
The administration of principals in a KDC's database is outside the scope of the normal Kerberos protocol. Usually it's done using some auxiliary protocol, and each KDC can implement it in any way it wants.
For example, MIT Kerberos has the (SunRPC-based) kadmin protocol, and the kadmin client indeed sends the actual administrator-specified password to the kadmind service running on the KDC. (The RPC message is encrypted using the Kerberos session key, of course.) Heimdal has its own kadmin protocol, mostly incompatible with MIT's but working the same way.
(Both also have "local" versions of the kadmin tool, which directly accesses the KDC database backend – this is how the initial admin accounts are created, typically by running kadmin.local on the server console or through SSH.)
Microsoft Active Directory has several user administration protocols, some of them dating to pre-AD days, but the primary mechanism is LDAP (usually over an GSSAPI/Kerberos-encrypted session, but occassionally TLS-encrypted).
To create a new account in MS AD, the administrator creates an LDAP 'User' or 'Computer' entry with the plain-text 'userPassword' attribute, and the domain controller automatically transforms this attribute into Kerberos keys (instead of storing it raw). The commonly used "AD Users & Computers" applet (dsa.msc) is really an interface to the LDAP directory.
All of the above implementations also support a second administration protocol, the kpasswd protocol whose sole purpose is to allow an existing user to change their password. As you'd expect, it also works by transmitting the user's new password over the network, again making use of Kerberos authentication and encryption. (Password changes can also be done via AD's LDAP or MIT/Heimdal's kadmin, but kpasswd has the advantage of being supported by all three.)
As a final side note, the PKINIT extension uses X.509 certificates to authenticate the AS-REQ – in which case the client doesn't know their own shared secret, so the KDC in fact sends the whole Kc to the client over the network (encrypted using a session key negotiated via DH, somewhat like TLS would). This is mostly used in Active Directory environments with "smart card" authentication.
I have a service broker configured in two different databases on two different servers. The problem is that I can't receive message because I have the problem:
Connection handshake failed. The login 'public' does not have CONNECT permission on the endpoint. State 84.
I have endpoints with certyficates, I gave permission to connect to a specific user who has a certificate(I did it on two servers because it is always on availability group), while looking for a problem I noticed that the certificate from the initiating server is different from the certificate from the target server:
-initiator - signature algorithm: sha1RSA, key length: 1024 (sql ver. 11.0.7 ...)
-target - signature algorithm: sha256RSA, key length: 2048 (sql ver. 15.0.4 ...)
When I grant permission:
grant connect on endpoint :: BrokerEndPoint to PUBLIC
Servers communicate but this does not solve the problem.
Can different types of certificates be a problem?
grant connect on endpoint :: BrokerEndPoint to PUBLIC
Doing this basically bypasses authorization, as everybody is authorized to connect. I think you should try to fix the user/roles permission.
I noticed that the certificate from the initiating server is different from the certificate from the target server:
This shouldn't make any difference.
It looks like the problem is you somehow misconfigured the users/login/certs chain. Is so darn complicated that is easy to break... Here is a redux of the proper setup:
There are two layers of security: conversation security (between services in DBs) and transport security (between endpoints in instances). You are now talking about transport security (endpoint to endpoint).
Endpoint security is always between the SQL instances involved. If you have AGs then each node needs to be separately configured, as the endpoints are instance level concepts and do not follow AG failovers.
An endpoint will use the certificate configured (CREATE ENDPOINT ... FOR SERVICE_BROKER (AUTHENTICATION = CERTIFICATE <certname>)). The certificate must have an accessible private key to be usable (ie encrypted with a key that can be opened from the service master key, usually via the master database master key).
During handshake, the authentication and authorization is mutual. Say to instances, S1 and S2 need to connect, then:
S1 will use certificate C1, S2 uses certificate C2
S1 needs to have C2 (public key only) in its master database, and S2 needs to have C1 (public key only) in its master.
The C2 certificate in S1 master is owned by a database user (a database principal), say it's US2. This user has a login (a server principal, say UL2). The login UL2 must be granted CONNECT permission on the S1 endpoint.
Vice-versa: the C1 certificate in S2 master is owned by an user (US1) that has a login (UL1). This login UL1 needs to be granted CONNECT permission on S2 endpoint.
For troubleshooting, enable the "Audit Broker Login" event in Profiles (in the Security Audit group). This event will fire with details of why a handshake fails, when it fails.
Ty for your time, I checked the connection and data again and found no problem anywhere. As I was bothered by the fact that maybe it was a problem that I wrote about so for the test I created another connection but this time on the server with SHA256 certificate and as I thought it is a problem here. To confirm my theory, I replaced the certificate on the initial server about which I wrote earlier to SHA256 (I deleted and re-created the endpoint with this certificate) and on the target server I replaced this certificate and the problem was solved. So it's like I thought certificates must have the same type of encoding.
Once the certificate got generated successfully, the previous active provision profile got invalid.
We are using codename one Certificate wizard to generate certificates.
A provisioning profile includes a reference to the certificate, when you generate a new certificate you revoke the old one. That's why we ask you if you want to replace the old certificate to which you said Yes.
The correct approach moving forward is to say No and copy the certificate from the previous project. That way the wizard will only generate provisioning.
We have one domain with trust (not-transitive) to two other domains. The base domain user can login without any problems, but the users from other domains cannot.
We get exception from ADFS like this:
The Federation Service encountered an error during an attempt to
connect to a LDAP server at {trusted domain}.
Additional Data Domain Name: {trusted domain} LDAP server hostname:
{trusted domain dc} Error from LDAP server: Exception Details: A
local error occurred.
User Action Check the network connectivity to the LDAP server. Also,
check whether the LDAP server is configured properly.
After reserching we found out, it's the one-way trust problem. The problem is, we don't have any posibility to change the trust configuration or to set up other ADFS on trusted domains.
Is there some possibility to get it to work? Maybe some work around solution?
Is it possible to change the FormSignin page, search the user manualy with DirectoryServices and manualy create the token?
Thanks All!
Not sure if there's a way to do it if you keep your ADFS service account in the trusting domain (in a one-way trust scenario). You would need to allow that account to be able to query LDAP in the trusted domain, which would usually mean a two-way trust.
Absent that, you may try to setup use an ADFS service account from the trusted domain. Of course, this would only work for one of your domains (unless the two other domains have trusts between themselves).
Typical ISP setup. One server is the web server, another is the DB SQL server. There is a local administrator account, let's say XYZ, created on both machines. So when I log in remotely, I am either WebServer\XYZ or DBServer\XYZ, depending where I log in.
Now, when I login to SQL Server SSMS on DBServer using Windows Authentication, and execute "SELECT SUSER_NAME()", I get DBServer\XYZ. That makes sense since it's picking up the fact that I logged in with those credentials.
Now, move over to the WebServer. I remotely login as WebServer\XYZ. I've installed the SQL client components there. When I launch SSMS, choose the DBServer, login with Windows Authentication, and execute "SELECT SUSER_NAME()", I somehow get DBSERVER\XYZ, instead of what I would assume should be WebServer\XYZ.
Somehow, the XYZ from the WebServer becomes the XYZ from the DBServer. Why is that? How does that happen? Surely, it can't just be because the names happen to be the same?
I've heard of trusted domains, but neither machine is a Domain Controller, so I don't have access to that info. How can I tell if it's trusted or not, without the GUI tools?
The reason I ask the question is because, I'm trying to implement the same thing on my XP laptop (using Virtual PC), so I can imitate the production environment, but I'm not having any luck.
The NTLM challenge between machines is a little more complex #Quassnoi indicates but it is similar. The machines may well be in the same domain or trusted domains, but the accounts you are using are local machine accounts, scoped only to the local machine's security access management.
Local SAM accounts patterned as machinename\userid are non-propagatable. You'd experience a series of negotiated fallbacks when you tried to authenticate against external resources using that account as follows:
Pass current domain/username/password hash token - it'll fail, the account is untrusted
Fallback - revert passing hash of UserID + Password
Fallback - revert to connecting as anonymous credentials.
The fallbacks can also be disabled through configuration, it is very common for anonymous authentication to be prevented.
As #Quassnoi indicates in this instance you managed to login using the #2 fallback.
To enable account credentials to propagate, you'd need the following to be true:
machines would need to be members of domains with at least one-way trust between each other (they don't necessarily have to be members of the same domain).
use domain accounts - not local machine accounts - would look something like domainname\userid. A special case is the Network Service account which has a proxy account in the domain scenario - domainname\machinename$.
How do you tell if your machine is a member of the domain? It's pretty easy if you've got interactive login to the machines. There are a few strategies
interactively the System control panel will show workgroup or domain membership. (Right-click properties on Computer in the start menu)
at the command-line, IPCONFIG /ALL will also show the default DNS prefix which is typically the same as your domain name.
I suspect your ISP would create a domain just to make it easy to manage and monitor their machines. Whether they'd let you create domain accounts is a different question.
You XYZ accounts seem to have same passwords on both machines, and they are not a part of a domain.
WebServer sends just XYZ as a username and answers all password challenges successfuly, as the passwords do match.
DbServer, of course, thinks of you as of DbServer/XYZ, as it knows of no others.
Exactly same thing happens when you try to access one standalone machine from another one over SMB. If your usernames and password match, you succeed.