I've got a macOS 10.13 server running, on which I have recently had to change the hostname (upstream IT requirements) - and I suspect this has broken Kerberos.
Changing the hostname appears to have been successful: I exported the Open Directory setup, modified it, and reimported it into the updated setup - user accounts exist, and manual authentication works as expected. changeip is happy:
mac-mini:~ server_admin$ sudo changeip -checkhostname
dirserv:success = "success"
However SSO from client machines does not appear to be successful.
Attempting to run kinit with a valid user account shows this:
mac-mini:~ server_admin$ kinit test#MAC-MINI.EXAMPLE.COM
test#MAC-MINI.EXAMPLE.COM's password:
kinit: krb5_get_init_creds: Server (krbtgt/MAC-MINI.EXAMPLE.COM#MAC-MINI.EXAMPLE.COM) unknown
Looking at /etc/krb5.conf, I only see this:
[libdefaults]
kdc_timeout=5
...which is the same as it was on my previously-working configuration.
And now I'm a bit stumped. All the documentation for destroying and rebuilding Kerberos setups seem to be out of date. Any ideas?!
Thanks.
Related
I have just installed MariaDB 10.4 using Home Brew. I was finally able to set the root password, and I am now trying to enable network access.
I think have added the correct directive:
bind-address=0.0.0.0
The thing is, is it to the correct my.cnf? I have tried adding it to /usr/local/etc/my.cnf as well as to a my.cnf I found in various Cellar directories.
It doesn’t seem to work. I get the message
Host … is not allowed to connect to this MariaDB server
even when I try from the local machine.
Am I setting the directive in the wrong file, or is there something else I should be doing.
Check that your user have the privilege to access the database from remote by running:
SELECT User, Host FROM mysql.user
Check also that you don't have the skip_networking configuration property set.
Read also the following documentation page: Configuring MariaDB for Remote Client Access
I am attempting to set up gpg preset passphrase caching using the gpg agent so I can automate my file encryption process. In order for the gpg-agent to run and properly cache the passphrase, it seems there needs to be a S.gpg-agent socket located within the ~/.gnupg/ directory that gets generated in the root directory when I set up gpg and gpg-agent.
What I have done (and which seemed to work in the past) is I would start up everything as root and copy over the contents of the /.gnupg directory to my less privileged user and grant permissions to that socket and directory to the user. The commands I ran to start up the gpg-agent daemon and cache passphrase:
gpg-agent --homedir /home/<user>/.gnupg --daemon
/usr/libexec/gpg-preset-passphrase --preset --passphrase <passphrase> <keygrip>
gpg-agent process seems to be running just fine but I get the below error from the second line:
gpg-preset-passphrase: can't connect to `/home/<user>/.gnupg/S.gpg-agent': Connection refused
gpg-preset-passphrase: caching passphrase failed: Input/output error
I have made sure the socket exists in the directory with proper permissions and this process runs as root. It seems that this socket is still inherently tied to root even if I copy and modify permissions. So my questions are
How exactly does this socket get initialized?
Is there a way to do so manually as another user?
To add, the agent process seems to run just fine for both users but where I get a little hazy is how the gpg-preset-passphrase is using the socket and if its that or the agent that is refusing the connection to S.gpg-agent
I also assume that I don't need to explicitly start the agent but figured I would this so that I could set any values such as the homedir if needed.
It turns out the issue was unrelated to the gpg-agent and gpg-preset-passprhase.
Note: This is not a permanent solution but it did allow me to get past the issue I was facing.
After modifying the /etc/selinux/config and disabling SE Linux, I no longer experienced the permissions issue above. SE Linux is a Linux kernel security module developed by Red Hat (I am currently running this on RHEL7). It seems the next step will likely be to make sure these binaries and packages are allowed access from my user using audit2allow. Bit more information on this here: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-fixing_problems-allowing_access_audit2allow
So I have tried and tried to get my ssh to work with kerberos on Mavericks to no avail. Here are my versions:
ssh: OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
kerberos: Heimdal 1.5.1apple1
I also tried the built in ssh with no effect as well. Here is my config:
ForwardAgent yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
GSSAPIKeyExchange yes
i have checked, there are no overriding settings in my user config
After all of this, I still get prompted for a password when ssh'ing to a linux host that does work with linux clients. (I am able to successfully kinit and i do get a ticket)
Any clues what I am missing? Has anyone has this problem before.
HERE is a link to the ssh connection log. It just seems to abandon gssapi without even trying it... why????
NOTE ON OSX SIERRA:
It appears that Apple broke it again.... The gssapitrusdns stuff is actually a third-party contribution and Apple revved to a newer ssh that doesn't include those patches... See HERE and HERE
ORIGINAL ANSWER (pre Sierra):
Ok, so after even more head-scratching, giving up, and violent attempts to strangle my computer with a power cord, I have found the answer... Turns out, OSX need to be told to explicitly trust DNS.... Add the following line to your ssh config:
GSSAPITrustDNS yes
Source (check the 'Problems and Workarounds' section)
From the logs it looks like server is sending "gssapi-keyex,gssapi-with-mic" methods but somehow client doesn't have support for it.
Look at this logs
preferred publickey,keyboard-interactive,password
can you check your client whether it supports it or not ?
you can check client config file /user//.ssh/config -> on linux system.
I am having a problem with my server and so far couldn't find any solution for this. When I try to add a server from a server manager (windows server 2012) I can see only the kerberos security error. Both servers are in the same domain(i have tried from several servers from domain and got the same error).
The strange thing is when I unjoin the problematic server from domain and rejoin it with another name it works normally. But the problem is to make it work with existing name. Anyhelp will be highly appreciated
thanks in advance.
Late reply, but I've just encountered the same error and hope this solution proves useful to others.
Situation: I had to wipe and reinstall a virtual server on which I'd previously had to set some Service Principal Names, and some SPNs for a service account. Turns out the SPNs were still there for the old server/account and I had to remove them.
I recommend checking for and removing rogue SPNs to resolve this. Use the following commands in an elevated command prompt:
setspn -l <servername/username>
In my case I had problems with MBAM, the Bitlocker admin tool, so for example I used:
setspn -l mbam01
Which gave me the output (changed names to protect the innocent):
Registered ServicePrincipalNames for CN=MBAM01,OU=Member Servers,DC=corp,DC=domainname,DC=com:
termserv/mbam01.corp.domainname.com
termserv/mbam01
http/mbam01.corp.domainname.com
http/mbam01
HOST/MBAM01
HOST/mbam01.corp.domainname.com
This will list the SPNs associated with the server or user account. Then you remove the errant SPNs with this command:
setspn -d <listed service> <servername/username>
In my case it turned out the mbamapppool user had http/mbam01 and http/mbam01.corp.domainname.com associated with it, causing Server Manager to fail to poll the server. I removed the http/ refs from the user and then added them to the server with the following commands:
setspn -d http/mbam01 corp\mbamapppooluser
setspn -d http/mbam.corp.domainname.com corp\mbamapppooluser
setspn -s http/mbam01 mbam01
setspn -s http/mbam01.corp.domainname.com mbam01
I then refreshed Server Manager and it polled the server successfully, and the Kerberos Security Error had gone.
I am trying to make a script to install more or less automatically oracle database as well as some other application of my own. I haven't writen a line yet because I want to make all steps manually first.
So, my environment is the following. I have RHEL 5 with no graphic interface. I am connecting to the server from Windows laptop through SSH as root. I have enabled XForwarding, so when I login with root account I can run xdpyinfo so that I can check XServer configuration.
I need XForwarding because the Oracle DB installation procedure requires an XServer. However, Oracle requires the user oracle to perform the installation. I have already created the oracle user but when changing the user from root to oracle I can no longer run xdpyinfo command so the Oracle installation procedure fails. I get the following error:
Xlib: connection to "localhost:10.0" refused by server
Xlib: PuTTY X11 proxy: wrong authorisation protocol attempted
xdpyinfo: unable to open display "localhost:10.0".
I have tried to use xhost to enable my laptop to access my server but I have failed as well to do that.
If you really feel the need to do this, then while you are root, get the current $DISPLAY value, particularly the first value after the colon, which is 10 in your case. Then find the current X authorisation token for your session:
xauth list | grep ":10 "
Which will give you something like:
hostname/unix:10 MIT-MAGIC-COOKIE-1 2b3e51af01827d448acd733bcbcaebd6
After you su to the oracle account, $DISPLAY is probably still set but if not then set it to match your underlying session. Then add the xauth token to your current session:
xauth add hostname/unix:10 MIT-MAGIC-COOKIE-1 2b3e51af01827d448acd733bcbcaebd6
When you've finished you can clean up with:
xauth remove hostname/unix:10
That's assuming PuTTY is configured to use MIT-Magic-Cookie-1 as the remote X11 authentication protocol, in the Connection->SSH->X11 section. If that is set to MDM-Authorization-1 then the value you get and set with xauth will have XDM-AUTHORIZATION-1 instead.
It might be simpler to disconnect from root and start a new ssh session as oracle to continue the installation, which would also make sure you don't accidentally do anything unexpected as root. Well, until you have to run root.sh, anyway.
If you do a silent install with a response file then you don't need a working X11 connection anyway; you just need $DISPLAY to be set, but nothing is ever actually opened on that display so it doesn't matter if xdpyinfo or any other X11 command would fail. I'm not sure how you're thinking of scripting the X11 session, but even if that is possible a silent install will be simpler and more repeatable.