JSS & Centrify to manage Macs

AVmcclint
Honored Contributor

Centrify was purchased before I got here with the intent of having all the Macs using it to join Active Directory and receive some management in addition to all that Casper provides. It was never deployed and I've been nudged into moving forward with it. I have no experience with Centrify but from what I've seen, it looks to be a duplication of efforts. Why would I want to use Centrify AND JSS on the same computers? I don't like the idea of using AD group policies to manage Macs.

Is anyone out there using both? How are you using it? Is it worth the effort? Does it cause any problems? Do I need to be an Active Directory guru to properly do this?

20 REPLIES 20

easyedc
Valued Contributor II

We used to use Quest AD plugin, which did/does the same thing as Centrify (I think from the demo's I've gotten by their sales people). It was sold to us before I came on board and pushed for JAMF. It allowed our team which managed GPOs to manage ALL workstations. Casper integrated much better, and being a product specifically designed for Macs, was an easy sell. The big sell from moving away from that management was that JAMF could house all info/management/settings/encryption for Macs, where as not using it just adds layers of complications.

djwojo
Contributor

I'm not sure there is a valid reason left for AD specific management software when the bind configurations can be made in most MDM style systems now. I would be interested in knowing them other than, "We bought it."

Taylor_Armstron
Valued Contributor

We actually are using both, because Centrify offers ONE major thing that Casper does not: Smart card logon.

We've had Centrify in place for a couple of years. it... works. It is better than nothing, and it IS nice in that it allows non-mac savvy admins to create GPOs in a familiar environment. Our biggest issue with it is that extending beyond the "canned" options is more difficult, and it essentially turned the Macs into our "canaries in the mine shaft" for AD issues. Replication issues between DC's = Macs out of sync with each other, different versions of GPO's, etc. It also does essentially nothing for software/patch management, while Casper does.

We've just started moving forward with Casper, we're starting with software management and then moving all of our configuration baseline over except for the smart card policies, as we're required to use them for logon.

You don't need to be an AD guru, but you DO need to know the basics. Areas of conflict = mostly startup/login/logout policies. If you have both products trying to manage this, it basically becomes a race - whichever system gets there first on the client wins and trumps the others.

In short... it isn't a bad product at all, but has its limitations, and unless you have a very specific requirement that Centrify addresses and Casper does not, there isn't a whole lot of reason to use both.

psliequ
Contributor III

Organizationally, if you have a separate team that manages AD and GPOs they might use Centrify to send down their own management preferences which you could overlay with additional preferences from Casper (be careful to avoid preference collision though.) They can then say on paper that all computers bound to AD have such and such GPOs applied from a compliance perspective.
Even if you don't end up applying any GPOs via Centrify it can be nice to keep in your back pocket just for performing client side binds. It tends to work quite well in complex AD forests. It is, however, yet another product to validate against new OS releases. Tradeoffs...

tknighton
New Contributor II

Just started with a company using this setup.

Not really happy with it.

AVmcclint
Honored Contributor

Currently we have an overabundance of agents and clients installed on all the computers fighting for CPU cycles. Not only does desktop performance suffer, it also severely complicates troubleshooting when something goes wrong. Centrify seems like it would be yet another agent that would contribute to these problems.

I also don't want the Windows admins thinking they know how to manage Macs when they barely know how to power them on. In that same line of thinking, I know they wouldn't want me tinkering in AD potentially screwing up GPOs for the Windows machines.

r0b
New Contributor II

My company is big on having all of the Macs joined to AD, so we use Centrify for that. I just completed enrolling our 100ish Macs into Casper and although not much has been configured, I have yet to encounter any problems between the two. We push policies such as the lock screen via GPO and a couple others as well but most of the policy management I plan to do on the Casper side.

I'm curious as well to hear of others with this setup and what issues they have seen.

PeterClarke
Contributor II

We have Hundreds of Macs bound to AD, across a complex network..

We don't use Centrify - We just use the built-in tools.
Currently we mostly use an AD-Bind script, that works very well.

But are starting to toy with using Casper Built-in AD Bind, with a view to simply using that..
Early tests so far showing this also works OK with Casper 9.81
Though we will need more extensive tests before we can definitively phase out the bind script.

It's not clear what advantages - if any - that using Centrify adds..
Although we do have an issue with mounting OLD smb1 storage, but that's being phased out..

Just wanted to say it's perfectly possible to reliably bind to AD
without having to use a 3rd party product such as Centrify..

AVmcclint
Honored Contributor

We've been using the built-in AD tools to bind all our Macs to AD (via Casper) and it's worked just fine. We've never had a problem with that.

davidacland
Honored Contributor II
Honored Contributor II

I've had a few sites using centrify for AD logins and in one case for mac management. I haven't seen Centrify and Casper in place for Mac management purposes in one site. IMHO that would be a duplication of effort.

steveevans
New Contributor II

We use casper for AD binds...But haven't been binding the machines as there really isn't any need for us to do so with Casper serving out policies.

Looking for one suggestion as Centrify has been mentioned here and we have been told it will solve this issue by their sales team.

Complicated AD forest with trusts...basically need macs to authenticate to a cross-forest trust, but not be member objects of that domain. So I was thinking LDAP authentication is the best bet. Centrify says they can make the AD bind work with a pseudo Loop-Back style GPO (such as you would use with Windows clients getting GPO's on domains other then the one authenticated to).

Anyone have familiarity with this style situation?

JPDyson
Valued Contributor

@steveevans Yes. Exactly that, actually. Disjointed namespaces, unidirectional trusts, loopback processing - all of it. It works as advertised, by and large. I was getting ready to comment that Centrify does help in this kind of setup.

That being said, if you can convince your org to let go of AD binds, Apple's own Enterprise Connect promises to solve your authentication woes, and Casper already solves your config management and deployment workflows.

NUREG
New Contributor

Hi there,
we come from the other side, that means we manage our Macs with Centrify and GPOs. We just came across JAMF that we are currently testing, because we need a patch and deploy management that goes deeper than standalone ARD. As far as I can see, I have no easy way in JSS to tell specific Computers that only specific members of an AD group have the right to log in. We have this scenario in some of our departments, and it is highly necessary. Also we found no way to access the AD groups (Users and Computers) to work with in JSS. Is there a way to do so?
thanks
OH

Sachin_Parmar
Contributor

Hi @AVmcclint, I'm currently rocking the same boat, and have completely decide to move away from Centrify to Casper, you can find a script that we wrote on how we moved/moving from one to the other here. Centrify in my opinion is great for managing Mac's if you're a Windows administrator as writing GPO's are common. In regards to the AD binding I use a Smart Computer Group based of naming convention and then binds the Mac natively after the EnrollmentComplete flag is triggred.

KatieE
Contributor
Contributor

@NUREG

... tell specific Computers that only specific members of an AD group have the right to log in

Hello Oliver,

I believe this functionality can be achieved by way of a Login Window configuration profile:

549114c930024dceb7de416b9f9f492d

Cheers,
katie

NUREG
New Contributor

@Katie ,
thanks for the response. I'm aware of this profile, but in this case I've to maintain my users and groups twice.
Once in the AD in order for share access via group privileges, and then in JSS for the login profile. This ist double the work, for the same result.
best regards
OH

KatieE
Contributor
Contributor

@NUREG Once Centrify is out of the mix, are your computers still binding to AD via native OS X plugin? Is AD integrated with the JSS via the LDAP Servers settings? If so, then there is no need to replicate group structure. The JSS would be reading the same group membership that the computers are during login.

Cheers,
katie

hunter99
New Contributor

The only thing we would want here from Centrify is smart card login. The rest of the management can be left to Casper. If there is a way to do that I would be happy. It used to be that Express did that but it appears it now only supports VPN login. Smart Card login into AD requires the paid version and management is not going to go for that along with Casper at all.

Maybe we will look at Thursby but I think they are in the same boat.

JPDyson
Valued Contributor

@hunter99 Technically, all you need is the PIV tokend. There was a time when you could lift it from a previous version of OS X and just drop it in the Security folder and smart card started working again.

Anyway, check out a free alternative.

franton
Valued Contributor III

@JPDyson Don't count on that working forever either. Apple has massively revamped the smart card API's in OS X (as in totally changed them) so that OSS project won't work soon. I'd say more but that'd currently violate developer NDA.