find-generic-password /Active Directory/DOMAINAME Equivelent for Centrify
05-05-2017 07:00 AM
I am trying to setup a script that requires the computername and Computer Trust password. On a mac that is joined to the domain using the normal Apple method I could use:
security find-generic-password -w -s "/Active Directory/DOMAIN" /Library/Keychains/System.keychain
That would then return the computer trust password for use with my script to send for authentication.
On a Centrify Joined machine there is no /Active Directory key in the keychain.
I found one machine that had the /CentrifyDC application password but the returned password when using that still give Access Denied so I don't think that is the right password. The /CentrifyDC item isn't showing on all my test macs anyway so that wouldn't be a consisten method even if it worked.
Is there a script string I can run that would return the correct Computer Account Trust Password when joined via Centrify? Thanks!
Solved! Go to Solution.
05-05-2017 01:27 PM
Thank you for your inquiry and welcome to Centrify!
You can use /Centrify for Centrify binded macs which equivelent to /Active Directory while using apple plugin. The below is an example on how to fetch the computer name with its machine password which you can modify to fit your need:
COMPUTER_NAME=`cat /var/centrifydc/kset.prew2k.host| tr [:upper:] [:lower:]`$
security find-generic-password -a "$COMPUTER_NAME" -l "/CentrifyDC" -w
Hope this helps.
05-05-2017 01:49 PM
Thanks for the response. I have some Centrify Joined machine that don't have a /CentrifyDC Item in the system keychain. What could cause that?
Also, on the machine I am able to use the /CentrifyDC for it does return a password but when trying to authenticate with that it says "access is denied due to invalid credentials" are you sure that would be polling the right PW?
05-05-2017 02:31 PM
May I know what is the version of agent you are using and also the OS X/MacOS version? If this is not there, could you try to rejoin and see if it will help?
If the application are able to deal with the kerberos, you can try the below approach instead:
1. Modify the /ect/centrifydc/centrifydc.conf with commenting out "
2. Save and run "sudo adreload" to take effect
3. Run kinit <computer hostname>$
4. It should generate the kerberos ticket for the machine which you can use it and this will be a securer way.
The password should be correct if this is in sync with AD, you can check if it is in connected mode "adinfo -m". And you can verify the password to AD using the following command:
adinfo -A --user <computer hostname>$ <domain>
Hope this helps.
05-08-2017 06:51 AM
Thanks for your help so far! On the machines that don't have a /CentrifyDC item in the keychain, I tried running those extra commands but they didn't seem to work.
These are MacOS 10.12.4 running centrify 5.3.3.
I wanted to see if we could get the /CentrifyDC to show up without having do a an unbind and rebind of the machine as I'm not sure if that can be done remotely easily. I did manually unbind and rebind one machine and it brought the /CentrifyDC item into the keychain. However on the other test machine I have that doesn't have the /CentrifyDC item I tried using those other commands.
First the adclient.autoedit: true item in the .conf file was already commented out with a # at the begining of the line so I didn't end up changing that.
when running kinit <computer hostname>$ I get an error: "Configuration file does not specify a default realm"
when running adinfo -A --user <computer hostname>$ <domain> it does ask for the password but after putting that in it gets "Unable to connect to server"
On a happy progress note, I did get the authentication credentails to work for the machines that have a /CentrifyDC item. It turns out when authenticating I had to use the Computername with the trailing $. I was trying to just do the Computername without a $ at the end so that was why it was failing authentication.
I think the only remaining issue now is how to get a /CentrifyDC item back into the keychain on the machines that don't have it without doing a manual unbind and rebind. (if possible)
05-08-2017 06:58 AM
Sound like this is getting a bit complicated.
Can you please let me know what you're trying to accomplish? (no implementation details), just the goal of your application.
The reason for this is to try not to use passwords.
05-08-2017 08:06 AM
@Robertson- sure I can provide a big picture of what I am trying to accomplish.
End goal is to pull down a machine domain certificate from the certificate server to use for wireless and VPN authentication. See sample script at the URL below.
REFERENCES: nkalister - https://jamfnation.jamfsoftware.com/discussion.html?id=3387
With the help of @ac83124 I was able to get the AD_COMPUTER_NAME and AD_TRUST_ACCOUNT and pull down the certificate for the machines that have the /CentrifyDC item stored in the keychain.
I just have a few machines in my Test Lab that don't have the /CentrifyDC item in keychain (even though they show domain joined and connected) and I'm not sure yet how many other end users have macs in the same situation.
We have been using Group Policy to pull down a machine certificate currently but there hasn't been a way to specify the ACL permissions on that certificate. So the cert it pulls down doesn't allow it to be used by Airport or our VPN Application. If I can pull down a cert manually with the Web Enrollment menthod using an adapted script as referenced above I can make that certificate pull down and then adjust the ACL to "allow all applications" to use it.
05-08-2017 09:46 AM
I really appreciate you clarifying this requirement for us.
You have options.
If you are using the licensed version of Centrify (I'm saying this because this is in the Express forum).
You should be able to use a the "Enable Machine Wi-Fi Profile" GPO and the native ability of the client to use Microsoft PKI and auto-enrollment to help you simplify this process.
Here's a checklist approach: http://community.centrify.com/t5/TechBlog/HOWTO-A-checklist-approach-to-enable-802-1x-networking-on-...
Alternatively, if you don't have the licensed version, you could leverage the adcert command to get the certificate pulled into your Keychain store provided that you have Microsoft PKI set up correctly. This could work with another CAs if you are creative enough :-)
Ultimately, what we are trying to avoid here is a solution that will rely on a password (embedded or vaulted) because ultimately it's not a "kosher" security practice.
05-08-2017 10:24 AM
We have tried using the GPO method as you describe and it does work sort of. But it imports the cert with locked down permissions. We use Cisco VPN and there isn't a way to specify that application to be an authorized app on the cert using GPO. If we manually change the ACL on the cert it refreshes and looses the setting next GPupdate.
05-08-2017 10:35 AM
Hmmm... seems to be something we can help you with by enhancing the way we are doing things (on the long run), but perhaps....
...did you try changing the umask on the target directory as a potential workaround? (or, alternatively, you can change the runmapper script -the script that runs to perform the GPO action-).
If these things sound foreign to you, let me know.