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

[nathan at nathanpeters.com]

> 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 at 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 at ipaserver ~]# scp cert8.db solaris.example.com:/var/ldap
[root at 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