Kerberos kinit: Resource temporarily unavailable while getting initial credentials - virtualbox

I am in the process of setting up Kerberos on a CentOS7 (more specific: the Hortonworks HDP 2.3 sandbox) running in a VirtualBox VM. My problem is that kinit seems to be unable to reach my KDC, the answer is "Resource temporarily unavailable while getting inital credentials" if I add an address in my /etc/hosts file and if I leave that file as is I get the message "could not contact any host for realm mycompany while getting initial credentials".
The KDC is running (can find it with ps plus the service starts with an "okay" message), same for kadmin.
As a guide for setting up kerberos I followed these two guides:
CentOS guide
Guide 2
My config files:
krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
[libdefaults]
default_realm = MYCOMPANY.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
MYCOMPANY.COM = {
kdc = kerberos.mycompany.com
admin_server = kerberos.mycompany.com
}
[domain_realm]
.mycompany.com = MYCOMPANY.COM
mycompany.com = MYCOMPANY.COM
kdc.conf
[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88,750
[realms]
MYCOMPANY.COM = {
#master_key_type = aes256-cts
acl_file = /var/kerberos/krb5kdc/kadm5.acl
dict_file = /usr/share/dict/words
admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
}
kadm5.acl
*/admin#MYCOMPANY.COM *
/etc/hosts
127.0.0.1 localhost.localdomain localhost
192.168.96.140 sandbox.hortonworks.com sandbox ambari.hortonworks.com
192.168.1.3 mycompany.com kerberos.mycompany.com
I get the "Resource..." error if I have any address in the third line of the hosts file, if that line is missing I get the "could not contact..." error.
I could trace the kinit command with something along the lines of krb5_trace or something (unfortunately I can't find the link I got it from any more nor remember the exact command) to the address specified in the host file so kinit seems to contact the fitting address, its just that the KDC does not listen there.
Netstat shows that the KDC is listening on the ports specified in the kdc.conf
Any help would be appreciated

Okay so it does work now. Things I did to fix it:
/etc/resolv.conf
mycompany.com 127.0.0.1
/etc/hosts
127.0.0.1 localhost.localdomain localhost
192.168.96.140 sandbox.hortonworks.com sandbox ambari.hortonworks.com
127.0.0.1 mycompany.com kerberos.mycompany.com
And, most embarrassing: I used kinit mycompany/admin for the principal user/admin#mycompany.com which is of course wrong.
The right call is of course kinit user/admin

Related

Automatically certbot renew wildcard certificates on NameCheap - port 53 problem?

I'm trying to get an AWS/Lightsail Debian server automatically renewing certificates with certbot. My DNS is with Namecheap.
I'm follow the steps on https://blog.bryanroessler.com/2019-02-09-automatic-certbot-namecheap-acme-dns/ and https://blog.bryanroessler.com/2019-02-09-automatic-certbot-namecheap-acme-dns/. I keep getting a no-permission error.
I run:
sudo certbot certonly -d "*.example.com" --agree-tos --manual-public-ip-logging-ok --server https://acme-v02.api.letsencrypt.org/directory --preferred-challenges dns --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --debug-challenges
I see:
Failed authorization procedure. example.com (dns-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT record found at _acme-challenge.example.com
It says I need to open port 53. I followed Amazon's Lightsail instructions. Neither iptables nor ufw seems to be installed. When I nmap my machine, I don't see 53. I actually installed ufw for lack of a good idea, to no avail.
My /etc/acme-dns/config.cfg is as follows:
#/etc/acme-dns/config.cfg
[general]
# DNS interface
listen = ":53"
protocol = "udp"
# domain name to serve the requests off of
domain = "acme.example.com"
# zone name server
nsname = "ns1.acme.example.com"
# admin email address, where # is substituted with .
nsadmin = "example.example.com"
# predefined records served in addition to the TXT
records = [
"acme.example.com. A <public ip>",
"ns1.acme.example.com. A <public ip>",
"acme.example.com. NS ns1.acme.example.com.",
]
debug = false
[database]
engine = "sqlite3"
connection = "/var/lib/acme-dns/acme-dns.db"
[api]
api_domain = ""
ip = "127.0.0.1"
disable_registration = false
autocert_port = "80"
port = "8082"
tls = "none"
corsorigins = [
"*"
]
use_header = false
header_name = "X-Forwarded-For"
[logconfig]
loglevel = "debug"
logtype = "stdout"
logformat = "text"
For the listen value, I also tried 127.0.0.1:53 and :53
The settings portion of /etc/letsencrypt/acme-dns-auth.py:
# URL to acme-dns instance
ACMEDNS_URL = "http://127.0.0.1:8082"
# Path for acme-dns credential storage
STORAGE_PATH = "/etc/letsencrypt/acmedns.json"
# Whitelist for address ranges to allow the updates from
# Example: ALLOW_FROM = ["192.168.10.0/24", "::1/128"]
ALLOW_FROM = []
# Force re-registration. Overwrites the already existing acme-dns accounts.
FORCE_REGISTER = False
Thanks for any help you can provide.
If you don't wish to maintain your own acme DNS server, I built and use this script to automatically renew NameCheap wildcard certs with certbot. I hope it helps:
https://github.com/scribe777/letsencrypt-namecheap-dns-auth

AWS cloud-config not setting dns-nameservers

Here is the cloud.cfg on my instance (I had tampered it manually when provisioning the ami from which I launched the instance)
root#ip-10-17-0-121:~# cat /etc/cloud/cloud.cfg | grep -i resol -C 3
# Network configuration for ami
manage_resolv_conf: true
resolv_conf:
nameservers: ['10.11.4.1']
However this is never taken into account given that:
# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.17.0.2
search eu-west-1.compute.internal
I have tried with and without creating the following file
# cat /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
network: {config: disabled}
I managed to make my instance obtain my custom dns-nameserver as follows
- name: pre_tasks --> Add my custom dns-nameserver
lineinfile:
path: /etc/dhcp/dhclient.conf
regexp: '^#prepend domain-name-servers'
line: 'prepend domain-name-servers 10.11.4.1;'
become: yes
However now I am getting the following warning:
pkara#ip-10-17-0-35:~$ sudo -i
sudo: unable to resolve host ip-10-17-0-35
not accepting my answer until / unless I address this;
edit_1: adding this to my cloud-config.yml which I am setting as user data did not help much:
hostname: localhost
manage_etc_hosts: true
edit_2: adding this to my cloud-config.cfg helped me to address the above unable to resolve host problemn
bootcmd:
- echo "127.0.0.1 $(hostname)" >> /etc/hosts

python, in for loop i can iterate only with my last element

I have a dictionary that contains a list of servers:
{'server1': 'RHEL 6.8', 'server2': 'RHEL 6.8', 'server3': 'RHEL 6.8', 'server4': 'RHEL 6.8'}
I want launch a hostname command on each node (this is a method on class).
ssh connection:
def ssh(self, cl_name, cmd):
try:
ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect(self.cl_name, timeout=2)
stdin, stdout, stderr = ssh.exec_command(cmd)
out = stdout.read()
return out
except (paramiko.ssh_exception.SSHException, socket.error, paramiko.ssh_exception.AuthenticationException, socket.gaierror):
print "server DOWN"
return False
This is the method that should by run a hostname command on each node:
def get_load(self):
for k in self.get_cluster_nodes().keys():
print k
cmd = "hostname"
print self.ssh(k, cmd).rstrip()
This is the output:
server1 (EXAMPLE: print k)
server4 (EXAMPLE: print self.ssh(k, cmd).rstrip() )
server2
server4
server3
server4
server4
server4
I work on python 2.7.
Seeing your output, everything seems fine.
You are using self.cl_name instead of cl_name which would be a parameter of your function (k in this case).
I think that you are calling the method from an object which has its attribute cl_name set to server4.
Old:
Although it seems that the hostname command output is the same for each server, have you tried connecting manually to each servers and running hostname ?
If you did, the problem might come from somewhere else, like a bad value for the server IP or something.

Deploy VM from template and set VM and DNS name

I’m using pyVmomi to deploy a VM from a template on vSphere,
this woks ok, the new VM get the name I sent as parameter but I want that the DNS name \ hostname will be same as VM.
Is there a way to set the hostname when doing the actual clone ?
If not how can I do that after the new VM was created ?
Here is part of the code I'm using:
# RelocateSpec
relospec = vim.vm.RelocateSpec()
relospec.datastore = datastore
relospec.pool = resource_pool
# ConfigSpec
configSpec = vim.vm.ConfigSpec()
configSpec.annotation = "This is the annotation for this VM"
# CloneSpec
clonespec = vim.vm.CloneSpec()
clonespec.location = relospec
clonespec.powerOn = power_on
clonespec.config = configSpec
print ("cloning VM...")
task = template.Clone(folder=destfolder, name=vm_name, spec=clonespec)
wait_for_task(task)
I think you need a clonespec.customization (vim.vm.customization.Specification). You should be able to specify the hostname there somehow or other.
Oh, as far as I know VMware Tools must be installed for guest OS customization.
Hope that helps.

Error sending email using CDO on port 587 (TLS)

Is there any trick to sending mail with CDO on port 587 (the port that uses TLS security protocol)?
This is my C++ code:
CDO::IMessagePtr iMsg(__uuidof(CDO::Message));
CDO::IConfigurationPtr iConf = iMsg->GetConfiguration();
CDO::FieldsPtr iFields;
_bstr_t empty("");
iConf->Load(CDO::cdoIIS,empty); // this string constant from import
iFields = iConf->Fields;
iFields->Item["https://schemas.microsoft.com/cdo/configuration/smtpserver"]->Value = _variant_t(szServer);
iFields->Item["https://schemas.microsoft.com/cdo/configuration/smtpserverport"]->Value = _variant_t(587);
iFields->Item["https//schemas.microsoft.com/cdo/configuration/sendusing"]->Value = 2;
iFields->Item["https//schemas.microsoft.com/cdo/configuration/smtpauthenticate"]->Value = _variant_t(1); // Basic
iFields->Item["https//schemas.microsoft.com/cdo/configuration/sendusername"]->Value = _variant_t(szUser);
iFields->Item["https//schemas.microsoft.com/cdo/configuration/sendpassword"]->Value = _variant_t(szPassword);
if(iUseSSLTLS == 2)
iFields->Item["https//schemas.microsoft.com/cdo/configuration/sendtls"]->Value = _variant_t(true);
else
iFields->Item["https//schemas.microsoft.com/cdo/configuration/smtpusessl"]->Value = _variant_t(true);
iFields->Update();
etc... etc...
If I use this code with smtp.gmail.com:
server: smtp.gmail.com,
port: 587,
sndtls = true,
account: my gmail account,
password:
I obtain the following response:
Code = 8004020e,
Code meaning = Impossibile modificare o eliminare un oggetto che è stato aggiunto utilizzando COM+ Admin SDK,
Source = (null),
Description = Indirizzo del mittente respinto dal server. Risposta del server: 530 5.7.0 Must issue a STARTTLS command first. y2sm3575389wme.12 - gsmtp,
(sorry ... part of the message is in Italian language, but take a look at the bold/italic one)
Obviously, if I configure Outlook 2010 using the same parameters, it works perfectly.
One more thing, if I use port 465 and SSL:
server: smtp.gmail.com,
port: 465,
smtpusessl= true,
account: my gmail account,
password:
the code works fine, but I need to configure 587 port and TLS.
I eventually tried smtpusessl and sendtls together, setting them true:
iFields->Item["https//schemas.microsoft.com/cdo/configuration/sendtls"]->Value = _variant_t(true);
iFields->Item["https//schemas.microsoft.com/cdo/configuration/smtpusessl"]->Value = _variant_t(true);
And I obtain the following error:
Code = 80040213
Code meaning = IDispatch error #19
Source = CDO.Message.1
Description = The transport failed to connect to the server.
After over 2 years, I found a solution, well ... not a solution, but now I know why it didn't work, e why it will never work. It seems there's a bug in CDO library: it can handle STARTTLS command on port 25, but it can't on port 587.
You can read more here:
https://social.technet.microsoft.com/Forums/en-US/37d00342-e5e9-4c8d-975d-44362332d426/bug-in-cdomessage-smtpserverport-587-fails?forum=ITCG
As I've just written above, it's a bug and I think Microsoft will never correct it. The recommendation for the future is to abandon CDO and use "Power shell" or third-party components.