Issue: Authd and Intune device settings/compliance

[arnoldthebat]

Is there an existing issue for this?

• [x] I have searched the existing issues and found none that matched mine

Describe the issue

Configuring authd initially works as expected with the user onboarding and using a local password

Trying to add in intune compliance checking however results in a failure to update device settings

The local password for the authd user is compliant with the password policy but intune does not seem to read the local password store:

Jun 10 10:31:48 td-ubutst01 intune-portal[3192]: Non-compliant status indicated by IWS issues=[("Enforce a secure password", "This device must be configured to enforce passwords containing at least 1 digits.", "https://go.microsoft.com/fwlink/?linkid=2210011"), ("Enforce a secure password", "This device must be configured to enforce that passwords contain at least 14 characters.", "https://go.microsoft.com/fwlink/?linkid=2210011"), ("Enforce a secure password", "This device must be configured to enforce passwords containing at least 1 lowercase letters.", "https://go.microsoft.com/fwlink/?linkid=2210011"), ("Enforce a secure password", "This device must be configured to enforce passwords containing at least 1 symbols.", "https://go.microsoft.com/fwlink/?linkid=2210011"), ("Enforce a secure password", "This device must be configured to enforce passwords containing at least 1 uppercase characters.", "https://go.microsoft.com/fwlink/?linkid=2210011")]

Steps to reproduce

No response

System information and logs

No response

Double check your logs

• [x] I have redacted any sensitive information from the logs

[arnoldthebat]

Im not sure whether this is an intune issue or an authd issue as such (yet), but the fact that intune on-boarding for a 'normal' user outside of authd works, makes me think that the issue lies with the way that authd is storing users passwords.

For ref, this is on both stable and edge versions of authd.

[3v1n0]

Mh, is the MS API providing any information about what should be the password constraints?

Because otherwise there's no way we could apply the same rules ourself

[arnoldthebat]

Hi See the snippet above in the original issue log. Ill need to setup intune in debug mode to go further but suffice to note the local password I set is as per the constraints Intune needs to validate against.

Thats why I assumed that the authd based user stored local password outside that of a normal Linux user.

You dont need to apply the rules yourself, Intune isnt picking up the authd user password for whatever reason, where it works with a normal user password fine (I set tests with the same password for authd and standard linux user for that reason)

Give me a bit of time, and Ill see what I can find debug wise

[ajm370]

@arnoldthebat I don't think this is reporting that the password you chose does not meet the requirements, rather that the local password policy does not match what InTune expects (14 character minimum, ... etc. based on the log you posted above). To rectify this:

sudo apt install -y libpam-pwquality

sudo sed -i "s/# minlen.*/minlen = 14/g" /etc/security/pwquality.conf

sudo sed -i "s/# dcredit.*/dcredit = -1/g" /etc/security/pwquality.conf

sudo sed -i "s/# ucredit.*/ucredit = -1/g" /etc/security/pwquality.conf

sudo sed -i "s/# ocredit.*/ocredit = -1/g" /etc/security/pwquality.conf

sudo sed -i "s/# lcredit.*/lcredit = -1/g" /etc/security/pwquality.conf

sudo sed -i "s/LOGIN_TIMEOUT.*/LOGIN_TIMEOUT   180/g" /etc/login.defs

sudo sed -i "s/pam_pwquality.so.*/pam_pwquality.so try_first_pass retry=5 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1/g" /etc/pam.d/common-password

Login timeout is not strictly necessary, but helps if auth is slow for some reason. The last line may not be necessary also. Best of luck!

[3v1n0]

sudo apt install -y libpam-pwquality
...
sudo sed -i "s/pam_pwquality.so.*/pam_pwquality.so try_first_pass retry=5 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1/g" /etc/pam.d/common-password

These steps are absolutely unneeded and potentially even problematic with authd:

• authd already depends on pwquality library, so just configure it by adding your parameters to /etc/security/pwquality.conf.d/your-settings.conf
• manually changing common-password is wrong and dangerous (but even useless with authd), use pam-auth-update if you want to.

[ajm370]

These steps are absolutely unneeded and potentially even problematic with authd:

* authd already depends on pwquality library, so just configure it by adding your parameters to `/etc/security/pwquality.conf.d/your-settings.conf`

Good to know on the authd front! We had these left in our autoinstall late-commands from when we were testing InTune, prior to even looking at Authd at all.

I don't think InTune is going to be aware of Authd's password complexity implementation unfortunately, and manually specifying the options above was still necessary to have the InTune compliance check pass last time I looked at it.

* manually changing `common-password` is wrong and dangerous (but even useless with authd), use `pam-auth-update` if you want to.

Yes I agree, although invoking pam-auth-update and other utilities in automated, non-interactive ways within the target chroot at install time with Autoinstall was a little flakey. I vaguely recall being able to get it working with DEBIAN_FRONTEND=noninteractive or similar.

[3v1n0]

I vaguely recall being able to get it working with DEBIAN_FRONTEND=noninteractive or similar.

Well actually just use --force with the service name to enable, that's it. The module will also read the same configuration though, so no need to repeat it as arguments.

See the man or just its simple source code :)

[ajm370]

I vaguely recall being able to get it working with DEBIAN_FRONTEND=noninteractive or similar.

Well actually just use --force with the service name to enable, that's it. The module will also read the same configuration though, so no need to repeat it as arguments.

See the man or just its simple source code :)

Sure, that's just overwriting any manual changes though, as I understand it? It doesn't "fix" the fact that InTune doesn't detect a sufficiently strong password policy.

In either case, I'm of the opinion this is an InTune issue, not an Authd one. The issue would be present without Authd being installed.

[arnoldthebat]

If I create a local user outside of authd, then InTune works fine with the password. That said, let me review again as soon as I get some time based on the above feedback. This was my rationale for wondering whether authd was storing the local password differently.

Basically, I need to do some more digging on this when I get some time so bear with me and Ill see what I can find.

Thanks for the feedback above.

[Senectus]

This is an increasing issue for us as well, Have found that I can authD sign in then try and fail to intune enroll, then sign out and sign in with a purely local account and succeed in intune enrolling the device. unfortunately if I then sign out of the local account and sign into the authD account the intune agent never checks back into intune, so the "compliance" state is essentially static . If you then sign back in with the local account ad relaunch the intune agent it will then check in and get compliance status again.

[ajm370]

@Senectus Intune for Linux is tied to a single account for each device you onboard. If you try to sign in with a second account (local or Authd), it will create a duplicate entry of that device in your Entra tenant device list. MS need to sort that or we will never be able to have multi-user devices work with InTune.

[Senectus]

yeah, it functions better in the windows world, you can have multi-user windows device in intune (shared device or hybrid joined). Its a bit clunkier in the Linux world. If we could get the keyring problem solved we (in theory) could join a machine into intune after authD does its thing and my world would become a brighter place.

I really dont want to slide back to sssd.