[Freeipa-users] AD trust users cannot login to Solaris

[Alexander Bokovoy]

On Wed, 04 Mar 2015, nathan at 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