vMA 6.0 Active Directory user login

SUSE Product Topics SLES Configure-Administer
1

I’ve successfully joined vMA aplliance based on SUSE Linux Enterprise Server 11 (x86_64) (VERSION = 11, PATCHLEVEL = 3)
to AD domain. However AD users can login to appliance only using local console (login: class\Administrator) but not using ssh.
Here is example:
login as: Administrator@class.local@vma1
Welcome to SUSE Linux Enterprise Server 11 SP3 for VMware (x86_64) - Kernel \r (\l).

Using keyboard-interactive authentication.
Password:
Access denied

Messages from /var/log/messages
2015-08-28T11:59:01+02:00 vma1 sshd[5545]: Invalid user ‘class\\Administrator’@vma1 from 10.216.1.143
2015-08-28T11:59:01+02:00 vma1 sshd[5545]: input_userauth_request: invalid user ‘class\\\\Administrator’@vma1 [preauth]
2015-08-28T11:59:01+02:00 vma1 sshd[5545]: Postponed keyboard-interactive for invalid user ‘class\\\\Administrator’@vma1 from 10.216.1.143 port 40538 ssh2 [preauth]
2015-08-28T11:59:04+02:00 vma1 sshd[5547]: pam_unix2(sshd:auth): Unknown option: `try_first_pass’
2015-08-28T11:59:04+02:00 vma1 sshd[5547]: pam_tally2(sshd:auth): pam_get_uid; no such user
2015-08-28T11:59:08+02:00 vma1 sshd[5545]: error: PAM: User not known to the underlying authentication module for illegal user ‘class\\Administrator’@vma1 from 10.216.1.143
2015-08-28T11:59:08+02:00 vma1 sshd[5545]: Failed keyboard-interactive/pam for invalid user ‘class\\Administrator’@vma1 from 10.216.1.143 port 40538 ssh2
2015-08-28T11:59:08+02:00 vma1 sshd[5545]: Postponed keyboard-interactive for invalid user ‘class\\\\Administrator’@vma1 from 10.216.1.143 port 40538 ssh2 [preauth]

Messages from /var/log/auth.log
2015-08-28T11:57:49+02:00 vma1 sshd[5538]: Invalid user ‘class\\Administrator’@vma1 from 10.216.1.143
2015-08-28T11:57:49+02:00 vma1 sshd[5538]: Invalid user ‘class\\Administrator’@vma1 from 10.216.1.143
2015-08-28T11:57:49+02:00 vma1 sshd[5538]: input_userauth_request: invalid user ‘class\\\\Administrator’@vma1 [preauth]
2015-08-28T11:57:49+02:00 vma1 sshd[5538]: input_userauth_request: invalid user ‘class\\\\Administrator’@vma1 [preauth]
2015-08-28T11:57:49+02:00 vma1 sshd[5538]: Postponed keyboard-interactive for invalid user ‘class\\\\Administrator’@vma1 from 10.216.1.143 port 40528 ssh2 [preauth]
2015-08-28T11:57:49+02:00 vma1 sshd[5538]: Postponed keyboard-interactive for invalid user ‘class\\\\Administrator’@vma1 from 10.216.1.143 port 40528 ssh2 [preauth]
2015-08-28T11:57:53+02:00 vma1 sshd[5540]: pam_unix2(sshd:auth): Unknown option: `try_first_pass’
2015-08-28T11:57:53+02:00 vma1 sshd[5540]: pam_tally2(sshd:auth): pam_get_uid; no such user
2015-08-28T11:57:57+02:00 vma1 sshd[5538]: error: PAM: User not known to the underlying authentication module for illegal user ‘class\\Administrator’@vma1 from 10.216.1.143
2015-08-28T11:57:57+02:00 vma1 sshd[5538]: error: PAM: User not known to the underlying authentication module for illegal user ‘class\\Administrator’@vma1 from 10.216.1.143
2015-08-28T11:57:57+02:00 vma1 sshd[5538]: Failed keyboard-interactive/pam for invalid user ‘class\\Administrator’@vma1 from 10.216.1.143 port 40528 ssh2
2015-08-28T11:57:57+02:00 vma1 sshd[5538]: Failed keyboard-interactive/pam for invalid user ‘class\\Administrator’@vma1 from 10.216.1.143 port 40528 ssh2
2015-08-28T11:57:57+02:00 vma1 sshd[5538]: Postponed keyboard-interactive for invalid user ‘class\\\\Administrator’@vma1 from 10.216.1.143 port 40528 ssh2 [preauth]
2015-08-28T11:57:57+02:00 vma1 sshd[5538]: Postponed keyboard-interactive for invalid user ‘class\\\\Administrator’@vma1 from 10.216.1.143 port 40528 ssh2 [preauth]

already tried different combinations all with similar results
‘class\Administrator’@vma1
class\\Administrator@vma1
class\\Administrator@vma1
Administrator@class.local
Administrator@class@vma1
Administrator/class
class/administrator
class\\Administrator@local
‘class\\Administrator’@local

2

Hi tomeksmi,

However AD users can login to appliance only using local console (login: class\Administrator) but not using ssh.

compare /etc/pam.d/login and /etc/pam.d/sshd - probably “login” was modified to suit AD needs, while sshd wasn’t…

Regards,
Jens

3

Please look at the files below and advise what should be changed:

vi-admin@vma1:/etc/pam.d[vc1.class.local]> cat login
#%PAM-1.0
auth requisite pam_nologin.so
auth [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad] pam_securetty.so
auth include common-auth
account include common-account
password include common-password
session required pam_loginuid.so
session include common-session
session optional pam_mail.so standard
session optional pam_ck_connector.so

vi-admin@vma1:/etc/pam.d[vc1.class.local]> cat sshd
#%PAM-1.0
auth requisite pam_nologin.so
auth include common-auth
account requisite pam_nologin.so
account include common-account
password include common-password
session required pam_loginuid.so
session include common-session

4

Hi tomeksmi,

Please look at the files below

I didn’t spot anything obvious, did you?

BTW, the warning reported in your initial message (“pam_unix2(sshd:auth): Unknown option: `try_first_pass’”) might be worth looking after, despite it not having any influence on the original problem.

Regards,
Jens

5

I also didn’t spot anything obvious and have no clue where to look further.

6

Hi tomeksmi,

I’ve successfully joined vMA aplliance […] to AD domain.

how did you do this, what was changed as a result of your actions? There are different approaches to AD user integration, which one did you follow?

Once you know how it should work, you can focus on spotting the differences when login in via console vs. login in via sshd.

It could be a question of presenting the correct user id (by sshd, to the underlying auth layers), it could be that searching is only performed when logging in locally (though at least at the PAM layer, there seem to be no such differences). It could be sshd restricting logins to a specific set of users.

Try turning on debugging for the PAM auth modules and compare the logins via console vs. via sshd, this seems a good starting point.

Regards,
Jens

7

[QUOTE=jmozdzen;29418]Hi tomeksmi,

I’ve successfully joined vMA aplliance […] to AD domain.

how did you do this, what was changed as a result of your actions? There are different approaches to AD user integration, which one did you follow?

Once you know how it should work, you can focus on spotting the differences when login in via console vs. login in via sshd.

It could be a question of presenting the correct user id (by sshd, to the underlying auth layers), it could be that searching is only performed when logging in locally (though at least at the PAM layer, there seem to be no such differences). It could be sshd restricting logins to a specific set of users.

Try turning on debugging for the PAM auth modules and compare the logins via console vs. via sshd, this seems a good starting point.

Regards,
Jens[/QUOTE]

Thanks for clues, I 'll trouble shoot it later on if I have time.
For now on one of my colleagues successfully integrated vMA with AD and enabled ssh login for AD users (out ot the box).
It must be me that made a mistake in vMA initial setup.

–
Best regards,
Tom

8

Hi Tom,

For now on one of my colleagues successfully integrated vMA

thank you for giving feedback - if you find the time to debug your steps, you’ll have a baseline to compare to. This can be a real advantage :slight_smile:

Best regards,
Jens

9

Thanks again for help!