Welcome to the Centrify community.
I will give you some rapid-fire comments. Bottomline, due to the poor lifecycle management of the software, there are "many things going on" :
On our file server (CentOS 6.3, Centrify DC 5.0.4), Centrify has been working '
great for years. Yesterday, we rebooted the server to troubleshoot an issue
with our backup server, and Centrify never bounced back.
Thanks for the feedback. Unfortunately the " set it and forget it" approach does not help with authentication software (because of proper IT practices, and most importantly, security practices). CDC 5.0.4 has been EOL since September 2012, and you are using it in CentOS 6.3 that we started to support officially in 2015. Surprisingly you were doing well.
2) We used yum update to update the server to CentOS 6.9. 3) We reinstalled Samba and were able to verify that we could connect to
local Samba shares with local accounts with Centrify removed. 4) We downloaded Centrify Suite 2017 (Centrify DC 5.4.2) and installed it
using instructions.
Several comments here. I'm not sure how critical this server is (and there's nothing we can do about the past), but I think looking at change control before doing these steps could have helped better. That being said:
- With the release of 5.4.0, many things happened with our software (we split many of the open source utilities), this means that the best bet (which was an upgrade in place) wasn't supported from such an older version. By starting from scratch, you needed to understand how to reconfigure the system. This is complicated because of the changes below.
- Samba changes. Since BadLock, we EoL'd all the Centrify-enhanced Samba software, in favor of the adbindproxy Identity Mapper, this means that the deployment is slightly different.
1) We can't login to the server with domain credentials.
It accepts the username and password, then reverts back to the login screen
See below on how to determine this issue. Watch for Samba/CDC clashes depending on
how you set it up.
(yes, home directories exist with the correct permissions).
That's to be expected. The files won't be destroyed unless a human being or a program does. 2) We can't login to the server with local credentials that are not root,
but root is working correctly.
root will work correctly. We don't mess with it. 3) We cannot connect to Samba shares without getting "Access denied" errors,
though permissions have not been changed.
You need to make sure adbindproxy is set up and configured (see below). Most
importantly, remove all Centrify-ehnhanced Samba servers from your environment
since they are EOL'd and susceptible to anything from BadLock on. 4) We don't know how to test to ensure that Centrify is working correctly
or not.
Use the adinfo or adcheck commands. The most basic test is to see if the system is
disconnected with adinfo -T; after that you can check to see if the users and groups
are resolvable (adquery user/adquery group). See the link below.
If I were to approach this, I'd simply start in different parts.
Make sure CDC is working correctly and allows login; once that's done I'd work on the Samba integration.
I'd start by disabling Samba; the system does not need to be double-joined. The potential (this is an assumption) is that Samba and CDC may be having a conflict on UID/GID resolution. Let's say that userX tries to log in (the UID/GID data from Centrify is there), but depending how the NSS/PAM stack is laid out, the Samba UID/GID is resolved first, then we have a problem.
Tips:
- Use addebug (e.g. sudo /usr/share/centrifydc/addebug on) and then do a tail -f to the log file
- Try to log in, and you'll see exactly what's going on.
- The adbindproxy guide is here: https://docs.centrify.com/en/css/2017.2-html/index.html#page/Samba/Installing_the_adbindproxy_components.4.html
Please let us know of any progress you make.
R.P