Universality and Communications. The NCP Secure Enterprise macOS Client is a component of NCP's „Next Generation Network Access. Technology”, the.
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.
My biggest question about this product is it's potential usefulness in terms of DEP deployed Macs. The biggest thing holding us back from a DEP implementation is AD integration. We have many remote users who would be unable to connect to the domain to create mobile accounts.
Even for users on our domain the initial account created is still a local account so there would still be some polciy magic involved to switch them over to a bound mobile account. Would this allow us to deploy using DEP and offer our users all of the benefits of using the AD credentials without actually having to bind to our domain? How exactly does this handle the linking of their local account with their AD account? Does it enforce our AD password requirements on the local account as well or would that still have to be managed by profiles?
May have a more direct answer for you, but from the presentation I attended on Enterprise Connect, although it wasn't stated explicitly, I got the distinct impression this tool was born out of the need the Apple enterprise support team felt was needed from listening to what was probably years of complaining from customers about how poorly Apple's OS works with AD and other LDAP environments. All this is to say that it doesn't sound like Apple's upper management is interested in integrating this into the OS at this time, but gave the enterprise support folks the freedom to create, develop and promote this tool to help address this need. This is all just speculation based on 'reading between the lines' if you will. It was what wasn't said on the call that spoke louder than what was mentioned. We are in a similar boat.
I don't anticipate ever being able to convince management here to move away from cached AD local accounts for our managed/company owned Macs. DEP makes that very challenging because of how its designed around setting up a local account. DEP is really more about using the OS OOB and getting it enrolled into management, rather than getting them joined to AD or using AD accounts. While I can see the possibility of it still being done to use AD, boy it would be incredibly tricky.
Policy magic indeed! Enterprise Connect is a product of Apple Professional Services. Please file a feature request or a bug if you’d like to see it added to the operating system or distributed in the Mac App Store. In your case, you'd use Enterprise Connect after you've gone through setup via DEP and make a local account. You'd use a profile to manage password policy on this local account.
You'd then launch Enterprise Connect and sign in with your AD account. Once you did this, Enterprise Connect would get you a Kerberos TGT, check your AD password, etc. Enterprise Connect does nothing to make your local account a mobile account - it just lets you do some AD type things like Kerberos from a local account. '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.'
I'm afraid these features aren't too valuable. Current AD integration allows for password expiration message upon login.
Mapping drives automatically is pretty simple. Unless it allowed for me to manage specific variables on the mac (group policy style), I don't see the value. Sounds like a money grab to me. This kind of stuff should be included in the base OS. I'm afraid these features aren't too valuable. Current AD integration allows for password expiration message upon login. Yes, because Mac users log out and log in all the time, don't they.
Sorry, but while I agree maybe this shouldn't cost $5k, being able to be notified of pending password expiration while logged in is not exactly useless, so I can't really agree with you there. Also, it shows you your account information within a menu item, so its pretty handy for users to be able to access this. Lastly, I got the impression professional services is open to adding new features to the product as they go.
Its kind of new. All, thanks for all of the questions and feedback. I'm responding as quickly as I can, so please be patient:) - It is true that current AD integration allows you to change your password at login. However, this depends on two things.
First, your user must actually log out and log in to be prompted. Many users don't do this on a regular basis. Logouts consist of closing the lid and logins consist of entering a screensaver password.
Also, the user must have a network connection at the login window for this to work. Unless you are using Ethernet or system level wi-fi authentication, many users won't have this in place. Regarding network shares, there's a variety of ways you can mount network shares (login items, scripts, etc). Enterprise Connect is different in that when these shares get disconnected, like when you leave your corporate network, Enterprise Connect automatically remounts them when your network comes back online. I should also add that Enterprise Connect is delivered as part of a Professional Services engagement. The price is $5500 and includes 2 days onsite with one of our engineers. Travel and expenses are included as well.
During this engagement, we test Enterprise Connect on your network and make sure it is working properly. Some customers have unusual AD configs, etc that we need to adjust for. We also give you a 'deep dive' on the tool itself, help you decide how to deploy it, etc. With any remaining time, we can help you work on any other issues or questions you have about your Mac deployment (as time permits).
Thanks, it's great to see Apple opening up their communication with its community! I first heard about Enterprise Connect two weeks ago and almost thought it was a scam:-) I'd love to see it in action. As I'm in Europe, I extended a bit pmbuko's KerbMinder to make it work without being bound to AD. I hope we will integrate things a bit further and involve the community to make something better, has a good idea here. I cross my finger to have EC released someday either in open source or in the OS. HI, Remember your name from a few years back, at a company where we used some Apple Pro Services- Nice to see you're still at Apple. Does free users from needing computer objects being created in AD?
So far, it seems like the solution is best deployed in a DEP environment, but is there something that makes it worth using in an environment where we are used to binding? (I know Apple is pushing DEP big, but not every solution is necessarily benefited by it). I also echo what others have said about it being open source and/or part of the base OS. I dislike the lack of information about it out there, but appreciate that you are reaching out.
Wow, that was quite awhile ago, good to hear from you! If you use Enterprise Connect on an unbound system, there is no need to create a computer object in AD. There's also no process you need to go through to bind it to a domain. You just feed it a domain name, AD username and password and you're good to go.
If you use it while bound and logged in with an AD account, it ensures you always have a Kerberos ticket when you're on the corporate network (wi-fi and VPN included), you get notifications when your password is going to expire, you can use Enterprise Connect to change your AD password, and it eases the management of network share points. I sat in on a demo of Enterprise Connect about a month back, and one of the things I recall about it seems important to mention on this thread. In relation to what you posted with: You just feed it a domain name, AD username and password and you're good to go. If I recall now, most of the same holds true for when using it on an AD bound Mac and logged into a cached AD mobile account, meaning, you still must feed it a username and password to configure the application (or is it only the password now, I can't recall) But essentially, it will not read the AD account's information and automatically just work. The client still must enter their credentials at least once to configure it for use with their account. I do seem to remember that it has the ability to accept Configuration Profiles for setting up some of the items though. Maybe that's something you can elaborate on a little when you can, since I'd imagine many folks here would be interested in hearing about the configurability of the application.
We're all about automation here after all. You're correct on both things.
If you're logged into your Mac with an AD mobile account, it'll pick up the username and domain at first launch. The user just needs to enter their password and sign in. They don't need to sign in again unless their password changes or there is some problem with their AD account.
For the most part, once its set up, the app runs in the menu bar and does its thing without user intervention. Users will just see the color of the app's icon change. It's yellow when your Mac isn't on the corporate network and green when it is.
And yes, the application can also be configured with a configuration profile. You can configure most settings using the Custom Settings payload of a profile. Casper does a great job of deploying this profile. Yes, EC does the right thing when a setting is configured with a profile - the configured settings get disabled in the UI so the user knows they cannot be changed. Speaking of automation, Enterprise Connect can also execute a script whenever it goes through its connection process. We intended this to be used to audit a system prior to connecting.
Think of something like host checking in a VPN client. For example, you could write a script to check if FileVault is on. If it's not on, and the script has an exit status!= 0, Enterprise Connect stops the connection process, tells the user their system isn't compliant and to call the help desk.
Really though, you could make the script do whatever you want it to. The only catch is that the script runs as the logged in user, so you can't do anything as root. Bonus item - the app is also AD site aware.
EC chooses a random domain controller when doing a site lookup, but once EC has determined your site, it uses local domain controllers for LDAP queries, Kerberos, etc. Again, your Mac does not need to be domain bound for this to work.
It would be fantastic to see this outside of the US soon. I spoke to our Apple SE here about Enterprise Connect as we currently develop our own tool to perform these functions. If there is anything we can do to help untie it from Professional Services as we do not have this service in Australia please point me in the right direction. I know that many other Universities here would be interested based on the discussions we have had around our in-house tool.
Is the WebEx available to people outside the US? All, Thanks a lot for the feedback so far. We've been staying on top of OS releases. For example, with El Capitan, EC was ready to go well before it shipped. That's our goal going forward.
By 'keychain issues', I assume you're talking about the Keychain password falling out of sync if a user changes their AD password somewhere other than their Mac. If a user does this, Enterprise Connect won't get the Keychain password back in sync. However, if your user either uses Enterprise Connect to change their password, or uses a local account + Enterprise Connect, you should be okay. If you use EC to change your password while logged in with an AD account on a bound system, EC will change your AD password, mobile account password, FileVault password and the password for your default keychain (usually login).
![Enterprise Vpn For Mac Enterprise Vpn For Mac](/uploads/1/2/5/4/125423624/468522139.png)
Using a local account sidesteps the issue entirely. I think I understand some of what Enterprise Connect is about now after reading this thread and a previous one from back in June.
We are required to bind every computer to AD, and we get all our password expirations taken care of with ADPassMon. You say it can be used to mount AD Network home shares. Can it also mount all the network drives (H: M: O: Q: R.) the users would see if they logged in on a Windows PC without the user having to know the server path? Unless there's some other magic going on behind the curtain, I don't see how paying $5500 for this tool would benefit us.
And why the secrecy? Why is there no public facing webpage to explain this product? Ideally what we are hoping we can do is enter the smb mount point of our DFS server into EC. Which would be the same for everyone. The actual shares are configured in windows server per user (or AD security group) We've been working towards this (DFS) for a couple years, because to my knowledge Mac & linix have no way of parsing a windows logon script (without the help from $centrify) Unless Enterprise Connect can do this?
We are currently a 60% Windows & 40% Mac environment so I'd rather not replicate all of our shares in Casper. Very interesting development; Enterprise connect. For those that are using this technology, it only works with local accounts? Or integrates into AD/OD centralized management accounts on the Mac systems with regards to kerbinization and password syncing (similar to say ADPassMon/Kerbminder combo that others have mentioned)?
I sent a email to [email protected], haven't heard anything back yet. Our Jamf/CS rep did state it was legitimate, and sounds pretty cool overall.
But as with all things Mac. Proof is in the pudding. This is the first time I read of any of this. It sounds interesting.
Our Macs are currently bound to AD using the OS's AD plugin. We bind them as part of the Casper Imaging process. One of my biggest challenges is getting our Mac users to change their AD password before it expires. They don't log out, no matter how hard I try to convince them to.
Because of this, they don't see when their password expires, and we get situations when it expires while they're out of the office, and they're stuck for a while. Secondly, after they change their password, we get those annoying 'Local Items' keychain prompts that never go away unless we manually delete that folder from their /Library/Keychains folder and restart. Our passwords expire every 90 days, and people never remember what they need to do to reset them. Will this tool get rid of those 'Local Items' keychain prompts? Based on the first post on this thread, one of the last sentences: Enterprise Connect is only available to USA based customers Emphasis is mine. I think some of the Apple folks would need to confirm, but I read that as limited to companies that have their main headquarters in the US, not necessarily that it can only be installed in US locations.
At least I would hope that's the only limitation, since many companies that could use this would be in the same situation; US based, but have offices in many locales around the world. It probably has to do with the on site professional services visit to get it set up. Hi Matthew, I purchased it and implemented it. The “purchase” was more a 2 days contract for Apple Professional Services. The actual setup lasted an hour. APS engineers are very knowledgeable and super nice. Enterprise Connect doesn’t modify your infrastructure.
If you have a 'standard' AD setup, EC should integrate very easily. Otherwise, the 2 days might come in handy:) If you want to test before, download and install KerbMinder.
If it works straight away, chances EC will work too. To be honest, in my case, EC wasn't better than KerbMinder, and I lost the possibility to tweak it myself. But the EC team is great and you get great Apple support. Hey Yes, we use it exclusively on unbound machines. Our users barely notice it.
To be honest, they don't care. They have single sign-on, that all they want to know.
Yes, I have quite a few features I'd like to add: - remove the GUI, it's not needed and users don't like to have lots of icons in the menubar. It feels like windows - push username and realm from a profile - use AD login and password from the one entered in SetupAssistant. I hope this will come if it ever become native to OS X - open a per-app VPN to get the kerberos ticket when outside of corporate network But again, it works great.
I work in government. Would this work with PIV/CAC enabled accounts?
Can this support PIV/CAC logins to network shares, etc. How would that work with remote users? I can use via VPN. This part is directly at Apple person that posted this.
Please bring back PIV/CAC support in the OS natively. When it was dropped Macs in government were not that much. Nowadays, Macs are infiltrating at an exponential rate.
Eliminate the 100% need for me to bind the Mac to AD and there will a whole lot more real fast. Yes, I have put feedback in on Apple page. I am just trying to get this heard wherever I can. I couldn't agree more with 's comment above. Its utterly astounding that that dialog has not been revamped by now. Its the single most confusing dialog Apple has in their OS and bafflingly continues to have in there.
I can only imagine how many complaints Apple has received over the years about this and they've yet to change it. But, you can bet Apple will have designed some new system font for 10.12, or recreated all the apps icons or something, because, you know, that's actually what's important after all. I just sat through the Web Ex on this and it seems that it can be boiled down to a few things:. The cost is really going towards having an engineer onsite for 2 days. It helps sync local items (keychain) to what the AD password is. Reminds to change AD password without logging out.
Maps drive. Can trigger scripts to run It doesn't necessarily seem like a game changer or a magic bullet, but a nice little in-between for the computer and the domain controller.
Anyone that has purchased this at their organization verify this? Is there a solid benefit in implementing this? We purchased EC and use it on all of our Domain bound Macs. Our users seem pretty happy with the tool as it syncs the Keychains with the AD password at time of password change with out having to logout and log back in. I also like the fact that if you are not on your corp network it will give you an alert saying to connect to corp network first before trying to change your password.
It also mounts the network drives after the login has happen and the user gets control of the screen, so this doesn't tie up or slow down the login process, which I have seen when trying to map drives at login. Furthermore, it gives a nice pop up in the notification center letting users know their password is going to expire. The only thing that we still have issues with is Macs falling off the domain rendering EC useless. So I wrote a long script that checks if the machine is bound to AD, if the AD keychain is present, and if the machine is actually still in AD. If any of the test fails. It launches my AD binding policy to rebind the machine to the network.
I have this script run once a week on all machines. Hope this helps out!!! I've called and emailed as well and have never been able to get anyone at Apple to contact me. Considering that we are a huge enterprise company - and we PAID for a Readiness Review 2 years ago (we received the report, but my requests to schedule the actual presentation were never returned) my management is not very happy with Apple. We keep getting reassigned to different reps and engineers and basically it is a fight just to allow Apple products in the environment. If Apple really wants to start supporting their enterprise customers, then they might want to actually start supporting their enterprise customers.
We purchased EC and have been playing around with the configs a bit, a couple of things we learned. EC works better when changing AD pw's directly against a dc. We us a web portal for the users to login and initiate a pw change that eventually filters down to AD. We knew going into the purchase we couldn't use EC to change a pw directly, but it does pick up and alert the user when it detects the AD pw is different than the EC pw, and prompts for change. Because we do not change the pw directly in EC, we miss out on it updating the keychain passwords, and I think even the FV2 pw.
We are still trying to see how we can interject a script to run during that prompt for password update, but it as of now it appears the only scrip triggers are at network state change or password change. Hopefully we'll have more time to finalize this in the next month or two, I'll update the findings as we go along., would it be ok to post/share the Enterprise Connect documentation for people to review? Correct, our peoplesoft/idm environment serves as the master and changes flow down to AD. I'd be interested in more details of how you're doing that for your env. Our portal has 2 factor auth in play, so it might be a whole new level of fun. Oh, I forgot to mention that EC has us looking at switching from domain account logins to local again, with EC managing the pw sync to the local account.
We've lived a nightmare of keychain issues when the AD pw is changed and users can't unlock/sync up their keychain properly. Also with so many wireless users, and our wifi requiring auth, which is not available at lockscreen, they were in a world of hurt if they changed their pw and couldn't wire into the network to login afterwards. Hoping the local account will alleviate some of those pain points.
Oh lord, two factor would be.fun? Is it just username and then the token for auth and then asks for the new password? Or does it need token, old password and then new password? Theoretically possible to prompt for that first factor and post it for them but not sure how worth it it would be.
I would highly recommend using local accounts and having EC take the place of AD with password sync on. As far as our portal, its just AD auth and once you're able to log in it will then trigger the sync. So, for me its just a simple http post. I have a loop that keeps trying the new AD creds against that form until it gets back a good result.
It will bail if it tries too many times, though. 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. 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. Order DEP enabled Mac.
Power On. User logs in with AD credentials. JAMF agent gets deployed. System reboots. FileVault encryption is enforced.
System reboots. JAMF wraps up deployment (this includes a hostname change to meet NetBIOS 15-character limits, VPN client and Apple Enterprise Connect). The user connects to VPN. The user clicks a 'Bind to AD' script within Self Service. 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. Order DEP enabled Mac.
Power On. User logs in with AD credentials. JAMF agent gets deployed. System reboots. FileVault encryption is enforced. System reboots. JAMF wraps up deployment (this includes a hostname change to meet NetBIOS 15-character limits, VPN client and Apple Enterprise Connect).
The user connects to VPN. JAMF detects a network state change. Some scripts run to test the validity of the connection.
AD binding takes place behind the scenes. 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! 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.;-). 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. 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.
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. 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? Apple EC Support Enginner should continue working with you via Email/Webex/ect. To continue expanding your deployed EC capabilities. Yes: Simple network paths that all users use smb://shareserver/shares/ is really simple to setup & just works. 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. 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. So.Enterprise Connect (EC) and no AD Binding.and HR/Legal/Security phone call to lock out an AD account.go. If a user's AD account is locked out as per HR/Legal/Security, how does EC behave when the user returns from lunch, and during their lunch, their AD account was locked out?. If a user moves to another Mac where they logged on before, and their AD account is locked out, will they be able to log in to the locally cached account (mobile account)?. If a user knows he/she is locked out of their AD account, are they able to walk over to a computer they logged into before, unplug it from the network, and log in with their last cached password?
Read: circumvent AD lockout. We haven't gone down the EC road, figured I'd post here rather than wait for the next monthly EC web meeting, where the question might not get answered, or might lose context if follow up questions are not possible. If this file $HOMEFOLDER/Library/Preferences/com.apple.Enterprise-Connect.plist doesn't exist then Enterprise Connect has never been logged into.
Key off of that but I'd actually take it a step further and even if the prefs exist verify that it is actually connecting. Defaults read $HOMEFOLDER/Library/Preferences/com.apple.Enterprise-Connect.plist dateLastConnected And you can easily convert that to epoch for easy comparison and see if they've check in in the last X days timeStamp14dBack=$(date -v-14d -u +'%s') dateLastConnecedEpoch=$(date -j -f '%Y-%M-%d%T' '$($HOMEFOLDER/Library/Preferences/com.apple.Enterprise-Connect.plist dateLastConnected cut -d ' ' -f1,2)' '+%s') if $dateLastConnecedEpoch -lt $timeStamp14dBack then echo 'they have connected in the last two weeks. Good user' else echo 'they have not in a couple weeks. Hi, I posted this question last week, and I just notice this post today so I thought I should ask the same question here: Apple Enterprise Connect - System Clock - Your Mac's date or time is incorrect.
I'm using Apple Enterprise Connect 1.7.1 I normally don't log out. And when I log back in from 'sleep mode' I'm getting this popup after I log in: 'System Clock - Your Mac's date or time is incorrect. Please correct this issue and try again.' Time is set to 'time.apple.com' and when I get the popup I see the time and date is correct. I just click 'ok' and on the 'EC' icon I right click and select 'Reconnect' and it connects fine. Any thoughts on how to resolve this? What I have is a 'Smart Computer Groups' with a Criteria=OS - Verify Time Server, Operator=like, Value=Fail if it finds a 'Fail' for the time it automatically applies a policy with a really basic command: #!/bin/sh systemsetup -setnetworktimeserver time.apple.com Has anyone seen the same 'issue' on EC version 1.8?
User schultza posted this: Posted: 10/27/17 at 7:47 PM by schultza This might be related. Time on Macs has been allowed drift since 2013. Apple is no longer using NTP directly from source, it's been changed so that time updates itself less frequently; as I understand it this was done to save power. I have a policy that runs that syncs the time once a day with our local NTP server. This might not be your issue, but I've seen strange time problems with machines coming out of sleep related to this. /usr/sbin/ntpdate -u serverurlhere Alternatively you can compile NTP from source if you want to.
I haven't dived deep into the EC 1.9.0 beta but I'm wondering if there's any plan to leverage EC or possibly built-in support for offline mobile account logins with SmartCards. My company is planning a transition to full PIV SmartCard multi-factor authentication and I was pleased to discover fairly robust support for this in 10.13.3 (my Windows counterparts struggled with this mandate for months and I got a working demo up in one day). The only feature that doesn't exist is the ability to log in to AD-supplied mobile accounts off-network. I've heard that apps like NoMAD might be able to provide this ability but since we already have EC I figured I'd see if it was something that was coming or maybe that could be bashed together with EC and Ticket Viewer or something.
And This is what I ended up with. Hi we have had Enterprise Connect deployed for some months, but today I had a chance to be a user.:) My password expired.oops.sorry Enterprise Connect, I ignored you (it was busy I swear!). I called our Help Desk and asked for a temporary (one time use) password, they gave me something easy to remember like 123Oopsie. I was logged in with my old password OldPassword01 (sanitized!), so I rebooted my computer to start a test. Computer is now up, I'm at the FileVault 2 pre-boot screen, and my old password OldPassword01 works as expected. I'm taken to the macOS Login Window, where I'm prompted for my password.I enter the temporary (one time use) password 123Oopsie.
I'm prompted to change my password, which I change to NewPassword01 (sanitized!), and I'm taken to my Desktop. I reboot the computer, to see if Enterprise Connect syncs my new password NewPassword01 with FileVault 2. I'm back at the FileVault 2 pre-boot screen, my new password NewPassword01 does not work, but my old password.OldPassword01 works. I'm taken to the macOS Login Window again, where I'm prompted for my password.I enter the new password NewPassword01. I reboot again. I'm back at the FileVault 2 pre-boot screen.
I enter my new password NewPassword01, I'm taken to my Desktop. It appears the second reboot resulted in my new password NewPassword01 syncing to FileVault 2. SUMMARY: The above is a possible scenario where a user has a brain fart (guilty!), forgets to change his or her password, and goes through a Help Desk temporary password scenario.does this scenario represent what a user should expect to go through (um, pretend the user did NOT have a brain fart but for some other reason didn't change his or her password before it expired.
Just wanted to check before we start having techs repeat the above steps, to see if this is another article we need for our Help Desk to be aware, and to inform users. Yea, I learned this one the hard way. During our last major onboarding, I ended up having to make a mad rush to User Approved MDM (Yes, you've all been telling me for a while now) and ended up using EC credentials to recreate new BYOD users pre-existing local accounts using AD usernames and passwords (Brilliant right!). A number of new users ended up rebooting before the FV2 sync and were presented with the old FV2 Username (Account technically Deleted). When they logged back in with those credentials, the OS was kind enough to create them a new, FV2 Approved, empty user account. A few users showed up very concerned that all of their stuff was deleted!
It was simple enough to get the users back into the proper account and fix the FV2 users list, but it was very awkward. More interesting were the users I had to track down because they simply didn't seem to care that all of their files disappeared!
Hello All - thank you for sharing all of this (especially @donmontalvo for the plist example for adding shares via a Profile). Silly question - is there any publicly available documentation for Enterprise Connect? I inherited a configuration and would like to review/modify our EC audit script but cannot find any references to this online. Or is this a situation where we need to contact Apple for support? We purchased EC previously but have no support information that I am aware of. I appreciate any guidance or ideas. Thank you again, -Neil.
I’m surprised to see this thread still running. This is something I’m rather passionate about. But I disagree with using any additional tools for AD and DFS integration. Windows integrates just fine into AD and uses DFS just fine and yes I get it windows in a windows world. They do not have a 5k tool for enterprise level integration. I don’t see why anyone should be asked by apple to pay for something that should be native in the OS if apple hopes to compete against windows and Linux for corporate desk space.
The added costs of these tools is largely what turns off our company from accepting more macs into the environment. On that note, I have had considerable trouble with SMBv3 and Windows DFS servers 2012 and later. Seems smbv2 however resolved those issues. And on AD binding, jamf gives you the tools to detect when a Mac drops off the domain and execute a rebind. That coupled with preferred DC ( if your company forgot to assign VLans to DC's) adding the proper search domains in order (if you have multiple domains) and a script for Kerberos renewals and you should be set. My kerb ticket renewal is currently manual but auto renewal is something I do want to look into time permitting especially since the Biometric scanner on Mac does not renew your Kerb ticket, only a login by password does.
However it appears connecting to a DFS share does also renew a Kerb ticket at least for the newer OS releases. Oh and of course everyone’s favorite, turn off smb signing in nsmb.conf and block.DSStore files on DFS shares to get a speed boost and help prevent file locks. And it seems it’s only Apple with these issues. Though I do not have personal experience with running Linux in our environment I do know they don’t report these issues when bound to the domain and surfing the dfs on redhat. Seems Mac specific SMB stack just isn't fully baked like it should be.
I will stick to the hard way, it seems to be more reliable for us than another app to buy and update every year. I'm surprised this thread is still going - still interest in this., or, anyone else on here. I'm looking to use some bits of Enterprise Connect into a 'Computer Info' script I'm using. (Computer Info script came from here: I would love to bring in the part from Enterprise Connect that notifies the current user how many days until their password expires into the Computer Info script. In that link I provided someone else mentioned that they implemented EC with the Computer Info script, however, I'm unable to get it to work.
Does anyone know what script I would use to call the current user information and to output how many days until their password expires? Thanks in advance for your help!