Linux login problems...
04-05-2017 06:46 PM
Running Linux Mint 17.3 on a test system here. I'm trying out Centrify because of problems getting Likewise/PBIS Open to work, but I seem to be having similar problems. Basically when I am in the login screen now, all the AD users are visible, but if I try to login as one of them, it fails.
I've installed from the centrify-suite-2017-deb7-x86_64.tgz file, since that seemed to most closely match the 64 bit Mint I'm running.
adinfo responds with:
Local host name: xxxxx
Joined to domain: xxxxx
Joined as: xxxxx
Pre-win2K name: xxxxx
Current DC: xxxxx
Preferred site: Default-First-Site-Name
Zone: Auto Zone
Last password set: 2017-04-05 16:41:59 BST
CentrifyDC mode: connected
Licensed Features: Disabled
using adinfo -A --user <user ID> results in the message that the password is correct, so it is obviously able to successfully communicate with the DC.
What I have noticed on auth.log is that the following message turns up when I try to login as an AD user:
Apr 6 02:40:34 xxxx login: pam_unix(login:auth): authentication failure; logname=paul uid=0 euid=0 tty=/dev/pts/0 ruser= rhost= user=paul.d
So, "paul" is the user I am logged in as, before doing a "sudo login" and "paul.d" is the active directory user I am attempting to log in as.
Hopefully someone has some ideas as to where I am going wrong!
04-05-2017 07:26 PM
Welcome to the Centrify forums.
- Check if paul exists in /etc/passwd (grep paul /etc/passwd) - ideally should not exist, but does not matter because of the next test.
- Check the order of /etc/nsswitch.conf for passwd directive centrifydc should be first than files or compat
- Check to make sure that no traces of PBIS exist, should not matter either, but ideally we would not be competing.
- Check the user status (sudo adquery user -A paul | grep account), ideally the output is:
accountExpires: Never accountLocked: false accountDisabled: false
- Use switch user to isolate issues with SSH (su - paul)
You should be challenged for Paul's password and if all is well, you are able to switch. This proves nothing wrong with the NSS stack (su is NSS-enabled), now let's move on to SSH connectivity.
- Attempt to log in via SSH (e.g. ssh email@example.com)
If all is well, you should be able to log in, if not, then the issue is with SSH and you must debug (See below)
- Attempt to log in via GUI
In GUI mode, attempt to log in with Paul. Monitor the results. If everything works with su and SSH and the GUI fails, look for the PAM configuration for the GUI (perhaps a reboot hasn't been done since the installation?).
How to debug Centrify and OpenSSH at the same time, just in case you have to submit for inspection.
- Turn ON centrify debug by running "/usr/share/centrifydc/bin/addebug on".
- Next run "<path_to_sshd>/sshd -ddde -p 2222" to start the SSHD server in the foreground with verbosity turned on.
- From the ssh client, connect to the SSH server on port 2222, "ssh -p 2222 -vvv <hostname>" and try to authenticate.
- Please paste the output from the SSH server foreground session for analysis.
- Now turn OFF Centrify debug "/usr/share/centrifydc/bin/addebug off"
- The information collected will be in /var/log/centrifydc.log
- Collect the system diagnostics information by running sudo adinfo --support
- The file with the debug information will be in /var/centrify/tmp/adinfo_support.tar
04-05-2017 08:01 PM
Thanks very much for your very quick reply.
Yes, paul, the local user, exists in /etc/passwd, but paul.d, the AD user does not. I think you have the two users muddled up :-)
The adquery on paul.d results in:
So, that all looks good.
The su - paul.d resulted in:
No directory, logging in with HOME=/
This is VERY encouraging :-)
ssh -l paul.d localhost results in repeated requests for the password.
A reboot has definately been done since the installation. Now you mention pam configuration, and also state that it is specific to the GUI, so does that mean that there are two problems - one stopping the ssh from working and the other preventing logins from the GUI?
Thanks again for your help - really pleasing to see su - working.
04-06-2017 06:34 AM
There's definitely an issue with your PAM configuration.
The results of the su - paul.d should have been that the home directory is created.
This tells me that for some reason, the session PAM module could not create the folder.
If you do a debug (SSH and Centrify) you'll definitely be able to pinpoint the issue. It would be nice to know if another system acts the same way.
04-06-2017 08:28 AM
So I have been looking at the PAM configuration files for sshd and mdm (which I think is the Display Manager that Mint Mate uses). Can't see anything obvious. Do you have a working PAM config file that you ccould share, and the important parts of it?
04-06-2017 08:45 AM
I found this post:
And made a file called "centrify" in /etc/pam.d and then did the "pam-auth-update --package"
command as suggested, and said "no" to override local files, which I think is the correct answer.
I then rebooted and attempted to login as an AD user, which once again failed. When trying to login from the GUI (MDM), it specifically says "incorrect password". Which makes me wonder if the MDM is properly making the connection with centrify, since the adinfo -A --user thing proves that the password I am using is correct on the AD.
The centrify debug logging seems to spew out a LOT of lines, would you like some posted here?
04-06-2017 09:06 AM
I'm not sure about that suggestion you read.
Your system should just work.
I am in transit, perhaps anohter community volunteer reading this can help.
Note that if you're a commercial organization looking at the full centrify proudct, you get SLA-based support.