On Wed, 04 Mar 2015, nat...@nathanpeters.com wrote:
I have successfully setup a Solaris 10 client so that internal FreeIPA
users can login, get the correct shell, and can sudo to root using ldap.
The problem is that the AD trusted users cannot login. I have read all
the freeIPA docs about enabling legacy clients, and they say to use the
compat tree. I'm pretty sure I'm already doing this. Here is the
contents of the ldap_client_file from my Solaris machine (which was
downloaded automatically when I did ldapclient init):
#
# Do not edit this file manually; your changes will be lost.Please use
ldapclient (1M) instead.
#
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= ipadc1.mydomain.net
NS_LDAP_SEARCH_BASEDN= dc=mydomain,dc=net
NS_LDAP_AUTH= none
You need to use authenticated bind and password proxying. There are two
actions here:
1. Add system account in IPA
To create a system account for NS_LDAP_BINDDN, use
# cat <<END >45-my-solaris-binddn.update
dn: uid=solaris,cn=sysaccounts,cn=etc,\$SUFFIX
add:objectclass:account,simplesecurityobject
add:uid:solaris
add:userPassword:"ohaimakethissimethingtoughtobreak"
add:passwordExpirationTime:20380119031407Z
add:nsIdleTimeout:0
END
# ipa-ldap-updater -l ./45-my-solaris-binddn.update
Frsing update file './45-my-solaris-binddn.update'
New entry: uid=solaris,cn=sysaccounts,cn=etc,dc=ipacloud,dc=test
The ipa-ldap-updater command was successful
2. Setup Solaris properly
NS_LDAP_AUTH=tls:simple
NS_LDAP_CREDENTIAL_LEVEL=proxy
NS_LDAP_BINDDN=uid=solaris,cn=sysaccounts,cn=etc,dc=ipacloud,dc=test
NS_LDAP_BINDPASSWD=ohaimakethissimethingtoughtobreak
NS_LDAP_CACHETTL=0
NS_LDAP_HOST_CERTPATH=/var/ldap
and put IPA's ca.crt (available on any IPA machine at /etc/ipa/ca.crt) into
/var/ldap's database with certutil:
# certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap
Obviously, you'll have your own $SUFFIX value in NS_LDAP_* entries.
And point LDAP_SERVICE_SEARCH_DESC for passwd to the compat tree.
NS_LDAP_SEARCH_REF= TRUE
NS_LDAP_SEARCH_TIME= 15
NS_LDAP_PROFILE= default
NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=mydomain,dc=net
NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,dc=mydomain,dc=net
NS_LDAP_BIND_TIME= 5
NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount
I see that the users are coming from the accounts tree and the groups are
coming from the compat tree. Is this right? The trust was created with
--enable-compat so I'm surprised that only the groups are coming from the
compat tree.
Does FreeIPA serve up an improperly configured DefaultDUAProfile
No, it serves a profile which is fine for non-AD case because all we
need to override is group management -- Solaris expects RFC2307, not
RFC2307bis. But for AD users you need to point passwd to compat tree
cn=users,cn=compat,.. as well -- we simulate LDAP objects there for AD
users on request.
Additionally, a default DUA profile assumes you are using Kerberos
authentication and thus don't need LDAP bind proxying to verify
passwords. It is not true in the case of AD users as they couldn't be
seen differently by Solaris. As result, you have to do LDAP bind against
compat tree. When the Schema Compatibility Plugin is configured to
expose users from trusted domains, their authentication is handled via
PAM 'system-auth' service. This service exists by default on Linux
systems and is provided by pam package as /etc/pam.d/system-auth. If
your FreeIPA install does not have default HBAC rule 'allow_all'
enabled, then make sure to define in IPA a special service called
'system-auth' and create an HBAC rule to allow access to anyone to this
rule on IPA masters.
As 'system-auth' PAM service is not used directly by any other
application, it is safe to use it for trusted domain users via
compatibility path.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
