About Enterprise Connect

rjlemmon
New Contributor II

Hi all,

This is Rick Lemmon from Apple Professional Services. I'm happy to answer any questions you have around Enterprise Connect. For those of you who are unfamiliar with the tool, it provides a good level of Active Directory integration for Macs that are not domain bound. It also enhances AD integration for Macs that are domain bound and have a user logging in with an AD account.

Enterprise Connect is simply an application. Once it has been set up, it resides in your menu bar. Specifically, Enterprise Connect provides:

Kerberos SSO support: Enterprise Connect includes a built in Kerberos client and ensures that your users have a Kerberos TGT.
Account management: Enterprise Connect notifies your users, via Notification Center, when their AD password is about to expire. They can change their AD password right within Enterprise Connect.
Network shares: Enterprise Connect can mount network shares, including your AD network home and any other SMB or AFP shares you'd like to mount.

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.

Enterprise Connect is driven by network state changes. When a state change occurs, Enterprise Connect checks to see if your corporate network is available, and if it is, it will acquire a Kerberos TGT, check password expiration and re-mount your shares if they have disconnected. It is also triggered by wakes from sleep and in a couple of other situations.

There's also a lot of other useful features (configuration profile support, can run scripts, etc) but for the sake of brevity I'll leave those things for later.

You may be asking "How do we get it?" or "Can I see a demo?". Please contact your Apple account team for more information on these subjects. Also, Enterprise Connect is only available to USA based customers.

I'll be following this thread, so please respond with any questions.

243 REPLIES 243

wmckin
New Contributor

@ice2921 - Just stumbled upon this, looking for updates to this exact issue. The short of it is no, Enterprise connect doesn't support AzureAD integration; at all. I was hoping to see functionality similar to Windows 10 where I could log in with Azure AD creds on the OS but alas, it's not there. I spoke to both MS and Apple about this and the onus is on Apple to develop the solution. From what I was told from Apple, this isn't even roadmap. To save you some time, I also tried falling back to LDAPS served from AzureAD and enterprise connect wouldn't even leverage that. It's unfortunate but hopefully things change.

lgt28jr
New Contributor II

@rjlemmon We purchased Enterprise connect almost a year ago and I am wondering if there are any version updates to the App. The version we have now is 1.6.1 (4)

bradtchapman
Valued Contributor II

@lgt28jr : Your should be reaching out to your Apple business rep for updates. ;-)

The current version is at least 1.6.4.

spalmer
Contributor III

@lgt28jr You should be receiving emails from the Apple Professional Services group when updates are available.

After we went through the required two-day onsite for the purchase we gave them our email addresses (actually a mailing list in case we ever need to change who the contacts are) and we have received emails for every version update since we purchased it, which is about a year ago for us as well.

lgt28jr
New Contributor II

Thanks I thought we did the same. About 10 minutes after posting this I received an Email from Apple Professional Services with the latest update. How's that for service wow!!! I also gave them an alias to use so this has been resolved.

ccarlton
New Contributor II
New Contributor II

Next EC demo Monday, May 15, 2017:

APS Enterprise Connect Demo 25
Monday, May 15, 2017
10:30 am | Central Daylight Time (Chicago, GMT-05:00) | 1 hr 30 min

http://tinyurl.com/ECDemo25

edickson
Contributor

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!

Stephen_Perry
New Contributor III

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

edickson
Contributor

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!

Stephen_Perry
New Contributor III

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

clarachao
New Contributor

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.

See_Understand
New Contributor

@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?

cainehorr
Contributor III

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!

Kind regards,

Caine Hörr

A reboot a day keeps the admin away!

jhuls
Contributor III

@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.

cainehorr
Contributor III

@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. ;-)

Kind regards,

Caine Hörr

A reboot a day keeps the admin away!

jhuls
Contributor III

@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.

cainehorr
Contributor III

@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.

Kind regards,

Caine Hörr

A reboot a day keeps the admin away!

cainehorr
Contributor III

@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)

Kind regards,

Caine Hörr

A reboot a day keeps the admin away!

jhuls
Contributor III

@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.

fseaton
New Contributor

Does EC require JAMF to configure for a single workstation?

merps
Contributor III

@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

rderewianko
Valued Contributor II

I agree nomad is the way to go.

fseaton
New Contributor

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.

rderewianko
Valued Contributor II

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.

Stephen_Perry
New Contributor III

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.

fseaton
New Contributor

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!!

Reboot2611
New Contributor

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

JSnell
New Contributor

@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.

Reboot2611
New Contributor

@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

Kedgar
Contributor

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!

Tigerhaven
Contributor

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

Kunal V

Kedgar
Contributor

@Tigerhaven Thank you so much!

milesleacy
Valued Contributor

My 2¢...

As an Enterprise Connect customer, I find that the engagement pays dividends that far outstrip the cost or time involved or the feature set of the Enterprise Connect app.

Through the engagement, we learned how and why Enterprise Connect works, as well as a deeper understanding of the macOS AD tools.

As Jamf customers, maybe think of it as an 'AD jumpstart' that comes with a free app.

cainehorr
Contributor III

@milesleacy

That is an excellent way to look at it.

As a former Apple Enterprise Connect subscriber, I would agree with your view point 100%!

Kind regards,

Caine Hörr

A reboot a day keeps the admin away!

rjlemmon
New Contributor II

@Kedgar

Just sent you my email address via LinkedIn.

Chris_Hafner
Valued Contributor II

Having completed engagement, we are now happily running Enterprise Connect within IT and are prepping for a full rollout. Considering how well this is currently working, I'd love to see this get built into the OS later!

scottb
Honored Contributor

@Chris_Hafner - having to support a new client with this. Have you seen any issues with FV and password changes? I don't have a lot fo info yet, but they are trying to escrow personal FV keys into JSS and there's some mention of the passwords getting out of sync not unlike AD accounts if you change the PW on a website, etc.
Don't have a lot of info yet, and you likely don't either, but I have no hands-on with this yet...glad it seems to be working for you.

Chris_Hafner
Valued Contributor II

What specifically are you hearing about? So far in my testing, FV accounts and recovery keys work just fine. Personal keys are being properly stored and are usable at least in my limited testing. I'll have to test on the bench and get back to you.

paulschatz
New Contributor

Whom would I get in touch with at Apple to get more information about an engagement for EC? I have sent a few emails to consultingservices@apple.com, but I haven't received a reply. Thanks in advance.

Chris_Hafner
Valued Contributor II

Grab your Apple Rep or contact Apple Professional Services. They can sort you out.