I have a strange problem that I’ve searched extensively about, but cannot find a resolution. On boot, I can’t get to the desktop. It hangs with a black screen and the mouse pointer displayed. I won’t go into the entire gruesome history of how I found this workaround, but I’ve found it.
I am running the most current Tumbleweed drop and have this machine connected to an AD domain running on a Windows 2012 server. My userid, ‘myuser’ is defined locally to the Linux box and to the Windows domain. There were times in the past when I found that I couldn’t login from the KDE login panel unless I did the Ctrl-Alt-F1 to a text console, logged in as root and changed the password to ‘myuser’ (always to the same password, it has never changed).
At some point I don’t remember in the last year, I started getting hangs during boot with the above-mentioned symptoms. After hours of trying everything in the book, I resorted to resetting the password for ‘myuser’, logging on to it, and then restarting the display-manager service. That resolves the immediate problem and brings up my Plasma desktop perfectly.
I’m completely bereft of any ideas at this point, so I decided to post this to see if someone recognized the issue.
IMO depends how Linux integration is implemented. If you login directly to a Domain Server, then there is likely no problem. But some implementations map local Linux accounts to Domain accounts and in that case maybe it would be a problem depending on what you’re doing.
I would ask you why you think your User account’s UserID is the same in both cases?
Have you considered manually separating by creating a new, separate local account dedicated to mapping to AD if necessary?
Thanks for the reply tsu. I wasn’t clear enough in my description of the problem. I have the same userid defined both to my local Linux machine and to AD. I normally use the AD credentials to logon to my Win10 box and the local Linux user for my main Tumbleweed desktop. I have the Linux machine enrolled as a member of the domain, so I use my AD credentials to access/map Windows shares across the network.
For the last few months, when I reboot the Linux PC, the desktop fails to come up. I’m left with a black screen and a movable mouse pointer. When this first happened I tried dozens of “recommended” solutions. Normally I did a Ctrl-Alt-F1 to jump to a shell and logon as root. After dealing with this a while, for a reason I’ve forgotten, I decided to logon in with my normal user account. When I tried that, it failed to authenticate. I discovered, by trial and error, that if I logged in as root and changed the password (always back to what it originally was), my local userid would authenticate just fine. Then I’d do a service restart of display-manager and the desktop would then come up normally.
This is repeatable as a sunrise and I will be doing it today after a dup and reboot. The mysterious thing here is that doing a passwd <userid> and re-entering the old password resolved the problem and that it reappears each boot.
I have not set up something similar to what you describe for a long time, but I can describe how things should be configured…
First, some terminology…
Userid - Is a string of random characters or on a Linux system typically a number used by the machine to identify objects, there are userids and machineids plus many other identifiers. A userid is <not> a typically human readable string of characters like a Username like “Tom” or “Joe.Foobar”
Authenticator - Whatever is used to verify credentials of any type. On a local machine is usually a service with access to a database or file that contains valid credentials. Network security like AD or LDAP typically deploy Domain Controllers.
Cached credentials - When a machine is taken out of network and cannot connect to the Domain Controller, the machine will have stored the credentials for that Domain account locally for a period of time. This may have the appearance of logging on locally, but note that the account’s credentials are not stored in the local authenticator’s database, will expire shortly and cannot be managed by the local machine’s local User account management.
When you describe “using the same userid” for both logging in to the local machine vs logging in to the network Domain, that’s typically
Unlikely or an impossibility if the User accounts are set up following proper procedure, partly because local machine accounts are set up with default values (including the userid) and network accounts will set up by default with different defaults (start with a different default userid and assign userids in that range to new network accounts. If you think that you followed proper procedure creating your accounts and still found conflicting userids or userids close to others that aren’t the same type, then that should be submitted to a bugzilla.
Note that user accounts are defined by where the authenticator is, typically on the local system or to a network server.
User accounts are not defined by what type of assets they have access to, so for instance Domain accounts can and would be used to control access to ACLs, directories, files and what you can do on a local machine as well as what you can do on a remote machine. A local account defined by being authenticated by a service running on the local machine will typically control what you can do on the local machine and rarely would determine what can be done on a remote machine. For network accessed assets like network shares, you are typically authenticated by the local authenticator running on the remote machine.
So,
Am saying that it might be confusing to some that you can logon to the Domain on a machine without actual access to the Domain authenticator (typically a Domain Controller). Typically network security allows domain credentials to be cached locally on a device so that if the machine is removed from the network (ie a laptop or phone), a User can still logon to the device. It might look like you’ve logged in to the machine locally and might be using a local machine userid, but that’s not happening. The User must first have logged in to the machine before successfully, whereupon the credentials are cached on the local machine for a period of time. When the machine is on the network next time and can access an authenticator, the cached credentials are updated. It sounds like your machine may have been away from a DC too long and your cached credentials have expired.