I know this is an old thread but, I am having the same issue. I followed the steps but I get this error:
Computer Failed to cahnge it own password
Adjust the privilege settings for 'computername' or retry with a more privileged principal.
Adkeytab return code:27
Faild: Reset Password: Default Key Tab
Any further help with this issue would be great.
I am running centrify on Mac OS X 10.11.3
Thank you,
AED
BUMP! any update!?
the xrdp-sessman includes
:
@include common-auth
@include common-account
@include common-session
@include common-password
These files are where the centrify pam modules are configured.
I can login with sso using centrify PUTTY.
When I use xrdp, before the xrdp-sessman is called, it asks me for user and password. I enter an AD user and leave the password field empty. Is this how it should work?
RDP to a windows server dont ask for user and password. It just sighn in automaticly as SSO should do.
Thanks
Rafi
Hello,
Where can I download centrify enabled samba for ubuntu 14.04?
In the download page I can only see centrify-suite, adbindproxy, and putty.
Thanks
Rafi
Due to the Samba Badblock vulnerability and other complexities, we no longer ship a Centrify-enhancedversion of Samba server, just the Identity Mapper (Adbindproxy).
The current versions are available via download center: https://www.centrify.com/support/customer-support-
For information about badblock: https://www.samba.org/samba/security/CVE-2016-2118
R.P
Robertson wrote:
When troubleshooting e-mail delivery:
a) Make sure the user's e-mail address is correct (in the Centrify Cloud Directory, Active Directory (GAL), LDAP or Google Directory).
b) Make sure that the user's e-mail system isn't blacklisting "donotreply@centrify.com" or modify the email template to reflect a whitelisted address.
Finally, as a good design choice, depending on your security posture, make sure that the user has several step-up mechanisms and ideally at least one multi-factor mechanism. As of 16.8 (current release) the options are:
- Password and User-defined question are just secrets > they don't qualify as step-up or MFA
- Phone call, Email, Text (SMS) are step-up mechanisms > can be relatively good mechanisms for Step-up authentication.
- Mobile authenticator (push), OATH OTP client and 3rd party RADIUS (e.g. SecurID, Symantec VIP, Vasco, etc) > satisfy the requirements for MFA (something you have) and are relatively easy to set up.
- If you have the App+ edition, you can use Strong Authentication (certificate-based authentication/smart card) using your PKI infrastructure as well.
Make sure that your Auth Profiles include an alternative delivery method.
R.P
I tried to re-open this. Not sure if I succeeded. I still have this one user who does not receive the email. I tried adding the MFA policy and it doesn't seem to be working either.
Rafi,
There's a good blog and video tutorial here: http://community.centrify.com/t5/Community-Tech-Blog/Server-Suite-2016-Samba-with-adbindproxy/ba-p/24052
See around 4:30 in this video, which uses a Ubuntu system as an example:
:)
Hello
I created an authentication profile named "MFA" with Challenge 1 including Mobile Authenticator, Phone Call, Text message confirmation code, and Email conformation code.
I then edited the Default Policy>User Security Policies>Login Authentication>Identity Cookie - is not present and set the authentication to the "MFA" profile. I expected this to give me the options listed in MFA, but I still only have the email option for the authentication link. Am I misunderstanding the expected behavior or is there some other issue?
Thanks
Jay
Hello
Policies are processed top down, so this should be kept in mind when applying the policies.
Now, MFA challenges will only be shown when the corresponding attribute is valid and present for the User that is attempting to use this.
For instance, You will want to confirm that the User has a Mobile Phone number in ADUC or in the Cloud User section (If Cloud User), User should have enrolled a device for Mobile Auithenticator, etc.
Lsst, to confirm the correct policy is being enforced, check the User in the User table, and look at the Policy Summary. You should see the applied polices and authentication profile in use. If this is not showing the correct one, review the order processing in the Policy tab and make sure the correct Policy is being applied.
This guide from the online docs explains more about using Policies in the Cloud Manager
Managing Policies (In Centrify Cloud Manager)
I hope this helps!
Ryan V.
I have one new user who is not receiving the authentication challenge emails. I've verified that his email address is correct and matches in AD and Centrify. He receives all other external emails. Although no other user has this issue and I've verified there are no Centrify emails caught in our filters, I whitelisted donotreply@centrify.com to no avail. In the user activity I see this each time his account is challenged:
08/31/2016 12:29 PM User john.doe@domain.local was challenged by EMail at 'john.doe@domain.com' Cloud.Core.Login.MultiFactorChallenge XX.XX.XX.XX
By the looks of this, it certainly seems like he should be receiving the email, but he's the only user who doesn't. Any ideas?
Thanks,
J
Hi J and thanks for posting your question. Considering this seems to be the only user experiencing the issue, would it be possible to confirm the actual address in use so we can match in our system?
Please send the address to communitysupport@centrify.com or you can also send me a private message if preferred. I can quickly validate message status for the user and post an update for you.
Thanks for any info you can provide,
-Tony
Is there anything in the log you can see? I really don't want this to get forgotten.. please assist.
Hello,
We currently use Centrify to authenticate one on premise Active Directory domain (say, "domain1.local") users. We have recently setup another domain (say, "domain2.local") and synchronized its users by using the same UPN suffix of "domain1.local" to Office 365. The issue that we face is "domain2.local" users are not loaded in the Centrify Cloud Manager. This causes the "domain2.local" users unable to logon to the Office 365 portal.
Can anybody assist in this problem?
Regards,
Ganesan
Welcome back.
I am going by the example that you just mentioned. You have added a new parallel forest (not a child domain e.g. north.contoso.com vs south.contoso.com). Since these two forests are disjointed, you have several options based on your infrastructure or security posture.
With AD using a trust relationship: If both forests (domain1.local and domain2.local) have a transitive two-way trust relationship, the cloud connector will recognize the new forests and will start including users from the newly-trusted forest, however this may not be aligned with your security goals.
With Centrify Identity Service adding a cloud connector in a properly sized Windows sytem to provide AD Proxy services to domain2.local. This way you can pick users, sync identities, provide SSO and provisioning for O365 for users from both forests.
Check the cloud connector help for more info: https://docs.centrify.com/en/centrify/adminref/index.html?version=141#page/cloudhelp%2Fcloud-admin-config-proxy.html%23
R.P
This thread is a bit old and I thought you had figured it out.
Unfortunately, in my Express lab with a two way trust I wasn't able to reproduce the behavior, but here's what you can do.
Under /usr/share/centrifydc/bin there should be a binary for ldapsearch. Try to use that binary to search for the expiration attribute as a straight ldap query. This way you can compare and display the results vis'a'vis adquery user.
If the results are different, my only suspicion is a bug or a corrupted cache. Make sure you're using the latest version of Centrify.
Please post your results, if that's the case I will file a bug on your behalf.
Hello
Are you upgrading from a previous Centrify Express install? If so, can you remove the previous install and then try to install again?
Also, please try to download the agent again from here;
If the issue still occurs, in terminal, lets check to see if there may be any stale files that need to be removed.
To do this, open terminal and run;
sudo rm /System/Library/Security/tokend/* sudo rm -rf /Applications/Utilities/Centrify sudo rm -rf /usr/local/share/centrifydc sudo rm /usr/local/bin/sctool
Next, try to install again.
Please let me know if this helps!
Happy Friday!
Ryan V.
Thank you, it was very helpful. It should be updated in the documentation.
I have a problem with using samba with Centrify, but I'll open a new post so that the subject will reflect the question.
Hi,
I'm trying to mount CIFS shares using Kerberos with Centrify Express.
I've read all the posts I could find here about it, but it keeps failing.
What I do, I use the keymap cache file of the user krb5cc_<uid>, change the file ownership to root, and type:
KRB5CCNAME=/tmp/krb5cc_<uid> mount -t cifs -o sec=krb5i,user=<user> //server/share /mnt
I get error message:
mount error(524): Unknown error 524
My linux is Ubuntu 14.04, Centrivy Suite version is 2016.1 and adbindproxy version is 5.3.0.
Any idea?
I'm not personally a mount or Samba expert, but I would make sure that the version of DirectControl and adbindproxy match (both should be at 5.3.1)
(5.3 is suite 2016)
There are folks that have found issues with mismatched versions.
R.P