[SOLVED] bl-user-setup causes login failure for Active Directory

Bearded_Blunder · 2016-08-16 02:04:46

I've been setting up a pilot BL system, with a view to deploying several integrated with Active Directory.

By following this guide (with some minor tweaks, like pointing to /usr/share/bunsen/skel ) I can join the machines to my domain, AD users can login, have their home directories created, and domain admins get sudo rights.

The issue is that in order to login AD users must ctrl-alt-f2 to a tty, login, and issue startx manually. Trying to login from the normal login screen fails with no visible error, just returns you to the login screen. I've no idea what logs to look at for errors, or how to look at them under systemd, bring back plain text!

Google has been unhelpful on this occasion, with most of the results telling me to set

greeter-show-manual-login=true

which makes no difference.

I've also found references to setting override_homedir in sssd.conf, which I've also done after visiting

man sssd.conf

to no avail, I'm a bit lost tbh, much more comfortable troubleshooting windows as a general rule.

Any useful pointers would be appreciated, I'm probably missing something obvious, sadly I've only been documenting the steps that did work as I went along, not those that didn't, so it's hard to enumerate all the settings and tweaks I've tried.

Last edited by Bearded_Blunder (2016-09-22 14:25:26)

Head_on_a_Stick · 2016-08-16 07:55:48

Bearded_Blunder wrote:

I've no idea what logs to look at for errors, or how to look at them under systemd, bring back plain text!

The systemd logs are stored in binary but can be extracted with the `strings` command and then parsed with the usual GNU suspects (`awk` ftw!).

Alternatively, use this method:
http://unix.stackexchange.com/questions … her-system

In respect of specific errors from LightDM, have a look in ~/.xsession-errors, /var/log/lightdm/lightdm.log (and other files in that folder) and also check /var/log/Xorg.0.log

Bearded_Blunder · 2016-08-16 11:08:21

Thanks for the pointers, /var/log/lightdm/lightdm.log seems to show authentication is working:

[+330.53s] DEBUG: Activating VT 7
[+330.53s] DEBUG: Activating login1 session c4
[+330.66s] DEBUG: Session pid=852: Greeter connected version=1.10.3
[+331.04s] DEBUG: Session pid=852: Greeter start authentication
[+331.05s] DEBUG: Session pid=873: Started with service 'lightdm', username '(null)'
[+331.07s] DEBUG: Session pid=873: Got 1 message(s) from PAM
[+331.07s] DEBUG: Session pid=852: Prompt greeter with 1 message(s)
[+346.13s] DEBUG: Session pid=852: Greeter start authentication for ADuser@localdomain.local
[+346.13s] DEBUG: Session pid=873: Sending SIGTERM
[+346.14s] DEBUG: Session pid=875: Started with service 'lightdm', username 'ADuser@localdomain.local'
[+346.14s] DEBUG: Session pid=873: Terminated with signal 15
[+346.14s] DEBUG: Session: Failed during authentication
[+346.14s] DEBUG: Seat: Session stopped
[+346.18s] DEBUG: Session pid=875: Got 1 message(s) from PAM
[+346.18s] DEBUG: Session pid=852: Prompt greeter with 1 message(s)
[+349.79s] DEBUG: Session pid=852: Continue authentication
[+349.97s] DEBUG: Session pid=875: Authentication complete with return value 0: Success
[+349.97s] DEBUG: Session pid=852: Authenticate result for user ADuser@localdomain.local: Success
[+349.97s] DEBUG: Session pid=852: User ADuser@localdomain.local authorized
[+349.97s] DEBUG: Session pid=852: Greeter sets language en_GB.utf8
[+349.98s] DEBUG: Session pid=852: Greeter requests session lightdm-xsession
[+349.98s] DEBUG: Seat: Stopping greeter; display server will be re-used for user session
[+349.98s] DEBUG: Session pid=852: Sending SIGTERM
[+350.01s] DEBUG: Session pid=852: Greeter closed communication channel
[+350.02s] DEBUG: Session pid=852: Exited with return value 0
[+350.02s] DEBUG: Seat: Session stopped
[+350.02s] DEBUG: Seat: Greeter stopped, running session
[+350.02s] DEBUG: Launching process 884: /usr/lib/bunsen/configs/bl-user-setup
[+350.03s] DEBUG: Process 884 exited with return value 1
[+350.03s] DEBUG: Seat: Exit status of /usr/lib/bunsen/configs/bl-user-setup: 1
[+350.03s] DEBUG: Seat: Switching to greeter due to failed setup script
[+350.03s] DEBUG: Seat: Creating greeter session
[+350.04s] DEBUG: Session pid=885: Started with service 'lightdm-greeter', username 'lightdm'
[+350.05s] DEBUG: Session pid=875: Exited with return value 0
[+350.05s] DEBUG: Seat: Session stopped
[+350.09s] DEBUG: Session pid=885: Authentication complete with return value 0: Success
[+350.09s] DEBUG: Seat: Session authenticated, running command
[+350.09s] DEBUG: Session pid=885: Running command /usr/sbin/lightdm-gtk-greeter
[+350.10s] DEBUG: Creating shared data directory /var/lib/lightdm/data/lightdm
[+350.10s] DEBUG: Session pid=885: Logging to /var/log/lightdm/x-0-greeter.log

and that /usr/lib/bunsen/configs/bl-user-setup has some problem around timestamp [+350.02s] to [+350.03s].
Looking at that:

#!/bin/bash
# BunsenLabs User Set-up

# USER="$1" USER is exported by lightdm
[[ "$USER" = root || ! -d /home/"$USER" ]] && { echo "$0: variable USER has not been set correctly." >&2; exit 1;}

[ -f "/home/$USER/.config/bunsen/bl-setup" ] && exit 0

bkp_sfx="~$( date +%FT%T )~"

rsync -rltb --suffix="$bkp_sfx" --safe-links /usr/share/bunsen/skel/ /home/$USER

for i in "/home/$USER/.gtk-bookmarks" "/home/$USER/.config/nitrogen/nitrogen.cfg"
do
    [ -f "${i}.template" ] || continue
    sed --in-place "s/%USERNAME%/$USER/g" "${i}.template"
    if [ -f "$i" ]
    then
        if diff -BEbZ "$i" "${i}.template" >/dev/null
        then
            rm "${i}.template"
        else
            mv "$i" "${i}${bkp_sfx}"
            mv "${i}.template" "$i"
        fi
    else
        mv "${i}.template" "$i"
    fi
done

ln -sTf /usr/share/images/bunsen/wallpapers "/home/$USER/Pictures/wallpapers/bunsen"

mkdir -p "/home/$USER/.config/bunsen" # this should already exist
touch "/home/$USER/.config/bunsen/bl-setup"

chown -R "$USER":"$USER" "/home/$USER"

exit

I see the only place it exits with a status of 1 is right at the start

[[ "$USER" = root || ! -d /home/"$USER" ]] && { echo "$0: variable USER has not been set correctly." >&2; exit 1;}

I'm just unsure how to check what lightdm is exporting to the script, and consequently why this check is failing. If indeed that is the problem.

Looking in ~/.xsession-errors would only be useful for the ADuser's home, and at least in the case of a first login, neither exists nor gets created, except by logging in from a tty. I do notice for a user who has logged in via tty, all references to that user are entirely lower case as in "aduser" rather than "ADuser".

I might try creating an entirely lower case user "test@localdomain.local" though most of my user accounts are in the form Windows (and users) like Firstname.Lastname@localdomain.local

[edit]Made no difference being entirely lower case [/edit]

Last edited by Bearded_Blunder (2016-08-16 11:21:02)

xaos52 · 2016-08-16 11:44:07

See https://wiki.archlinux.org/index.php/Ac … ntegration
esp. the section about PAM setup - which enables you to create a 'link' between user name and user file structure, which is what is missing in your setup, I surmise.

I am not familiar with AD, so can't give you more info.

Bearded_Blunder · 2016-08-16 12:56:02

xaos52 wrote:

See https://wiki.archlinux.org/index.php/Ac … ntegration
esp. the section about PAM setup - which enables you to create a 'link' between user name and user file structure, which is what is missing in your setup, I surmise.
I am not familiar with AD, so can't give you more info.

If I try following that I'll need to start over from the beginning, am using realmd & sssd, the archwiki article linked refers to a completely different method using winbind, akin to telling someone asking "Why is Firefox not loading <insert url>?"
"Because you're not using Google Chrome, Here's how you set that up." I may yet try that, but it's a lot of pain without solving why realmd & sssd aren't cutting it, since I'd be using something else.

Logging in per-se isn't failing, AD users can login (from a tty) and startx from there, their home directories get created if it's the first login, and "everything works as expected" complete with all the other BL features.

They just can't through the lightdm greeter.

Head_on_a_Stick · 2016-08-16 19:31:43

The login managers of GNOME and KDE (GDM and KDM) have been extended to allow the handling of AD domain login.

http://doc.opensuse.org/documentation/h … ty.ad.html

This would suggest that perhaps LightDM doesn't support AD integration.

Can you try GDM to confirm this?

sudo apt-get install --no-install-recommends gdm3
sudo dpkg-reconfigure gdm3

To change back to LightDM, use:

sudo dpkg-reconfigure lightdm

Bearded_Blunder · 2016-08-16 23:20:59

Wow 91 newly installed, even with "--no-install-recommends", this allows me to confirm gdm3 doesn't like Bunesen...

beardy@bunsen-base:~$ sudo dpkg-reconfigure gdm3
[sudo] password for beardy: 
Job for gdm.service failed. See 'systemctl status gdm.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript gdm3, action "reload" failed.
beardy@bunsen-base:~$

so looking at those:

beardy@bunsen-base:~$ sudo systemctl status gdm.service
● gdm.service - GNOME Display Manager
   Loaded: loaded (/lib/systemd/system/gdm.service; enabled)
   Active: inactive (dead)

Aug 16 23:54:35 bunsen-base systemd[1]: Unit gdm.service cannot be reloaded because it is inactive.
Aug 16 23:56:11 bunsen-base systemd[1]: Unit gdm.service cannot be reloaded because it is inactive.
beardy@bunsen-base:~$

and

-- Logs begin at Tue 2016-08-16 23:49:26 BST, end at Wed 2016-08-17 00:03:16 BST. --
Aug 16 23:55:41 bunsen-base sudo[3428]: beardy : TTY=pts/0 ; PWD=/home/beardy ; USER=root ; COMMAND=/usr/sbin/dpkg-reconfigure gdm3
Aug 16 23:55:41 bunsen-base sudo[3428]: pam_unix(sudo:session): session opened for user root by beardy(uid=0)
Aug 16 23:56:11 bunsen-base systemd[1]: Unit gdm.service cannot be reloaded because it is inactive.
Aug 16 23:56:12 bunsen-base sudo[3428]: pam_unix(sudo:session): session closed for user root
Aug 17 00:03:05 bunsen-base sudo[3665]: beardy : problem with defaults entries ; TTY=pts/2 ; PWD=/home/beardy ;
Aug 17 00:03:08 bunsen-base sudo[3665]: pam_unix(sudo:auth): authentication failure; logname=beardy uid=1000 euid=0 tty=/dev/pts/2 ruser=beardy
Aug 17 00:03:08 bunsen-base sudo[3665]: pam_sss(sudo:auth): authentication failure; logname=beardy uid=1000 euid=0 tty=/dev/pts/2 ruser=beardy
Aug 17 00:03:08 bunsen-base sudo[3665]: pam_sss(sudo:auth): received for user beardy: 10 (User not known to the underlying authentication mo

Even with a reboot, still get the lightdm login screen, since this is a disposeable install (easily recreated), I might apt-get remove lightdm, see if that makes it use gdm3!

Head_on_a_Stick · 2016-08-17 07:20:23

I have just tried this on my BL system (apologies for not doing that first btw) and although the same error messages are displayed, a reboot takes me to the GDM login screen.

I don't know why that doesn't work for you

What is the output of:

ls -l /etc/systemd/system/display-manager.service

Bearded_Blunder · 2016-08-21 00:16:33

Sorry it's taken a while to get back, life intervening, had to leave it for a while, on booting back up, GDM came up, and works as expected for AD users.

Interestingly, on reverting to lightdm, with GDM installed, that also then works, I've had no time to investigate why that would be though, but evidently lightdm *can* work, with whatever was changed by GDM in place... be that something it pulled in, or some config change, just had no time to try to isolate what.

tknomanzr · 2016-08-21 06:21:02

It is likely a full reboot would be required, even with a newer kernel, because you need to reload PAM. Also, check to see if accountsservice got pulled in. That would be my first guess.

Head_on_a_Stick · 2016-08-21 14:21:28

We could check the autostarted programs and see what is different from a stock install:

/usr/lib/x86_64-linux-gnu/openbox-xdg-autostart --list

@B_B: I have marked the thread [SOLVED], you can do this yourself next time by editing the title

Bearded_Blunder · 2016-08-21 16:47:10

Head_on_a_Stick wrote:

We could check the autostarted programs and see what is different from a stock install:
/usr/lib/x86_64-linux-gnu/openbox-xdg-autostart --list

I shall (when I get free time, I'm currently subject to lots of interruptions, and have a guest in the house so time is limited) be looking into those or at least issue the equivalent for a 32 bit system, along with what GDM pulled in that may actually point me to the proper solution accountsservice looks a likely candidate, since GDM pulls that in, and it's only a suggests for lightdm, and many thanks @tknomanzr for the pointer

Head_on_a_Stick wrote:

@B_B: I have marked the thread [SOLVED], you can do this yourself next time by editing the title

@HoaS My intention was to do so, once I'd identified the real root of the issue, I do know how, and I also know it's considered bad form not to on this board.

Currently installing GDM switching to it and then back is more of a workaround than a fix as such.. Meantime, I shall edit my first post again to reflect this by saying [WORKAROUND]. Maybe I should have added something to this effect at my last visit, since I have a method that "works" even if it requires building on an extra unused metaphorical lobby.

[SOLVED] is better applied when we have a precise solution, something I hope to have in due course which I'll then report and do the edit for at that time.

Sorry to be such a pedantic old cuss.

Head_on_a_Stick · 2016-08-21 17:18:27

Bearded_Blunder wrote:

@HoaS My intention was to do so, once I'd identified the real root of the issue, I do know how, and I also know it's considered bad form not to on this board.
Currently installing GDM switching to it and then back is more of a workaround than a fix as such.. Meantime, I shall edit my first post again to reflect this by saying [WORKAROUND]. Maybe I should have added something to this effect at my last visit, since I have a method that "works" even if it requires building on an extra unused metaphorical lobby.
[SOLVED] is better applied when we have a precise solution, something I hope to have in due course which I'll then report and do the edit for at that time.

I disagree.

LightDM does not appear to support AD logins and so the solution is to use a display manager that does.

As such, I consider that this thread is indeed [SOLVED] and I am re-marking it as such in order to aid others who may have this problem.

I see no point using a nonsense tag for the thread as this will decrease SEO for the problem in hand.

I have closed the thread for now, if you wish to investigate further please PM me with the XDG autostart list and I will re-open the thread.

EDIT: Thread re-opened after further consideration.

Last edited by Head_on_a_Stick (2016-08-21 20:06:49)

Bearded_Blunder · 2016-08-24 03:34:53

In order to test your position, I have done the following.
1. A Jessie netinstall, at tasksel, I deselected everything except standard system utils
2. Installed xorg
3. Installed lxde-core
This gave me a very basic system with tty login and startx manually. No dm installed or configured.
4. I then installed lightdm to give myself a graphical login.

This was my test system.
I then installed realmd adcli and sssd and joined the domain the exact same way I did with bunsen

I then appended

session required pam_mkhomedir.so skel=/etc/skel/ umask=0022

to the file /etc/pam.d/common-session
in the exact same way I had appended

session required pam_mkhomedir.so skel=/usr/share/bunsen/skel/ umask=0022

to the same file when trying this in bunsen.

I also (though I don't think it's relevent) created a file named domain_admins in /etc/sudoers.d/ containing

%domain\ admins@localdomain.local ALL=(ALL:ALL) ALL

to give domain admins local sudo rights on login (domain name changed to something generic).

At this point logging in as an AD domain user works perfectly in the test system, and domain admins indeed get sudo rights.

In this test setup, AD logins work perfectly.

I believe this shows that though there is an issue with graphical logins for AD users in bunsen, the cause is not LightDM. Which I already suspected was the case, as switching back to LightDM after installing and using GDM once allowed such logins using it, which indicated to me that it should work just fine, if the config, and needed deps for AD logins are correct.

Incidentally this also eliminated the accountsservice package as the cause, as it's not present on the working lxde-core test system.

In light of the above testing, I'm editing the thread title to "Something causes graphical login for Active Directory users to fail"

Personally I don't see what difference a tag or otherwise makes at this stage, since the problem and subsequent solution is only relevant to bunsen, and not wider searches, nor do I believe "workaround" to be nonsense, and an (admittedly effective) workaround is all we have at the moment. I'm still looking to find a clean solution.

Unfortunately, I'm still at somewhat of a loss as to what the cause is......

As requested, output from

/usr/lib/i386-linux-gnu/openbox-xdg-autostart --list

on the machine with GDM3 installed and consequently working logins:

[ ] AT-SPI D-Bus Bus
	  File: /etc/xdg/autostart/at-spi-dbus-bus.desktop
	  Executes: /usr/lib/at-spi2-core/at-spi-bus-launcher --launch-immediately
	* Excluded by: OnlyShowIn (GNOME, Unity)

[ ] Secret Storage Service
	  File: /etc/xdg/autostart/gnome-keyring-secrets.desktop
	  Executes: /usr/bin/gnome-keyring-daemon --start --components=secrets
	* Excluded by: OnlyShowIn (GNOME, Unity, MATE)

[ ] GPG Password Agent
	  File: /etc/xdg/autostart/gnome-keyring-gpg.desktop
	  Executes: /usr/bin/gnome-keyring-daemon --start --components=gpg
	* Excluded by: OnlyShowIn (GNOME, Unity, MATE)

[ ] PolicyKit Authentication Agent
	  File: /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop
	  Executes: /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
	* Excluded by: OnlyShowIn (GNOME, XFCE, Unity)

[*] Network
	  File: /etc/xdg/autostart/nm-applet.desktop
	  Executes: nm-applet

[ ] PulseAudio Sound System KDE Routing Policy
	  File: /etc/xdg/autostart/pulseaudio-kde.desktop
	  Executes: start-pulseaudio-kde
	* Excluded by: OnlyShowIn (KDE)

[*] Screen Locker
	  File: /etc/xdg/autostart/light-locker.desktop
	  Executes: light-locker

[ ] GSettings Data Conversion
	  File: /etc/xdg/autostart/gsettings-data-convert.desktop
	  Executes: gsettings-data-convert
	* Excluded by: OnlyShowIn (GNOME, Unity)

[*] PulseAudio Sound System
	  File: /etc/xdg/autostart/pulseaudio.desktop
	  Executes: start-pulseaudio-x11

[*] Power Manager
	  File: /etc/xdg/autostart/xfce4-power-manager.desktop
	  Executes: xfce4-power-manager

[ ] SSH Key Agent
	  File: /etc/xdg/autostart/gnome-keyring-ssh.desktop
	  Executes: /usr/bin/gnome-keyring-daemon --start --components=ssh
	* Excluded by: OnlyShowIn (GNOME, Unity, MATE)

[ ] ClipIt
	  File: /etc/xdg/autostart/clipit-startup.desktop
	  Executes: clipit
	* Excluded by: OnlyShowIn (GNOME, XFCE, LXDE, Unity)

[ ] XFCE Volume Daemon
	  File: /etc/xdg/autostart/xfce4-volumed.desktop
	  Executes: xfce4-volumed
	* Excluded by: OnlyShowIn (XFCE)

[ ] Certificate and Key Storage
	  File: /etc/xdg/autostart/gnome-keyring-pkcs11.desktop
	  Executes: /usr/bin/gnome-keyring-daemon --start --components=pkcs11
	* Excluded by: OnlyShowIn (GNOME, Unity, MATE)

I can't compare to a default system right now, as I nuked the non-working one for the test described at the start of this post, but I also don't see anything that looks a likely candidate to be different.

Last edited by Bearded_Blunder (2016-08-24 03:37:19)

Head_on_a_Stick · 2016-08-24 06:56:45

Thanks for the detailed update

The autostart stuff looks normal so that theory is nonsense.

Bearded_Blunder · 2016-08-24 09:14:09

I now have a theory, unfortunately owing to commitments, I may not have time to test it for a couple of days, if I'm correct in where the issue lies, then logging in from a tty or switching DM only partially solves the issue, in that AD users get logged on, with an unconfigured home dir, the clues are in post #3, in neither of these cases does /usr/lib/bunsen/configs/bl-user-setup get run.

I never did much testing of a system logged onto that way beyond seeing that openbox tint2 conky etc. came up, so that's entirely possible.

If I'm correct bl-user-setup either needs a rework to cope with the fact pam_mkhomedir.so creates /home/domain.tld/$USER for active directory logons rather than /home/$USER which it's expecting for local users, and thus exits with a status of 1 aborting the logon. Again clues in post #3

[+350.02s] DEBUG: Seat: Greeter stopped, running session
[+350.02s] DEBUG: Launching process 884: /usr/lib/bunsen/configs/bl-user-setup
[+350.03s] DEBUG: Process 884 exited with return value 1
[+350.03s] DEBUG: Seat: Exit status of /usr/lib/bunsen/configs/bl-user-setup: 1
[+350.03s] DEBUG: Seat: Switching to greeter due to failed setup script

Or possibly better, needs running instead (with suitable edits) from ~/.config/openbox/autostart which would have the advantage of making it DM agnostic. It currently depends on LightDM or manually adding to the config for any replacement DM. If so added, I suspect AD logon would then also break for GDM3.

johnraff · 2016-08-25 03:04:30

Hi B_B as the writer of bl-user-setup I'm interested in this, though I am not familiar with AD either.

LightDM should be setting USER to the name of the user logging in, and exporting it to bl-user-setup. This works in normal cases. If HOME was also available to bl-user-setup and set correctly to /home/$USER or /home/domain.tld/$USER respectively, then it would be an easy fix. I don't have time to test this right now, however.

Unfortunately, while running bl-user-setup as the user, after login, is an attractive option, if it hasn't yet been run then ~/.config/openbox/autostart, if it exists, will be the generic openbox version. We'd have to call the user setup script from some file that exists independently of bl-user-setup having been run...

johnraff · 2016-08-25 08:12:53

update: Test confirmed that HOME is available at the time bl-user-setup is run. On my system it's set to /home/john
Now, whether on your setup it gets set to /home/domain.tld/$USER, and whether that is a desirable place for the files in skel to be copied to, are things you will have to check.

Anyway, you could try editing /usr/lib/bunsen/configs/bl-user-setup, substituting "$HOME" for every occurrence of "/home/$USER" and see if that fixes the issue. If it does, we might be able to release an upgraded bl-user-setup (after making sure we've got corner-cases covered).

btw I've just spotted an unquoted variable in bl-user-setup that will need fixing anyway.

Last edited by johnraff (2016-08-25 08:17:48)

Bearded_Blunder · 2016-08-25 21:17:22

Woke up, going to take a look later, got pounced on to do other things. Need to reinstall my test system, I was tired last time I did things on it and forgot to snapshot it before running stuff (and messing it up), now I can't simply revert to before having any AD user accounts and other modified stuff on there :8

However I can already confirm that, on my setup, the line

session required pam_mkhomedir.so skel=/usr/share/bunsen/skel/ umask=0022

added to /etc/pam.d/common-session already takes care of copying skel and the ~/.config/openbox/autostart runs. I have (had before I broke stuff) it setting the screen resolution for AD users already by editing it and adding a copy of my modified .screenlayout folder from the local user created during setup in /usr/share/bunsen/skel/ and editing autostart in skel. It's the customisations done by bl-user-setup that aren't at present happening, as the only way I've been able to log them on is by commenting out the line calling the bl-user-setup script from LightDM, switching to a tty to login, or switching DM.

johnraff wrote:

Now, whether on your setup it gets set to /home/domain.tld/$USER, and whether that is a desirable place for the files in skel to be copied to, are things you will have to check.

I suspect putting it anywhere other than that would cause issues as

$ sudo getent passwd User@domain.tld

returns a line specifying that home is located at /home/domain.tld/user for them, that's the first check I do after joining the machine to AD to check it joined properly and capable of getting authentication information from AD I'm not certain how I'd check what bl-user-setup sees before anyone is logged on though, I'd be surprised if it didn't report the identical info as getent passwd. I'm given to understand that it's possible to modify that location on the AD side specifying different things for different OUs, but I've not found a tutorial for how nor do I wish to, it seems it's the accepted default place for AD users to go on linux systems. AD users can also use a custom skel specific to them simply by specifying that instead of the local users' one in /etc/pam.d/common-session, although in that case one obviously has to create a custom skel for them somewhere.

johnraff wrote:

Anyway, you could try editing /usr/lib/bunsen/configs/bl-user-setup, substituting "$HOME" for every occurrence of "/home/$USER" and see if that fixes the issue. If it does, we might be able to release an upgraded bl-user-setup (after making sure we've got corner-cases covered)

I was, before I made a silly error and lost my efforts, already editing bl-user-setup to see if I could get it going, the silly error being why I went to bed, and now need to reinstall before continuing. I was intending at the time to call it from autostart, once I had it working in a terminal as the logged on user where I can watch the output. doing so from LightDM will involve me making the check right at the start pass for both my local user, and AD users, which makes my head hurt to do properly rather than simply commenting it out, I find editing bash scripts a slow process, as unlike DOS.bat and Windows.cmd scripts, I have to google virtually everything for the bash equivalent of the DOS line, and doing anything with sed usually takes me hours of research combined with multiple non-working versions.

Since I have to start over anyhow, I'll try it your way first, though I think it would work after logon running as the user, though perhaps not for new *local* accounts. If your suggestion does work, feel free to define what "corner cases" you want covered, I don't mind joining a machine to AD & creating some test users to check things out.

Irrelevent aside wrote:

n00b question, since bunsen uses a custom skel, would specifying it in /etc/adduser.conf instead of the default SKEL=/etc/skel entry in there get bunsen's skel copied without relying on bl-user-setup to do the copy for local accounts, and use the script just for the edits since it would then autostart if called in a similar fashion to bl-welcome? SKEL= wouldn't be a configurable setting if it wasn't envisaged that changing it might be useful.
I foresee people switching DM, or disabling LightDM to use text based login, then wondering months later why adding a user is broken or gets a broken wallpaper chooser etc., and not realising the two things could be related. Sure they'll get the answer if they ask here, or search diligently enough, but better if they never need to ask the question.

johnraff · 2016-08-26 02:19:25

About the skel location:
http://crunchbang.org/forums/viewtopic.php?id=39678
One reason for the switch was precisely so "lean" users could be created without all that config.

#1 2016-08-16 02:04:46

[SOLVED] bl-user-setup causes login failure for Active Directory

#2 2016-08-16 07:55:48

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#3 2016-08-16 11:08:21

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#4 2016-08-16 11:44:07

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#5 2016-08-16 12:56:02

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#6 2016-08-16 19:31:43

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#7 2016-08-16 23:20:59

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#8 2016-08-17 07:20:23

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#9 2016-08-21 00:16:33

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#10 2016-08-21 06:21:02

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#11 2016-08-21 14:21:28

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#12 2016-08-21 16:47:10

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#13 2016-08-21 17:18:27

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#14 2016-08-24 03:34:53

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#15 2016-08-24 06:56:45

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#16 2016-08-24 09:14:09

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#17 2016-08-25 03:04:30

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#18 2016-08-25 08:12:53

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#19 2016-08-25 21:17:22

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

#20 2016-08-26 02:19:25

Re: [SOLVED] bl-user-setup causes login failure for Active Directory

Board footer