I am setting up kerberos authentication for one application. Active directory is installed on Windows Server 2012 R2 and I am generating keytab file on a centos machine which is not added to domain.
I can successfully test generated keytab file with following command
kinit -k -t /tmp/hirosrv.keytab hirosrv#HIRO.COM
Security event created on windows machine is:
A Kerberos authentication ticket (TGT) was requested.
Account Information: Account Name: hirosrv Supplied Realm
Name: HIRO.COM User ID: HIRO\hirosrv
Service Information: Service Name: krbtgt Service ID: HIRO\krbtgt
Network Information: Client Address: 10.XX.XX.2 Client Port: 37142
Additional Information: Ticket Options: 0x40800000 Result
Code: 0x0 Ticket Encryption Type: 0x17 Pre-Authentication Type: 2
Certificate Information: Certificate Issuer Name: Certificate
Serial Number: Certificate Thumbprint:
Certificate information is only provided if a certificate was used for
pre-authentication.
Following is the output of klist -A
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: hirosrv#HIRO.COM
Valid starting Expires Service principal
12/03/18 16:26:48 12/04/18 02:26:48 krbtgt/HIRO.COM#HIRO.COM
renew until 12/10/18 16:26:48
Same service principal is associated with user account:
PS C:\Users\administrator> setspn.exe -Q krbtgt/HIRO.COM
Checking domain DC=hiro,DC=com
CN=hirosrv,CN=Users,DC=hiro,DC=com
krbtgt/HIRO.COM
krbtgt/HIRO.COM#HIRO.COM
Existing SPN found!
Application is configured to use the keytab file for authentication but I am getting the following error:
ERR_S_PRINCIPLE_UNKNOWN(7) error.
Related
I could use some guidance on what needs to be put in place for resolving this SSL issue to an artifactory server when running
pip install. Is this "self signed certificate" supposed to be replaced by a specific one provided by that server?
Could not fetch URL [our.artifactory.server.name]/simple/hercl/:
There was a problem confirming the ssl certificate: HTTPSConnectionPool
(host='[our.artifactory.server.name]', port=443):
Max retries exceeded with url:
/api/pypi/our.artifactory.server.name-local/simple/hercl/ (Caused by SSLError(SSLCertVerificationError(1,
'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed:
self signed certificate in certificate chain (_ssl.c:1131)'))) - skipping
Credited to pip.pypa.io:
Starting with v1.3, pip provides SSL certificate verification over
HTTP, to prevent man-in-the-middle attacks against PyPI downloads.
This does not use the system certificate store but instead uses a
bundled CA certificate store. The default bundled CA certificate store
certificate store may be overridden by using --cert option or by using
PIP_CERT, REQUESTS_CA_BUNDLE, or CURL_CA_BUNDLE environment variables.
In regards to the SSL issue, it depends whether you insist on SSL enforcement, if not, you may use an existing flag to ignore this by appending --trusted-host <server_name> ,in the example below: --trusted-host artifactory.
Some suggestions raised to overcome this issue are suggested here as well: pip install fails with "connection error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:598)"
Do note, prior to using artifactory as a caching/proxy server for Pypi packages, you should configure the pip.conf and .pypirc files according to the SetMeUp instructions: https://www.jfrog.com/confluence/display/JFROG/PyPI+Repositories#PyPIRepositories-ResolvingfromArtifactoryUsingpip
For example:
pip.conf:
[global]
index-url = http://artifactory:8081/artifactory/api/pypi/pypi-virtual/simple
.pypirc:
[distutils]
index-servers =
virtual
local
remote
devpi
[virtual]
repository: http://artifactory:8081/artifactory/api/pypi/pypi-virtual
username: admin
password: ***
[local]
repository: http://artifactory:8081/artifactory/api/pypi/pypi-local
username: admin
password: ***
[remote]
repository: http://artifactory:8081/artifactory/api/pypi/pypi-org-remote
username: admin
password: ***
[devpi]
repository: http://localhost:3141/admin/dev
username: admin
password: ***
I created a user in the Master.
First I created a key and certificate for him: dan.key and dan.crt
Then I created it inside Kubernetes:
kubectl config set-credentials dan \
--client-certificate=/tmp/dan.crt \
--client-key=/tmp/dan.key
This is the ~/.kube/config:
users:
- name: dan
user:
as-user-extra: {}
client-certificate: /tmp/dan.crt
client-key: /tmp/dan.key
I want to be able to run commands from a remote worker as the user I created.
I know how to do it with service account token:
kubectl --server=https://192.168.0.13:6443 --insecure-skip-tls-verify=true --token="<service_account_token>" get pods
I copied the certifiacte and the key to the remote worker and ran:
[workernode tmp]$ kubectl --server=https://192.168.0.13:6443 --client-certificate=/tmp/dan.crt --client-key=/tmp/dan.key get pods
Unable to connect to the server: x509: certificate signed by unknown authority
I followed this question:
kubectl unable to connect to server: x509: certificate signed by unknown authority
I tried like he wrote:
kubectl proxy --address 0.0.0.0 --accept-hosts '.*'
But I am still receiving:
Unable to connect to the server: x509: certificate signed by unknown authority
I copied the certifiacte and the key to the remote worker and ran:
[workernode tmp]$ kubectl --server=https://192.168.0.13:6443 --client-certificate=/tmp/dan.crt --client-key=/tmp/dan.key get pods
Unable to connect to the server: x509: certificate signed by unknown authority
You were missing the critical piece of data telling kubectl how to trust the https: part of that request, namely --certificate-authority=/path/to/kubernetes/ca.pem
You didn't encounter that error while using --token=... because of the --insecure-skip-tls-verify=true which you should definitely, definitely not do.
I tried like he wrote:
kubectl proxy --address 0.0.0.0 --accept-hosts '.*'
But I am still receiving:
You have followed the wrong piece of advice from whatever article you were reading; that --accept-hosts flag only controls the remote hostnames from which kubectl proxy will accept connections, and has zero to do with SSL anythings.
I enabled TLS in NiFi by running the below command,
nifi-toolkit/nifi-toolkit-assembly/target/nifi-toolkit-1.4.0-SNAPSHOT-bin/nifi-toolkit-1.4.0-SNAPSHOT/bin/tls-toolkit.sh standalone -n "{my-ip},localhost" -C 'CN={my-ip}' -C 'CN=localhost' -o ./certs
This created the files required for TLS under the directory certs.
I moved the files under the directory certs into the conf folder of the deployment in my machine.
Installed the certificate to my machine's Keychain Access.
Now started the server using bin/nifi.sh start. My server starts, I am able to hit the server, But my request is not authorized.
I am getting the below error,
Not authorized for the requested resource. Contact the system
administrator.
Once TLS is enabled in Apache NiFi, anonymous access is no longer enabled by default. You will need to authenticate as a user in order to access the UI/API. There are three authentication mechanisms available -- client certificates, LDAP, or Kerberos. Once you configure an Initial Admin Identity in $NIFI_HOME/conf/authorizers.xml (this would be the exact CN of the client certificate you issued in the TLS Toolkit command), that user can authenticate and use the user management tools in NiFi to add additional users.
You can find more information in the NiFi Admin Guide. Bryan Bende has also written a detailed walkthrough of the process.
One note about the command you posted above -- I am not sure what your desired output is, but the command is issuing a server certificate for my-ip and another for hostname, but then two client certificates with those DNs as well. In general, you want a server certificate for hostname (possibly with a SAN entry for my-ip), and a client certificate with a DN like CN=alopresto, OU=Apache NiFi.
For example:
./bin/tls-toolkit.sh standalone
-n 'nifi.nifi.apache.org'
--subjectAlternativeNames '123.234.234.123'
-C 'CN=alopresto, OU=Apache NiFi'
-P password
-S password
-B password
-f ...conf/nifi.properties
-o ...conf/
I deployed apiserver using TLS on master node and it worked fine,my question appeared when I deploying the kubelet and tring to communicate with apiserver.
the kubelet conf as follows:
/opt/bin/kubelet \
--logtostderr=true \
--v=0 \
--api_servers=https://kube-master:6443 \
--address=0.0.0.0 \
--port=10250 \
--allow-privileged=false \
--tls-cert-file="/var/run/kubernetes/kubelet_client.crt" \
--tls-private-key-file="/var/run/kubernetes/kubelet_client.key"
--kubeconfig="/var/lib/kubelet/kubeconfig"
/var/lib/kubelet/kubeconfig is following:
apiVersion: v1
kind: Config
users:
- name: kubelet
user:
client-certificate: /var/run/kubernetes/kubelet_client.crt
client-key: /var/run/kubernetes/kubelet_client.key
clusters:
- name: kube-cluster
cluster:
certificate-authority: /var/run/kubernetes/ca.crt
contexts:
- context:
cluster: kube-cluster
user: kubelet
name: ctx-kube-system
current-context: ctx-kube-system
As I want to achieve the comunication using a two-way(both client and server)CA authentication and expect for a fluky reply,but apiserver ask me to provide my username and password which I have never used before,some command lines as following:
> kubectl version
> Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.2", GitCommit:"9bafa3400a77c14ee50782bb05f9efc5c91b3185", GitTreeState:"clean", BuildDate:"2016-07-17T18:30:39Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"}
> Please enter Username: kubelet
> Please enter Password: kubelet
> error: You must be logged in to the server (the server has asked for the client to provide credentials)
I tried all these on master minion.Could anyone please resolve this conundrum？Thanks in advance.
You have to enable client certificate authorization via the --client-ca-file flag on the apiserver.
From http://kubernetes.io/docs/admin/authentication/:
Client certificate authentication is enabled by passing the --client-ca-file=SOMEFILE option to apiserver. The referenced file must contain one or more certificates authorities to use to validate client certificates presented to the apiserver. If a client certificate is presented and verified, the common name of the subject is used as the user name for the request.
From http://kubernetes.io/docs/admin/kube-apiserver/:
--client-ca-file="": If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
--cloud-config="": The path to the cloud provider configuration file. Empty string for no configuration file.
During the testing of the Travelocity sample application at Login screen, option2 OpenID, I get the following error at the client side:
0x704: I/O transport error: peer not authenticated
Any recommendation about the required steps to activate SSL protocol
support in the Travelocity sample application running under the Tomcat7?
More details from the Tomcat7 log:
SEVERE: Servlet.service() for servlet [ForwardingServlet] in context with path [/travelocity.com] threw exception [0x704: I/O transport error: peer not authenticated] with root cause
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.ibm.jsse2.ab.getPeerCertificates(ab.java:61)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at ...
Thanks for assistance.
As WSO2IS contains a self-signed certificate by default, So you need to configure its certificate as a trusted certificate to the sample application. We can configure a truststore file for the Tomcat server. you can add following two java parameters in to the "catalina.sh" file in /bin directory.
export JAVA_OPTS="-Djavax.net.ssl.trustStore=<PATH_TO_TRUST_STORE_FILE> -Djavax.net.ssl.trustStorePassword=<PASSWORD>"
As an example. Please note that the PATH_TO_TRUST_STORE_FILE file must contains the WSO2 server's certificate.
If your WSO2 server's certificate's CN value is not equal to the WSO2 Server's hostname, you would be probably hit by following error as well
hostname in certificate didn't match: !=. So, you need to make sure CN is equal to hostname as well.