Binding to Centrify during Pre-Stage enrollment

[rbingham917]

Hi All-

I've been scratching my head with a certain problem in my environment. My company uses Centrify to bind to Active Directory, and since we do not allow local accounts, it is imperative that the machine get bound to the domain and the user log in with their AD Account.

It has been my experience that I have to install the Centrify agent then run a script to bind it to the domain. I have accomplished this by creating a one-off local account, running a self service policy that runs through installation of packages to make it domain ready.

Is it possible to have the Centrify agent installed on a machine that is going through the Pre-Stage enrollment? Or for that matter, any of my pre-requisite applications?

[RedRangerJohn]

Hi rbingham917,

Interesting chicken-egg situation. You don't allow local accounts but you need a local account before the Mac is bound to AD. I'm not sure if there is a way around this. I work for Centrify and not a JAMF expert, so I could be wrong.

Here's a hypothetical workflow, hopefully it will provide some ideas.
Device needs to be on the network for AD binding.
1. New Mac gets enrolled to JSS through DEP. 2. User logs in with a local account.
3. JSS enrollment policy installs Centrify Agent and binds the Mac to AD.
4. Tell user to log in with AD account going forward.
5. Run script to delete local account.

[gachowski]

I think so not 100% sure of what you are asking but this might get you started

http://community.centrify.com/t5/TechBlog/How-to-Deploy-the-Centrify-Mac-Agent-through-JAMF-Server-Suite/ba-p/24145

And here is one link from jamf nation that show some details

https://www.jamf.com/jamf-nation/discussions/10338/deploying-centrify-via-casper

I know it's not this easy but it should be a start. We bind to AD with the native plug in and there is no local account.

C

[Dinnerticketboy]

Also, don't use a local account, but create a AD service account for the task, dependant on your companies policy, service accounts don't need to change their password every now and again.

[rbingham917]

@RedRangerJohn That's pretty much what I'm doing now, but with a pre-stage created account. I'd like to have the end user create an account, but my script-fu is weak, and I don't know how to write out/make a policy of "Delete the account that was just created".

@gachowski - My issue is not that I cannot install/deploy the software. I've got a script for that, which is working swimmingly. I was more wondering if there was a way of having it install during pre-stage enrollment. My current workflow goes: 1-machine runs Pre-Stage, creates throwaway account, no other account creation
2-account signs into Self Service (IF there is a way to force it to open ONLY that application when that account is in, that'd be immensely helpful) and runs a policy that triggers a set of policies to get it "domain ready", i.e. Network Access Control, security apps, and Centrify. 3- Forced reboot from Symantec Endpoint Protection, runs policy at logout to remove that local account. 4- Client logs in with network account, all is good in the neighborhood.

If I wasn't beholden to corporate demands, this would be immensely simpler. sigh

@Dinnerticketboy Based on your suggestion, if the machine is not on the domain, how would it utilize that service account? Could you expand more or give an example?

[gachowski]

@rbingham917

Are you using DEP?

If you are not, you should be able to do everything in the prestage.

1. Install all easy software Casper imaging

2. Install all hard software like SEP you just need to check the box in Casper admin to "install on boot drive after imaging. This will reboot the machine after Casper imaging runs and run a jamf 1st log in script that creates a temp account to install the "hard software" like SEP.

3. Run you scripts "At reboot" in the prestage with Centrify one being last. The scrips run in alphabetical order.

We do something like this with AD.

C