7:04 p.m.
Configuring a Solaris 11.3 system as a FreeIPA client. I've read various articles,
mail list archives, and pages found on google trying to figure out how to properly make
this work. So far, I've only gotten the ability to do su - user(a)domain.tld and check
getent passwd/group. This successfully works. The things that do not work are ssh and
console logins. This is what I've tried so far:
Setting authenticationMethod to 'simple:tls'
-> My service account never seems to work and the log says: "libsldap: Status:
53 Mesg: openConnection: simple bind failed - DSA is unwilling to perform"
-> "libsldap: Status: 49 Mesg: openConnection: simple bind failed - Invalid
credentials" - This isn't the case as I've tried the credentials multiple
times using ldapsearch commands with success. My credentials for my users are correct
since I can login to a CentOS 6 and CentOS 7 client perfectly fine.
These are the steps I took:
-> Create host in IPA
-> ipa-getkeytab and transferred it to the client
-> Created nss database with CA certificate and placed it in /var/ldap with proper
permissions
-> Configured /etc/krb5/krb5.conf
-> Configured nsswitch.conf to be files ldap
-> Configured /etc/pam.d/* files accordingly
-> Used ldapclient init on the client
Here is my kinit and ldap tests.
# kinit admin
Password for admin(a)IPA.EXAMPLE.COM:
kinit: no ktkt_warnd warning possible
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin(a)IPA.EXAMPLE.COM
Valid starting Expires Service principal
09/13/17 16:22:29 09/14/17 16:22:29 krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM
renew until 09/20/17 16:22:29
# ldaplist -l passwd louis.abel
dn: uid=louis.abel,cn=users,cn=compat,dc=ipa,dc=example,dc=com
cn: Louis Abel
objectClass: posixAccount
objectClass: top
gidNumber: 1006800013
gecos: Louis Abel
uidNumber: 25439
loginShell: /bin/bash
homeDirectory: /home/louis.abel
uid: louis.abel(a)ad.example.com
uid: louis.abel
# ldaplist -l passwd louis.abel2
dn: uid=louis.abel2,cn=users,cn=compat,dc=ipa,dc=example,dc=com
cn: Louis Abel
objectClass: posixAccount
objectClass: top
gidNumber: 1006800001
gecos: Louis Abel
uidNumber: 1006800001
loginShell: /bin/bash
homeDirectory: /home/louis.abel2
uid: louis.abel2(a)ipa.example.com
uid: louis.abel2
dn: uid=louis.abel2,cn=users,cn=compat,dc=ipa,dc=example,dc=com
cn: Louis Abel
objectClass: posixAccount
objectClass: ipaOverrideTarget
objectClass: top
gidNumber: 1006800001
gecos: Louis Abel
uidNumber: 1006800001
ipaAnchorUUID: :IPA:ipa.example.com:8babb9a8-5aaf-11e7-9769-00505690319e
loginShell: /bin/bash
homeDirectory: /home/louis.abel2
uid: louis.abel2
My pam configuration files:
/etc/pam.d/other
auth definitive pam_user_policy.so.1
auth sufficient pam_krb5.so.1
auth requisite pam_authtok_get.so.1
auth required pam_dhkeys.so.1
auth binding pam_unix_auth.so.1 server_policy
auth required pam_unix_cred.so.1
auth sufficient pam_krb5.so.1
account requisite pam_roles.so.1
account definitive pam_user_policy.so.1
account binding pam_unix_account.so.1 server_policy
account required pam_unix_account.so.1
account required pam_krb5.so.1
account required pam_tsol_account.so.1
session definitive pam_user_policy.so.1
session required pam_unix_session.so.1
password definitive pam_user_policy.so.1
password include pam_authtok_common
password sufficient pam_krb5.so.1
password required pam_authtok_store.so.1 server_policy
/etc/pam.d/login
auth requisite pam_authtok_get.so.1
auth required pam_dhkeys.so.1
auth required pam_unix_cred.so.1
auth sufficient pam_krb5.so.1 try_first_pass
auth required pam_unix_auth.so.1 use_first_pass
auth required pam_dial_auth.so.1
# ldapclient list
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= uid=solaris,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com
NS_LDAP_BINDPASSWD= removed
NS_LDAP_SERVERS= pentl01.ipa.example.com, pentl02.ipa.example.com,
pentl03.ipa.example.com, sentl01.ipa.example.com, sentl02.ipa.example.com,
sentl03.ipa.example.com
NS_LDAP_SEARCH_BASEDN= dc=ipa,dc=example,dc=com
NS_LDAP_AUTH= tls:simple
NS_LDAP_SEARCH_REF= TRUE
NS_LDAP_SEARCH_TIME= 15
NS_LDAP_CACHETTL= 6000
NS_LDAP_PROFILE= default solaris_authssl
NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=ipa,dc=example,dc=com
NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=compat,dc=ipa,dc=example,dc=com
NS_LDAP_SERVICE_SEARCH_DESC= netgroup:cn=ng,cn=compat,dc=ipa,dc=example,dc=com
NS_LDAP_SERVICE_SEARCH_DESC= ethers:cn=computers,cn=accounts,dc=ipa,dc=example,dc=com
NS_LDAP_SERVICE_SEARCH_DESC= sudoers:ou=sudoers,dc=ipa,dc=example,dc=com
NS_LDAP_BIND_TIME= 5
NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount
NS_LDAP_OBJECTCLASSMAP= passwd:posixAccount=posixaccount
NS_LDAP_OBJECTCLASSMAP= group:posixGroup=posixgroup
nsswitch changes:
passwd: files ldap [NOTFOUND=return]
group: files ldap [NOTFOUND=return]
This is what I looked at:
https://www.redhat.com/archives/freeipa-users/2013-January/msg00021.html
https://www.redhat.com/archives/freeipa-users/2015-January/msg00017.html
http://etcfstab.com/oraclelinux/solaris_n_freeipa.html
https://mkosek.fedorapeople.org/publican_site/en-US/FreeIPA/3.3/html/Free...
Anyone have better experience or any documentation that could help?
10:02 a.m.
I should probably mention that IPA users have started working. But not my AD users.
[root@rhn2 tmp]# ssh -l louis.abel2(a)ipa.example.com devu16 -q
Password:
Last login: Thu Sep 14 07:57:55 2017 from rhn2.example.com
Could not chdir to home directory /home/louis.abel2: No such file or directory
Oracle Corporation SunOS 5.11 11.3 June 2017
-bash-4.4$ logout
[root@rhn2 tmp]# ssh -l louis.abel(a)ad.example.com devu16 -q
Password:
Password:
AD users seem to be suffering from the same errors:
libsldap: Status: 53 Mesg: openConnection: simple bind failed - DSA is unwilling to
perform
libsldap: Status: 49 Mesg: openConnection: simple bind failed - Invalid credentials
10:08 a.m.
Louis Abel via FreeIPA-users wrote:
I should probably mention that IPA users have started working. But
not my AD users.
[root@rhn2 tmp]# ssh -l louis.abel2(a)ipa.example.com devu16 -q
Password:
Last login: Thu Sep 14 07:57:55 2017 from rhn2.example.com
Could not chdir to home directory /home/louis.abel2: No such file or directory
Oracle Corporation SunOS 5.11 11.3 June 2017
-bash-4.4$ logout
[root@rhn2 tmp]# ssh -l louis.abel(a)ad.example.com devu16 -q
Password:
Password:
AD users seem to be suffering from the same errors:
libsldap: Status: 53 Mesg: openConnection: simple bind failed - DSA is unwilling to
perform
libsldap: Status: 49 Mesg: openConnection: simple bind failed - Invalid credentials
Not sure why some users would work and some wouldn't but I'd suspect the
bind password in your ldapclient config.
rob
10:13 a.m.
On Thu, Sep 14, 2017 at 11:08:54AM -0400, Rob Crittenden via FreeIPA-users wrote:
Louis Abel via FreeIPA-users wrote:
> I should probably mention that IPA users have started working. But not my AD users.
>
> [root@rhn2 tmp]# ssh -l louis.abel2(a)ipa.example.com devu16 -q
> Password:
> Last login: Thu Sep 14 07:57:55 2017 from rhn2.example.com
> Could not chdir to home directory /home/louis.abel2: No such file or directory
> Oracle Corporation SunOS 5.11 11.3 June 2017
> -bash-4.4$ logout
> [root@rhn2 tmp]# ssh -l louis.abel(a)ad.example.com devu16 -q
> Password:
> Password:
>
> AD users seem to be suffering from the same errors:
>
> libsldap: Status: 53 Mesg: openConnection: simple bind failed - DSA is unwilling to
perform
> libsldap: Status: 49 Mesg: openConnection: simple bind failed - Invalid credentials
>
Not sure why some users would work and some wouldn't but I'd suspect the
bind password in your ldapclient config.
Another thing that bit me in the past was that since on the IPA server,
the password binds against AD users are intercepted and turned into a
PAM conversation against the system-auth service, HBAC must allow the
system-auth service on the IDM server itself.
(Check /var/log/secure on the IDM server for messages from pam-sss.so..)
10:29 a.m.
Perhaps, but I'm not sure it's the bind password. When I've done binds with
the proxy account using for example, ldapsearch, it works without issue. I've also
attempted to change the password and do ldapclient uninit and ldapclient init with the new
password. So IPA users are working but not AD trust users.
# ldapsearch -x -LLL -D
'uid=solaris,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com' -W uid=louis.abel
Enter LDAP Password:
dn: uid=louis.abel,cn=users,cn=compat,dc=ipa,dc=example,dc=com
cn: Louis Abel
objectClass: posixAccount
objectClass: top
gidNumber: 1006800013
gecos: Louis Abel
uidNumber: 25439
loginShell: /bin/bash
homeDirectory: /home/louis.abel
uid: louis.abel(a)ad.example.com
uid: louis.abel
10:34 a.m.
On to, 14 syys 2017, Rob Crittenden via FreeIPA-users wrote:
Louis Abel via FreeIPA-users wrote:
> I should probably mention that IPA users have started working. But not my AD users.
>
> [root@rhn2 tmp]# ssh -l louis.abel2(a)ipa.example.com devu16 -q
> Password:
> Last login: Thu Sep 14 07:57:55 2017 from rhn2.example.com
> Could not chdir to home directory /home/louis.abel2: No such file or directory
> Oracle Corporation SunOS 5.11 11.3 June 2017
> -bash-4.4$ logout
> [root@rhn2 tmp]# ssh -l louis.abel(a)ad.example.com devu16 -q
> Password:
> Password:
>
> AD users seem to be suffering from the same errors:
>
> libsldap: Status: 53 Mesg: openConnection: simple bind failed - DSA is unwilling to
perform
> libsldap: Status: 49 Mesg: openConnection: simple bind failed - Invalid credentials
>
Not sure why some users would work and some wouldn't but I'd suspect the
bind password in your ldapclient config.
Another thing is that compat tree
wasn't actually designed to have IPA
users addressed as fully-qualified ones. E.g.
louis.abel2(a)ipa.example.com is wrong, it was expected to be louis.abel2.
Using fqdn user name for IPA user causes some troubles to slapi-nis code
because it forces it to go through SSSD instead of relying on the LDAP
state.
--
/ Alexander Bokovoy
10:36 a.m.
On to, 14 syys 2017, Jakub Hrozek via FreeIPA-users wrote:
On Thu, Sep 14, 2017 at 11:08:54AM -0400, Rob Crittenden via
FreeIPA-users wrote:
> Louis Abel via FreeIPA-users wrote:
> > I should probably mention that IPA users have started working. But not my AD
users.
> >
> > [root@rhn2 tmp]# ssh -l louis.abel2(a)ipa.example.com devu16 -q
> > Password:
> > Last login: Thu Sep 14 07:57:55 2017 from rhn2.example.com
> > Could not chdir to home directory /home/louis.abel2: No such file or directory
> > Oracle Corporation SunOS 5.11 11.3 June 2017
> > -bash-4.4$ logout
> > [root@rhn2 tmp]# ssh -l louis.abel(a)ad.example.com devu16 -q
> > Password:
> > Password:
> >
> > AD users seem to be suffering from the same errors:
> >
> > libsldap: Status: 53 Mesg: openConnection: simple bind failed - DSA is unwilling
to perform
> > libsldap: Status: 49 Mesg: openConnection: simple bind failed - Invalid
credentials
> >
>
> Not sure why some users would work and some wouldn't but I'd suspect the
> bind password in your ldapclient config.
Another thing that bit me in the past was that since on the IPA server,
the password binds against AD users are intercepted and turned into a
PAM conversation against the system-auth service, HBAC must allow the
system-auth service on the IDM server itself.
(Check /var/log/secure on the IDM server for messages from pam-sss.so..)
This one as
well. It is documented in both slapi-nis and overall IPA
documentation.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...
5.4.1:
----
If the host-based access control (HBAC) allow_all rule is disabled,
enable the system-auth service on the IdM server, which allows
authentication of the AD users.
----
--
/ Alexander Bokovoy
1:28 p.m.
Jakub, you might be onto something.
Sep 14 18:11:08 pentl01.ipa.example.com ns-slapd: pam_sss(system-auth:auth):
authentication failure; logname= uid=389 euid=389 tty= ruser= rhost=
user=louis.abel(a)ad.example.com
Sep 14 18:11:08 pentl01.ipa.example.com ns-slapd: pam_sss(system-auth:auth): received for
user louis.abel(a)ad.example.com: 7 (Authentication failure)
Would this mean that I need an HBAC policy allowing specific/all users system-auth against
the IPA servers? Or what would you suggest? It does seem a little overkill if I did that.
Unless there's a better way.
1:39 p.m.
On to, 14 syys 2017, Louis Abel via FreeIPA-users wrote:
Jakub, you might be onto something.
Sep 14 18:11:08 pentl01.ipa.example.com ns-slapd: pam_sss(system-auth:auth):
authentication failure; logname= uid=389 euid=389 tty= ruser= rhost=
user=louis.abel(a)ad.example.com
Sep 14 18:11:08 pentl01.ipa.example.com ns-slapd: pam_sss(system-auth:auth): received for
user louis.abel(a)ad.example.com: 7 (Authentication failure)
Would this mean that I need an HBAC policy allowing specific/all users
system-auth against the IPA servers? Or what would you suggest? It does
seem a little overkill if I did that. Unless there's a better way.
If you are
authenticating AD users over the compat tree, you need to
create an HBAC rule that allows all users to access system-auth HBAC
service on the IPA master.
None of existing services (ssh, login, etc) use system-auth directly.
Its the only direct user is the Schema Compatibility plugin that handles
cn=compat tree.
This is documented in Windows Integration Guide, as I give you a link in
the other email.
--
/ Alexander Bokovoy
2:25 p.m.
On Thu, Sep 14, 2017 at 06:28:50PM -0000, Louis Abel via FreeIPA-users wrote:
Jakub, you might be onto something.
Sep 14 18:11:08 pentl01.ipa.example.com ns-slapd: pam_sss(system-auth:auth):
authentication failure; logname= uid=389 euid=389 tty= ruser= rhost=
user=louis.abel(a)ad.example.com
Sep 14 18:11:08 pentl01.ipa.example.com ns-slapd: pam_sss(system-auth:auth): received for
user louis.abel(a)ad.example.com: 7 (Authentication failure)
Would this mean that I need an HBAC policy allowing specific/all users system-auth
against the IPA servers? Or what would you suggest? It does seem a little overkill if I
did that. Unless there's a better way.
Well, yes and no.
If it was the HBAC access control that was kicking you out, I would have
expected the error code to be different (6 is typically returned for
access denied).
So I would also suggest to increase the sssd debug log on the server and
try the login attempt again, then check out sssd logs.
6:25 p.m.
Thank you for pointing that out. I've put sssd into debug to see what I can find. Is
there anything specific I should look for in the logs? Or is there anything specific I can
put here. The current set of logs of my login (based on time) is 2643 lines.
1:58 a.m.
On 15 Sep 2017, at 01:25, Louis Abel via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
Thank you for pointing that out. I've put sssd into debug to see what I can find. Is
there anything specific I should look for in the logs? Or is there anything specific I can
put here. The current set of logs of my login (based on time) is 2643 lines.
Maybe try grepping for errors? grep 0x00 *.log
Or feel free to send the logs to me if you need help.
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
11:54 a.m.
Thank you again for assisting. I did a little more digging myself and realized something
wrong about my /etc/pam.d/system-auth and /etc/pam.d/password-auth files. The auth line
for pam_sss.so had both use_first_pass and forward_pass. It seems to me that these counter
each other in some way. Once I took off use_first_pass, password logins to the domain
controllers and to my solaris 11 clients are working. I'm no longer getting an error
7, I'm instead getting successes in /var/log/secure.
Only issue now is it seems my pam configuration on Solaris must be incorrect or there is a
major bug - while the password works, I cannot open a session. Trying to su into an
account while on the system as root gives me some assertion error and then aborted. The
login with user@domain works (which is not what I want to use).
Solaris 10 on the other hand gives me "no legal authentication methods". Might
be a pam/nsswitch misconfiguration. I'll report back if I figure it out.
2415
days inactive
2422
days old
freeipa-users@lists.fedorahosted.org
12 comments
4 participants
participants (4)
-
Alexander Bokovoy -
Jakub Hrozek -
Louis Abel -
Rob Crittenden