Config profiles and AD bindings

ooshnoo
Valued Contributor

Yo..

Wanted to get your guys recommendations on AD bindings and retrieving an AD certificate?

For me, there’s 2 ways to do this..

  1. Policy for AD binding, and then an AD Cert config profile.
  2. Config profile containing both AD binding and AD cert.

However neither seem to be ideal for the following reasons

  1. An AD cert would push out automatically upon enrollment, but ultimately fail because it will probably try and retrieve the cert before the AD binding completes.
  2. Unless there’s a way to scope a config profile to only push out upon enrollment only, creating a profile that contains both payloads will push out to ALL computers…ultimately joining existing computers again to AD.

Any ideas or other ways of doing it?

-A

10 REPLIES 10

bpavlov
Honored Contributor

yoo...

there's another way to do this. Go to Management Settings -> Computer Management -> Directory Bindings -> Create New.

Then in your image configuration in Casper Admin add the Dir Binding you just created. After the computer restarts from Casper Imaging it will bind itself to AD.

JPDyson
Valued Contributor

I'd add your AD binding to Directory Bindings in Casper as described above. Note that this requires you use a service account to bind your computers to AD - usually not a big issue. After that, it really depends on what you're trying to do WITH the certificate, but most common uses match to a Configuration Profile payload.

markremo
New Contributor

Was the original question applicable to User-Initiated Enrollment? In so, it appears that using Imaging to solve the problem won't help. Either way, good point worth raising awareness of.

Second thought, I don't really see the issue anymore. Do the binding via policy.

JPDyson
Valued Contributor

Good point @markremo; perhaps with that workflow in mind, you have user-initiated enrollment > AD binding policy triggered by enroll completed > smart group membership "bound to AD" > config profile scoped to smart group.

ooshnoo
Valued Contributor

@JPDyson

Thanks man. That might work for us.
We're trying to get away from imaging, so user initiated enrollment is the workflow.

bpavlov
Honored Contributor

How about this:

  1. A pkg that puts necessary certificate in /tmp
  2. An AFTER script that uses dsconfigad to bind machine to AD and calls/references the certificate in /tmp EDIT: Forgot to mention that the script would make use of the Casper variables/parameters so that the service account for binding doesn't have its credentials exposed.

You can then make this policy available on trigger on Enrollment so that only when a computer is enrolled will it be run. However, I would make very sure that the computer is on your network because obviously it will not bind to AD if it's off your network. Make use of LIMITATIONS under Scope if you aren't already.

Alternatively if the trigger Enrollment isn't sufficient and may have some holes in it then you could honestly just add logic into your script that would determine if a computer is already bound to AD and if it is simply exit gracefully without taking any further action.

Curious to know if that would meet your need for this particular workflow.

bentoms
Release Candidate Programs Tester

This is a chicken & egg issue.

@ooshnoo I guess the cert is a certificate from an AD CA?

Might be something where post users enrol, the device is bound. Then the AD Certificate profile is scoped to a smart group that contains devices based on their Active Directory status.

ooshnoo
Valued Contributor

@bentoms

Yes, it's from an AD CA, and that workflow is exactly what I did. Works perfectly.

gachowski
Valued Contributor II

So I am lost,

If you login then bind, isn't that 1st account a local account? isn't that a security issue, or at lest a large amount of set up time for support staff?

The reason I ask is that I want to do the same thing, but I can't "see" the zero touch workflow ...

C

bentoms
Release Candidate Programs Tester

@gachowski We use the AdobeInstall account & bind as part of our postflight policy which runs whilst the account is logged it & before the JSS auto deletes it.