I’m going to try to be as thorough as I can, but if you have questions or would like additional tests. I will provide more detail as I can. I have a small number of computers exhibiting intermittent issues when waking from sleep.
Some details:
Bound to Active Directory (although the bind is likely broken when the issue occurs)
OSX - 10.12.3
Machine is Encrypted
Symptoms:
When a user sleeps their machine which enables a locked screen saver, and then attempts to wake the machine, they are unable to log in using their credentials.
If they click on "Switch User" they are then able to log into their account, however, they are not recognized as an admin and can not run sudo commands or unlock system preferences.
It seems, at least with the computer I was able to get hands on with, that they can not authenticate in terminal or system prefs UNLESS they change their network connection to reflect the connection that allowed them to log in. So if they switch user, then connect to wifi, they can not authenticate in sysprefs, but if they turn off wifi, then they are able to authenticate.
When clicking "Switch User" the wi-fi appears to drop, and thus, lets them log in.
Restarting resolves the issue for some users but not others (unverified, going off user input, the machine I restarted did resolve the issue, at least temporarily.)
Generally when I see this issue, the computer seems to have become unbound from Active Directory. Re-binding it appears to resolve the issue temporarily (until AD drops the keychain item again).
The issue was present prior to upgrading to OSX 10.12.
It seems to me like the computer knows to check with AD if the internet is available, but if AD is unreachable or the credentials are not accepted, then it does not know to default to the local cache, unless the internet is turned off completely. I'm not sure what file or files may be involved in that, but I would like to change that file to default to the local cache when internet is connected but AD is unreachable as well as when no internet is present.
This is an issue with the opendirectoryd daemon which bugs when trying to bind with AD.
The raw solution is basically to kill the daemon which will restart and rebind somehow.
There are many ways to automate the kill, a cronjob would work but will require to have the killall command run every minute, which is very dirty.
I am using sleepwatcher (available with homebrew) and set it to launch the kill command everytime the laptop is going out of sleep, which works like a charm.
It's a workaround, but seems Apple doesn't really work on a fix for that issue which is ongoing for years.
Related
I'm troubleshooting an issue having to do with Think N Do and Windows 7. I set the DCOM settings up as the manufacturer said they need to be. However, computers aren't connecting to each other. I have the computers set to automatically log on to an account at boot. This account is never logged out of.
What I'm finding is when I open a RDP to the computers they suddenly start to communicate with each other. As if it's finally seeing an interactive user. From my understanding of things by having an account automatically log on at boot that account is then the interactive user. Leaving RDP open at all times is not an option. Sometimes the customer forgets and closes out of the RDP session by Xing out of it, they don't log off so the program is still running in the background.
Does anyone have any idea what this could be? It's an issue at a couple customer locations for me.
So I've poked around looking for something like this for a while now, but can't seem to find anything anywhere. In our environment we have a script that disables computers after the last seen AD property on a computer is beyond 15 days. Since we are a mostly laptop environment and people frequently are not connected to the network when they login, the computers once they lock/unlock when eventually do get connected to the domain gets a trust relationship issue because obviously the computer is disabled in AD.
Has anyone seen a script that can run on the local computer that updates the LastLogonDate property in AD of the computer while the user is logged in? I was thinking of just pushing out a scheduled task to all computers that does this every 15 minutes if its even possible. Thanks!
I was wondering if there's a way to use Mosh on windows without Cygwin?
I need to be able to put it on my USB drive and copy it over to a windows computer and be able to Mosh into one of my servers. Otherwise, is there a way to use Cygwin and have it portable? I did get mosh working under windows via Cygwin, but that meant I had to add an environment path to the windows computer, which, on the windows computer that I'm working on doesn't allow you to change that, since I don't have admin privileges.
MobaXTerm is portable and supports Mosh.
It works quite well. I spent all day using it on a very dodgy connection and it worked like a charm.
Just get the most recent version and from the Session menu select Mosh. It did does not support IPv6 (at least in Version 9.2 (2016-09-18)):
Bugfix: Mosh sessions are forced to IPv4 only (IPv6 is not yet supported by Mosh client/server)
But it might work now, since Version 10.4 (untested):
We also improved MobaXterm behavior and fixed issues with multi-monitors, IPv6 connections, mouse scrolling and keyboard shortcuts.
Interestingly enough, I wanted MOSH for Windows too, and I find Cygwin to be very messy. Instead, I just downloaded a minimal Text-only Debian distribution, booted it up in VirtualBox, and installed MOSH. Surprisingly, it's much less time consuming and requires less tweaking than going the Cygwin route, and makes less modifications to the host machine.
In fact, there is a portable VirtualBox, so you can put your MOSH VM and Portable VirtualBox on a memory stick.
I haven't even tried to optimize things, but it runs just fine on the 256MB of ram I gave it. It would probably run just fine on 64MB or less.
I do hope MOSH will be built into PuTTY/KiTTY in the future.
I have noticed that a new version of MobaXterm has been released (version 7.1) and includes an intergrated Mosh session.
So, you dot not need anymore need plugin for that.
They said that it is "experimental", but I have tested it, and it is working quite well.
As of now, Mosh has added support for Google Chrome (or any of Chromium Browsers) as an official extension. So you can keep a portable google chrome & use mosh from there.
For Windows, there isn't a single solution install to support MOSH. Rather, you have to sort of "stitch together" a few options to make it work.
MOSH itself does not need ssh or any other initial program necessarily. It is possible to start a session on your server, then using the published connection information, go to your client (in this case your windows box) and use that information to connect the session. This is sort of messy and is the main reason people use SSH to basically establish a connection to the server, remotely start a MOSH server, get the session information back to your client machine, then launch the MOSH experience.
The two pieces you need on the client side (if you make the connection manually) are the server port number and symmetric encryption key. A typical example of one given by a MOSH server would be:
MOSH CONNECT 60001 U0MWPbwn3BdcdMyNLnSFCA
Where 60001 is my port number and "U0...CA" is my encryption key. Don't ever give this out BTW as ANYONE can connect to your running MOSH server with this information (that is, they would look just like an IP change just like you do when you get disconnected and reconnected)
So, back to installation. MobaXterm (currently at v10.5) is a free for personal use app that you can find at https://mobaxterm.mobatek.net/. Installation is relatively straight forward. One word of caution however, their SSH implementation is rudimentary. Basically they support password authentication for ssh. If you use public keys, you cannot have one with a password on it and expect it to work (the code to ask you for your password appears to be missing). This might not be a show stopper for everyone but this is where my company stopped following this thread.
Within MobiXTerm, you want to hit the "Sessions" button at the top left to bring up a new session window. Press the Mosh button on the top right to get the start of your session (NOTE: This is IPv4 only. Zippo luck on getting IPv6 with this to work). Enter your remote host and the username of the ssh account you will be using. If you have an unsigned ssh key, then you can use the Advanced Mosh setting to link that private key with this session (at this point, as a security guy, I'm sort of passing out). At this point, as long as mosh is correctly running on your server (with the 60000-61000 UDP ports open in the server firewall), things should "just work".
Ok, so its not too painful to get working this way. But other than terminal functionality, its not very much fun either. Although MobiXterm is an X-server, I haven't yet gotten X to function over the mobi connection (at least not automatically).
I’m trying to debug a Bonjour network routine, and every time I run it, the Mac’s firewall asks “Do you want the application ProjectName to accept incoming network connections?”
I click “allow,” give it the administrator name and password, and the app is duly added to the firewall’s list of allowed incoming-connections apps…until the next run.
Debugging this sync routine is cumbersome as it is. It’s really a nuisance having to type in the admin and password for every run. Of course I could get around this by running the Mac as admin, but I’d rather not compromise the security that way.
Does Xcode have some project setting that will calm the firewall?
You should code sign your app. The firewall is much more lenient toward apps that are signed.
To do that, you need to go into your Project Settings and in the Code Signing section, you should add one of your provisioning profiles as the Code Signing Identity.
There's a pretty good description of the process here.
At work, I running Vista Business on a lavishly new PC, which runs great excepting two issues. In order of annoyance, but not importance:
When I reboot the machine, the Windows Splash is presented asking me to Press Ctrl + ALT + DELETE so I can logon. It takes three to five minutes and seceral key presses for me to be prompted to select my user account. After which, everything works like a charm.
As part of my duties with the firm, I am responsible for emergency work on a rotating basis and deploying patches during off-business hours. I have been given an older laptop with XPSP2 (downloading 3 for kicks right now) which I use for browsing with the intention of RDP to my desktop in the offices. If I am connected at the domain through conventional means, I am able to RDP. However, if I am using an existing broadbad connection with VPN, I am not able to get access. I am able to access other servers, desktops running a variety of OS'es including Vista.
So umm any ideas guys?
as for 2 - this happens with some proprietary VPN software (i.e. Cisco). My solution was to perform my work duties in a Virtual PC (which doesn't need its normal LAN abilities) and do my other network/internet tasks in the physical machine.
I have a Vista at work and uses my home PC to rdc in for support work. I do not experience your problem 1 so I cannot offer any advice. For your second problem have you tried the IP address instead of the machine name? We have situations where sometimes the dns resolution in the office network is not accurate.
Do you have remote access enabled, either on the machine, via group policy?
If not, you might have to go into the Control Panel\System and Maintenance\System and choose Remote Settings (from the menu on the left).
That will show you the options for Remote Deskop, including Don't allow connections, Allow connections from any version of Remote Desktop, and Allow connections from computers running Remote Desktop with Network Level Authentication (which might be the hang up you are experiencing over the VPN).
Good Luck.
I have to chalk this up to "something wierd with my laptop" as I was able to download RoyalTS and connect to the machine just fine. I had Remote connections permitted, firewall disabled, McAffee gone and others could access the machine.
The advice garnered above is excellent and useful for your typical rdp connections