Hi Everyone!

So I'm working at an enterprise company that deployed EC a few months ago. What we're noticing (especially for remote users) is that if their Mac has fallen off our AD domain, EC will log in but will not allow a domain password change. If we re-bind the Mac to the domain (connected via VPN, of course) EC will allow a domain password change.

Any ideas as to what might be causing this?

Thanks!

This is the expected behavior of EC. The domain must be accessible to perform a password change.

Right, but from the original poster:

"It works great if you are bound to an AD domain, but again, there is no requirement to bind to the domain to use it. It works great from a local account on an unbound system."

Unless the "local account" is the key, we use AD accounts here.

Thanks!

Directory "binding" is not required, however, the directory must be accessible and directory authentication available. Two different things here.

Is there currently any way to hide the Enterprise Connect icon in the menu bar? Even with Bartender (https://www.macbartender.com/) in use, it remains persistent.

@rjlemmon - in your initial post, you stated

It also enhances AD integration for Macs that are domain bound and have a user logging in with an AD account.

But that was a couple of years ago. Is that still the case? Or is the recommendation by Apple, that when using EC, to not have your machines bound to the domain?

We are using Apple Enterprise Connect at my place of employment. Let me just say this... it's a god-send!

It allows me to deploy DEP enabled Macs to my end-user community and still have those same Macs get bound to Active Directory and leverage kerberos authentication as well as password synchronization and password expiration notifications.

Here is my workflow (more or less) for those who are interested in my zero-touch deployment...

1. Order DEP enabled Mac
2. Power On
3. User logs in with AD credentials
4. JAMF agent gets deployed
5. System reboots
6. FileVault encryption is enforced
7. System reboots
8. JAMF wraps up deployment (this includes a hostname change to meet NetBIOS 15-character limits, VPN client and Apple Enterprise Connect)
9. The user connects to VPN
10. The user clicks a "Bind to AD" script within Self Service
11. The user logs in with Apple Enterprise Connect

We are still working on automating the last few steps. My proposed automation goes a little something like this...

1. Order DEP enabled Mac
2. Power On
3. User logs in with AD credentials
4. JAMF agent gets deployed
5. System reboots
6. FileVault encryption is enforced
7. System reboots
8. JAMF wraps up deployment (this includes a hostname change to meet NetBIOS 15-character limits, VPN client and Apple Enterprise Connect)
9. The user connects to VPN
10. JAMF detects a network state change
11. Some scripts run to test the validity of the connection
12. AD binding takes place behind the scenes
13. Apple Enterprise Connect is then presented to the end user for final login

Anyway - Apple Enterprise Connect is awesome. It makes conception a wonder and child birth a pleasure!

@cainehorr I'm running on little sleep so bear with me but I'm not clear on how your process works at the beginning. How does the DEP enabled Mac let you log in with AD credentials if the Jamf agent isn't installed yet? At what point does Enterprise Connect get installed? I've never used it so I'm not familiar with the details of it although I caught part of a demo once.

@jhuls

Your primary question: How does the DEP enabled Mac let you log in with AD credentials if the Jamf agent isn't installed yet?

1st - If you have JAMF configured to use DEP, then all your Macs and/or iOS devices will receive the JAMF client as a part of the DEP enrollment process.

2nd - My users DO NOT log into their Macs using Active Directory credentials - they log in with local user accounts.

3rd - Apple Enterprise Connect gets installed as part of the JAMF deployment process.

4th - Users connect to the network either locally or over VPN. Users then log into Apple Enterprise Connect using their Active Directory credentials. This is where the kerberos authentication takes place. Apple Enterprise Connect also synchronizes the user's local user account password with their Active Directory account password. The user's local Mac keychain is updated as a part of this process.

Hope this clarifies. ;-)

@cainehorr Thanks but that falls in line with what I already assumed. In reading the workflow you mentioned above I didn't read it the same way though which is why I asked. You mentioned the user logging in with AD credentials before the jamf agent was installed. Did I miss something there?

At any rate there's been some thought put into using it. The biggest issue I've been told that it might not be best for us is that it's not designed to be used with multi-user systems. Most users have their own system but there are a few used by multiple people.

@jhuls

Ah - I see the discrepancy that is tripping you up...

Let me clarify...

When you deploy a DEP enabled device, the user must authenticate before the remainder of the initial Apple setup process will continue. This authentication process takes place either through JAMF's internal user directory or another directory service (such as LDAP); in my case, Active Directory.

DEP then calls home to Apple. Apple recognizes the devices as belonging to your company. Apple also knows what your MDM solution is. Apple calls home to your MDM. MDM confirms the username and password via your directory service. Once authenticated, your MDM tells Apple that all is well with the world. Apple reports back to the DEP enabled Mac and Bob's your uncle. It's essentially a cloud-based version of "Golden Triangle".

Here is where your missing link resides...

Once authenticated, the Apple setup process will continue and the user is prompted to create a local user account on the Mac... The username and password fields are already filled out using the credentials as submitted to DEP, but even though they "look" like your AD/LDAP credentials, they are actually just being applied to a local account.

Take note - the user can still change the local username and password at this point...

Once the user submits this info, the Apple Setup process creates the local account and the desktop rears its head.

Once Apple Enterprise Connect (AEC) is invoked, the user types in their network (LDAP, AD, etc.) username and password. AEC guarantees that the local account (regardless of username format) and the AD/LDAP account passwords are synchronized. And because AEC is now active and logged in on behalf of the network user, your Mac acquires a kerberos ticket granting ticket.

Hope this further clarifies...

So as you see, my workflow is sound... Until now, I hadn't broken down (in detail) the relationship between the Mac, Apple (DEP/APNS), and the MDM.

@jhuls

As for multi-user systems - I can't speak to that as I have not personally had to deal with that in my environment.

That's a great question for @rjlemmon (Rick Lemmon)

@cainehorr Ah, ok...that's making more sense now and, again, falls in line with what I know. Your terminology stating they logged in might be more accurate to say authenticates with AD credentials. It also threw me because we don't have authentication enabled for DEP Macs here. I simply forgot about that feature.

Either way all is good...thanks for getting back to me. It would be good to hear from someone on the multiuser aspect. I received that information from an Apple engineer but he wouldn't go into more detail other than to say that EC might not be a good solution for us.

Does EC require JAMF to configure for a single workstation?

@fseaton Enterprise Connect is configured by Apple professional services in a 2 day visit.

For just one workstation I'd look into NoMAD

https://nomad.menu

I agree nomad is the way to go.

Thanks for the quick replies. I guess I should have given more background.

We have multiple Macs, and our central IT is "purchasing" professional services from Apple to configure EC, so we will have access to EC. The question is still whether JAMF is required to configure it as we don't use JAMF to manage the few Macs we have in our area.

thanks again.

Jamf shouldn't be requried to config EC. If anything it's configured by a Plist which you could drop or install on each machine.

An MDM is not required to deploy or configure EC. EC may be configured manually or by way of a shell script. Use of an MDM (including Jamf PRO) simplifies the deployment and configuration.

Thanks, again, for the quick responses. I was assuming that JAMF wasn't required, but someone someone on campus had told me they thought JAMF was required and I just couldn't believe that was the case.

Thanks!!

Hello
Hoping for some assistance. We just implemented EC in to our environment with the help of an Apple engineer for two days and I am currently testing it with a small group of users. One of the improvement I will like to implement is mapping different network shares a user has access to by using their AD group memberships rather than user adding them in manually after EC is configured on their mac. We have an environment where some of our macs are joined to the domain and some are not.

Has anyone been able to map network shares using EC according to users AD group memberships on a non AD bound Mac?

Thanks

@Reboot2611

Yes & Sorta.
Apple EC Support Enginner should continue working with you via Email/Webex/ect. To continue expanding your deployed EC capabilities.

1. Yes: Simple network paths that all users use smb://shareserver/shares/ is really simple to setup & just works.
2. Sorta: The more complex user based shares (ex: smb://usershare/%username%/) require some special scripts to be built. We had some the EC Engineer code this out for us. Reason i say this SORTA works.. It fails to actually work the 1st time for 1/4th of my users.. And the EC Engineer is still trying to figure out why. And due to this 1 time failure the EC Agent totally doesn't work for said User until the usersEC.plist is blown away & the script is ran again to reconfigure correctly... Fun times.

Users can also add their OWN pre-mapped shares anytime they want.. unless you lock it out of their hands.

The other fun part is EC password changes work better than ADPassMon but still not 100%.. Somehow some way our users still manage to have stuff saved in their Keychain that we simply cannot fix. And also some times EC doesn't change the Users Keychain Password (Local User = AD User) this has to be resolved with a manual password reset to Keychain.

@JSnell Thank you for your reply. Is it possible for you to share the Script thats not fully working for your environment? I am not getting much assistance from my EC Support Engineer if I can get some ideas from your script to get started it will be very helpful for me. Thanks

How do I contact Apple Pro Services to start looking at EC? We don't purchase many macs, however, that is increasing as time goes on. The individuals I have contacts for at Apple have not got back to me since I e-mailed them. @rjlemmon, you still watching this thread?

Thanks!

Hi @Kedgar I have sent this link to rick and another guy. hopefully they can help you. they are awesome people