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

[Alexander Bokovoy]

On Thu, 05 Mar 2015, nathan at nathanpeters.com wrote:
>> 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
Right.


>I noted that in your example below you set passwd:cn=users,cn=accounts
That was a quote of your config, not mine.

>
>but then you later stated that it should actually be compat, so I did
>passwd:cn=users,cn=compat
Yes, this is what I wanted you to do.

>
>>
>> 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
You need to download certutil package for Solaris. Others had some
success in using a database copied from IPA server but this is generally
not something that we can rely on.

>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?
More or less -- create an NSS database and add a CA cert there.

>> 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.
PAM has different stages -- authentication, session, etc. Shell,
UID/GID and other parameters are coming from nsswitch interface, not
PAM.

On the other hand PAM allows to stack multiple modules to perform the
same action so you can have both pam_krb5 and pam_ldap in the stack and
cover both Kerberos ticket and password-based logins.

>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?
Yep, it would fail but there are few separate things we need to clarify
first.

Did you add your Solaris host into IPA? Did you create a keytab for
it? Is your Solaris host FQDN 

If answers are yes, yes, and yes, then AD users, when connecting to
Solaris host from their Windows machines will attempt to obtain Kerberos
ticket and IPA KDC will grant a service ticket to them thanks to
cross-forest trust. When AD user using putty would present that ticket
to Solaris, chances are that pam_krb5 will accept it and allow to login.

When AD users have no Kerberos ticket, then they would attempt to do a
password login. To verify this login you would need to bind to IPA
LDAP's as AD user, using its DN from the compat tree and then actual
authentication would happen on IPA master as part of LDAP bind
processing.


-- 
/ Alexander Bokovoy