> 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
This all worked fine and I was able to verify the account password : # ldapwhoami -vvv -h 127.0.0.1 -D uid=solaris,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net -x -w <some password> ldap_initialize( ldap://127.0.0.1 ) dn: uid=solaris,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net Result: Success (0) > 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 This part I have questions about. When I setup Solaris originally I used ldapclient init so it automatically creates (and updates based on the duaprofile) the configs. If I edit the file manually to make the changes you suggest, they will be overwritten at midnight when the ldapclient downloads the newest duaconfig. Instead I reconfigured using the ldapclient and the following settings: ldapclient manual -a credentialLevel=proxy -a authenticationMethod=tls:simple -a defaultSearchBase=dc=ipadomain,dc=net -a domainName=ipadomain.net -a defaultServerList=10.21.19.20 -a proxyDN=uid=solaris2,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net -a proxyPassword="changeme" -a objectClassMap=shadow:shadowAccount=posixAccount -a serviceSearchDescriptor=group:cn=groups,cn=compat,dc=ipadomain,dc=net -a serviceSearchDescriptor=passwd:cn=users,cn=compat,dc=ipadomain,dc=net I noted that in your example below you set passwd:cn=users,cn=accounts but then you later stated that it should actually be compat, so I did passwd:cn=users,cn=compat > > 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 > This part I'm really confused about. If I run that on the Solaris server I get : bash-3.00# certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap bash: certutil: command not found If I run that on the ipa DC I get : [root@ipadc1 ipa]# certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format. By following the Fedora 17 guide I had done this successfully: # certutil -N -d . [root@ipaserver ~]# scp cert8.db solaris.example.com:/var/ldap [root@ipaserver ~]# scp key3.db solaris.example.com:/var/ldap Is that functionally equivalent to what you were trying to do with the cert database or were you trying to do something different? > > 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. Could you clarify this a little bit? In the case of a FreeIPA native user, pam only lists pam_krb5.so modules so I assume that all login is handled by kerberos and not ldap. This doesn't explain how pam manages to set the user to the correct shell, because that shell information is obviously in ldap, yet I don't mention pam_ldap.so anywhere in my pam configurations. Also, if what you wrote below is true and AD users are authenticated not by kerberos, but by authenticated ldap binds, won't that totally fail if I don't mention pam_ldap in my pam configuration? > 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 > After -- 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
