On Thu, 05 Mar 2015, nat...@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@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?
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

--
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

Reply via email to