Hi Guys,
I would like the edit the email notifications that we receive from Centrify. Currently we are getting email alerts every 5 minutes from Centrify directory synchronization service.
I can't seem to find where we turn this off?
I thought it would be Centrify > Settings > Customization > System config however the SMTP details here are blank so must be elsewhere.
Any ideas? Can't seem to locate it
Welcome back.
Can you do us a favor? Since this is the community issue/support/best practices sharing forum, this may not get to the PMs that work with this capability.
Work with your customer success lead and brind this up to their attention. If you don't have a success rep, you can open a support ticket referencing this thread.
Additionally, you can use the Idea Exchange:
https://community.centrify.com/t5/Centrify-Idea-Exchange/idb-p/Centrify-Idea-Exchange
This allows other Centrify customers to see your request and do a "me too"
R.P
Hi,
We don't currently have support, is this not something you can help out with on here?
Thanks
Sorry. I thought you wanted an enhancement. This is my mistake.
Can you look here:
[Admin Portal] > Settings > Users > Outbound Provisioning
I think if you adjust the box to do a report on full sync, it should stop annoying you (no incremental sync stuff).
However, note that you will always get an email if there's an error (which merits your attention).
Let us know if this helps.
R.P
It seems like I have a remnant of a previous configuration that causes this part to fail. Server dc.sub.example.com is not know by DNS of /etc/hosts. If you're sure the name is correct, then add it to /etc/hosts. The name isn't correct. I've grepped through some samba, kerberos, sssd, etc. conf files and can't find it. The actual server name is 'cdc'. I subbed the sub.example part of the fqdn for this post.
Thanks,
Steve
Never mind. I fat-fingered the dc name in the analysis domain info window.
In Puttygen, create your key as you would for any other scenario. then, after the key is created, click Conversions, Export ssh.com key. i saved mine as a 3rd file of same name with -alt inthe name (you can of course pick anything).
pick the -alt file as your key file in your centrify DM deployment manager.
(and pre-deploy the keyfile to authorized_keys on all your linux systems)
Hi I'm trying to install express but it says the OS isnt supported. Even with the --no_os_check. Any suggestions?
Thank you,
# ./install-express.sh --no_os_check
***** *****
***** WELCOME to the Centrify Express installer! *****
***** *****
Detecting local platform ...
WARNING: /etc/os-release exists but OS_REV is unknown
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=18.3
DISTRIB_CODENAME=sylvia
DISTRIB_DESCRIPTION="Linux Mint 18.3 Sylvia"
ERROR: The above OS release is not supported anymore. Exiting...
Error detected.
Error detected. More information may be found in the logfile
(location is /var/log/centrifydc-install.log).
Exiting ...
Welcome to the Centrify Forums.
Linux Mint (released on Nov 27, 2017) is a relatively new revision.
Although we released 2017.3 in December; there was not enough time do enough testing of all the tooling.
Note that install.sh is just a tool to make sure all is kosher to install our client. Most of the time (unless we are talking about a consumer company with a fruit as its logo) Linux and UNIX distributions and flavors are pretty standard.
Most of the time, you can get away with installing the client, joining AD and just using it (the PAM, NSS and Kerberos stacks stay relatively static).
Have you tried installing the client using apt/dpkg and running adjoin manually?
sudo dpkg -i [centrify-package-name].deb
sudo dpkg -i centrifydc-5.4.3-deb7-x86_64.deb
sudo adjoin -w -u [user-authorized-to-join-system-to-active-directory] -V -c ou=container,ou=for-system [domain.name]
sudo adjoin -w -c "ou=servers,ou=centrify" -u winadmin -V example.com
From that point on I'd inspect the NSS, PAM and Kerberos environments and try to log in with my AD users.
Note: In the practical world, most people just try to log-in right away, but I'm adding this chunk of info for future readers:
How to check to see if your new (officially unsuported) distribution can work (at least for basic funtionality)
Basic information
Inspecting the NSS environment
To check what AD users are visible (all in Express/Workstation mode)
$ adquery user # Using Centrify native commands
$ getent passwd -s centrifydc # Using classic NSS commands
To check what AD groups are visible (all in Express/Workstation mode)
$ adquery group
$ getent group -s centrifydc
Should these not resolve, I'd check to see if the /etc/nsswitch.conf was properly populated after adjoin. This would be a major indicator of incompatibility.
Checking basic functionality
The quickest way to see if things are OK is to look at the output of adinfo.
$ adinfo Local host name: system-name Joined to domain: example.com Joined as: system-name@example.com Pre-win2K name: system-name Current DC: dc.example.com Preferred site: SiteName Zone: Auto Zone CentrifyDC mode: connected Licensed Features: Enabled
If you are connected, the site is properly named and you can hit at least a DC, you can rest assured things are relatively fine. If you have issues here (like disconnection), things need to be studied further (e.g. like with adinfo -T).
Inspecting the PAM stack
Review if the PAM stack was properly populated after adjoin:
$ view /etc/pam.d/common-auth
You are looking for lines inserted by Centrify DirectControl.
# lines inserted by Centrify Direct Control { CentrifyDC 5.4.3-887 }
auth sufficient pam_centrifydc.so
auth requisite pam_centrifydc.so deny
[truncated]If this is populated correctly, you can try a PAM-enabled application to see if Auth is working.
What I typically recommend is that you use switch user (this excludes any terminal or console program like SSH or login).
$ su - [ad user]
What's expected: You should be prompted for the AD password of the user. Should everything be OK and you can switch accordingly, things are OK in the PAM stack, at least with su.
Inspecting Kerberos
The Kerberos environment is automatically configured by Centrify once the system is joined. You can:
$view /etc/krb5.confWhat to look for: entries for domain controllers, encryption levels and trusts based on your AD infrastructure should be populated automatically.
$ sudo /usr/share/centrifydc/kerberos/bin/klist -kt /etc/krb5.keytabWhat to look for: KVNOs, Timestamps and Principal names for: host, nfs, smb, http, etc. These are added by Centrify as a courtesy (configurable).
$ sudo /usr/share/centrifydc/kerberos/bin/kinit [AD user Name]What to look for: Run klist (from the path above) and you should have a TGT for the user in question.
At this point, unless you have something funny happening with the OpenSSH server, you should be able to log in.
Note that although this may just work, the next release will officially support the distro in question along with the tooling.
R.P
I'm been using Centrify express for a while. We have are moving to a new domain. I'm sure the new domain will give all of the users a new UID and groups will get a new GID. Is there a way to keep them the same? Can they be mapped or changed in AD or in Centrify?
Welcome back to the Centrify forums.
The easiest way to go about this is to use the commercial version.
That being said, you can repurpose adfixid to do a migration too.
(note the article combines it with adrmlocal).
R.P
I looked at adfixid and adrmlocal. Unless I am wrong these look at local unix account and compares them to AD. I don't have local unix account. All my accounts are from my 1st AD. All the file permissions are based on my first AD. I am not ready to move to another AD which will have different SID which will create different UID/GID I assume. Once the users are on the new domain can adfixid be run to fix all the file permission issues?
Unless I am wrong these look at local unix account and compares them to AD. I don't have local unix account. All my accounts are from my 1st AD.
You are not wrong. You will have a permissions issue. Users won't be able to accesss their home directories.
Once the users are on the new domain can adfixid be run to fix all the file permission issues?
Yes.
I have a need to delete/remove an AD account from an Ubuntu 16.04 workstation ideally, so I can have the user login again and recreate it. I receive an error whenever I attempt to use the User Accounts GUI or "userdel" from command-line. I presume this has something to do with the difference between a local account and a network/AD account but my Linux knowledge is severly lacking.
Can anyone offer any suggestions or tips? I've attempted to search these and other forums but have had no luck.
Welcome to the Centrify forums.
Keep in mind that user accounts don't exist in the local UNIX/Linux/Mac Centrified system. They exist in Active Directory.
All you need to do to get rid of traces of a previous user is remove their home directory. Most of the time you can do a sudo rm -rf /home/[username] and get rid of the data, however in enterprise environments most of the time these are backed up and reviewed just in case there is critical data (e.g. same in Windows or when deleting Exchange inboxes).
Let us know if this helps.
R.P
Thanks. I think I'm confused then as to how the local profile and folders are built when an AD account authenticates to a laptop with Centrify Express installed. If I 'rm' the home directory a new one will get built when the user next logs in? Basically, I need to ignore the "Users & Accounts" UI completely when dealing with an AD-authenticated account on the Linux workstation?
I'm confused then as to how the local profile and folders are built when an AD account authenticates to a laptop with Centrify Express installed.
UNIX/Linux systems have a framework called Pluggable Authentication Module or PAM. PAM modules do account, authentication, password, and session-related tasks. The names are self-explanatory.
The session module has the responsibility of setting-up the user's environment, that includes setting their home directory.
More info here: https://en.wikipedia.org/wiki/Linux_PAM (plus all around the web).
I 'rm' the home directory a new one will get built when the user next logs in?
Yes, you are correct.
Basically, I need to ignore the "Users & Accounts" UI completely when dealing with an AD-authenticated account on the Linux workstation?
It depends. Users and Accounts is for local. AD users belong to a centralized directory service.
Let's reload here...
What do you want to accomplish?
Give us what you want to accomplish without any technical details and let's see how we can help.
R.P
Renaming the /home directory of the user fixed the original issue, thank you for that. But to give some clarification on my original question, here's the full scenario:
I have an Ubuntu 16.04 workstation bound to my AD domain using Centrify Express (we're in the process of standing up our Centrify Identity Management, long story, needed to start somewhere). I had a user experiencing some issues with his AD "profile" on said workstation but was unable to leverage the native Users & Accounts UI to remove/readd his account to the specific workstation (not AD as a whole). There starts my confusion: "why can't I remove the user object from the workstation through the native tool?" Fortunately, renaming the user's /home folder accomplished the desired result.
Outside of this, is there a way to remove all traces of a user's login to the workstation (ex, their /home directory and username in the login screen)? Basically, if I wanted to "clean up" a machine before sending it off to a new user (without going through the hassle of re-installing the OS) or needed to fix some interface problem with an existing user of the workstation.
Thanks again for your assistance thus far. I'm hoping that when we get the full suite of tools running it will be easier.
- Chad
There starts my confusion: "why can't I remove the user object from the workstation through the native tool?"
A basic identity management principle is that principals (users, groups, etc.) can only be added/changed/removed in the source directory. The UI for your Ubuntu system is designed to work with LOCAL user and group indentities, not for remote directory identities. This is analogous with you trying to delete a user from Active Directory using the Windows Computer Management console (it's designed to deal with local users and groups) - AD users can be changed with programs that interact with AD (ADSI) like Active Directory Users and Computers, adsiedit, AD PowerShell, etc.
Note this is the same for Windows, UNIX/Linux or OS X systems. When you delete the user in the Directory, there's no "magic" that removes traces of users in clients - because you may need to retrieve files from the user's home directory!!! Usually this requieres orchestration or a 3rd party tool, especially when it comes to client systems that are not always turned on.
I think this is the best answer I can give you in the topic.
Outside of this, is there a way to remove all traces of a user's login to the workstation (ex, their /home directory and username in the login screen)? Basically, if I wanted to "clean up" a machine before sending it off to a new user (without going through the hassle of re-installing the OS) or needed to fix some interface problem with an existing user of the workstation.
Yes. I stated this in my previous post. Remove the user's home directory. Provided the user did not write personal stuff elsewhere in the filesystem, you should be covered. Note that other operating systems have native tools (e.g. Windows has the System applet where you can delete user profiles; OS X has the Users System Preference, etc).
I'm hoping that when we get the full suite of tools running it will be easier.
Just to set the expectations clearly here. You have not asked in this thread anything directly-related to Centrify functionality, but normal operating system management. I am pretty sure that the Ubuntu ecosystem has tools that make these types of mundane tasks much easier. You can use DevOps solutions like Chef, Puppet, Ansible, etc; but that's outside of the scope of what Centrify does. Our focus is Identity and Access Management, more specifically Access Controls and Privilege Management.
Hi, I need help with an issue on old Centrify system client.
The good server is running this version of the client
This is RH 5.11 version
# yum list | grep Cen
CentrifyDC.x86_64 5.1.0-497 installed
CentrifyDC-openssh.x86_64 6.0p1-5.1.0.472 installed
The problem child server is running:
This is running 7.2 but we have another parititon setup that is running 5.11 as well
# yum list | grep Cent
CentrifyDC.x86_64 5.4.3-887 installed
CentrifyDC-curl.x86_64 5.4.3-887 installed
CentrifyDC-openldap.x86_64 5.4.3-887 installed
CentrifyDC-openssl.x86_64 5.4.3-887 installed
On the good server the following user:
# adquery user fake
fake:x:1234:101:fake user:/home/fake:/bin/csh
on th e bad server
# adquery user fake
fake:x:1234:101:fake user:/home/fake:/sbin/nologin
Both server are using the same domain controller
What is missing here ?