Description of problem: I am evaluating ipa-server 2.1.3 on RHEL6.1. Our environment has RHEL and Solaris 10 clients so I am testing to see how well Solaris 10 clients work with ipa-server. The generic instructions for configuring a Solaris 10 IPA client are lacking in that they only configure the client to use non-TLS (insecure) LDAP. I was able to get my Solaris 10 client to use LDAPS by adding a proxyagent (with a password) and a solaris profile to the IPA server LDAP directory. I also needed to add objectClass: shadowAccount to each user via ldapmodify to get the Solaris 10 pam_krb5.so library to allow access to the client once I got LDAPS working on the client. Here's the /var/ldap/ldap_client_file and the ldap_client_cred files I used on the client: ldap_client_file: # # 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= ipa01.foo.bar, ipa00.foo.bar NS_LDAP_SEARCH_BASEDN= dc=foo,dc=bar NS_LDAP_AUTH= tls:simple NS_LDAP_SEARCH_REF= FALSE NS_LDAP_SEARCH_SCOPE= one NS_LDAP_SEARCH_TIME= 30 NS_LDAP_SERVER_PREF= ipa01.foo.bar, ipa00.foo.bar NS_LDAP_CACHETTL= 43200 NS_LDAP_PROFILE= solaris NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd:dc=foo,dc=bar?sub NS_LDAP_SERVICE_SEARCH_DESC= group:dc=foo,dc=bar?sub NS_LDAP_SERVICE_SEARCH_DESC= shadow:dc=foo,dc=bar?sub NS_LDAP_SERVICE_SEARCH_DESC= netgroup:dc=foo,dc=bar?sub NS_LDAP_SERVICE_SEARCH_DESC= sudoers:dc=foo,dc=bar?sub NS_LDAP_BIND_TIME= 10 ldap_client_cred: # # Do not edit this file manually; your changes will be lost.Please use ldapclient (1M) instead. # NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=foo,dc=bar NS_LDAP_BINDPASSWD= {NS1}fbc123a921168126 I also needed to create a cert8.db and a key3.db by using certutil on the ca.crt from the IPA server. certutil for Solaris can be found in the SUNWtlsu package. I placed these files in the /var/ldap directory. Here is the LDIF from IPA for the proxyagent and profile that I manually added: # solaris, profile, foo.bar dn: cn=solaris,ou=profile,dc=foo,dc=bar preferredServerList: ipa01.foo.bar ipa00.foo.bar defaultServerList: ipa01.foo.bar ipa00.foo.bar serviceSearchDescriptor: passwd:dc=foo,dc=bar?sub serviceSearchDescriptor: group:dc=foo,dc=bar?sub serviceSearchDescriptor: shadow:dc=foo,dc=bar?sub serviceSearchDescriptor: netgroup:dc=foo,dc=bar?sub serviceSearchDescriptor: sudoers:dc=foo,dc=bar?sub bindTimeLimit: 10 credentialLevel: proxy profileTTL: 43200 searchTimeLimit: 30 defaultSearchScope: one followReferrals: FALSE defaultSearchBase: dc=foo,dc=bar objectClass: top objectClass: DUAConfigProfile authenticationMethod: tls:simple cn: solaris # proxyagent, profile, foo.bar dn: cn=proxyagent,ou=profile,dc=foo,dc=bar userPassword:: e1NTSEF9Mm53KytGeU81Z1dka1FLNUZlaDdXOHJkK093TEppY2NjRmt6Wnc9PQ= = objectClass: top objectClass: person sn: proxyagent cn: proxyagent Here'the snip from my user entry in IPA after I added the shadowAccount objectclass: -snip- cn: jlarson givenName: jlarson loginShell: /bin/bash mepManagedEntry: cn=jlarson,cn=groups,cn=accounts,dc=foo,dc=bar displayName: John Larson objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: mepOriginEntry objectClass: ntUser objectClass: shadowAccount sn: Larson gecos: John Larson homeDirectory: /home/jlarson -snip- Here is the error you will get when you try to SSH into a Solaris 10 IPA client with secure LDAP configured and no objectClass: shadowAccount on the IPA server: Mar 9 16:45:41 ipaclient01.foo.bar sshd[655]: [ID 800047 auth.info] Keyboard-interactive (PAM) userauth failed[13] while authenticating: No account present for user Version-Release number of selected component (if applicable):2.1.3 How reproducible:Any user added with the IPA web UI or CLI will lack objectClass: shadowAccount Steps to Reproduce: 1. Configure a Solaris10 IPA client as described above 2. Try to log in via SSH as a user with no objectClass: shadowAccount 3. Actual results: Mar 9 16:45:41 ipaclient01.foo.bar sshd[655]: [ID 800047 auth.info] Keyboard-interactive (PAM) userauth failed[13] while authenticating: No account present for user. Expected results: Mar 9 18:10:41 ipaclient01.foo.bar sshd[749]: [ID 800047 auth.info] Accepted keyboard-interactive for jlarson from 192.168.0.1 port 43980 ssh2 Additional info: What would be nice is a way to add profiles via the CLI or GUI and have a proxyagent installed as an option for ipa-server-install. Also an option to have the user template modified to add the objectClass: shadowAccount if people so desire. As it stands, having to modify every user via ldapmodify is going to be very cumbersome.
Is there any other way to do Solaris integration without requiring shadow and use password hashes that we already have in inside the IPA? This really seems cumbersome but is this the only option?
I'm not sure what you mean. If there's a better way to make LDAPS work on my Solaris clients, I am all ears.
I do not know how Solaris works, this is why I am asking you as you seem to know much more about Solaris than I do. I tried to find a way to explain to solaris client that it should not be looking for shadowAccount object class but could not find a way. Are you sure that there is no way on the client to specify a search filter in addition to base DN, scope and time?
There may be a way to map shadowAccount to posixAccount in the profile. Let me experiment a bit and get back to you.
In any event, a facility to manage LDAP profiles and a proxyagent in IPA either at ipa-server-install time or via the command line/web UI later would be useful for heterogenous client environments that include Solaris.
Try adding this to the profile you're using. objectClassMap: shadow:shadowAccount=posixAccount
I have tried that and many other permutations with no luck. # solaris, profile, foo.bar dn: cn=solaris,ou=profile,dc=foo,dc=bar objectclassMap: shadow:shadowAccount=posixAccount defaultSearchScope: one preferredServerList: ipa01.foo.bar ipa00.foo.bar defaultServerList: ipa01.foo.bar ipa00.foo.bar serviceSearchDescriptor: passwd:dc=foo,dc=bar?sub serviceSearchDescriptor: group:dc=foo,dc=bar?sub serviceSearchDescriptor: netgroup:dc=foo,dc=bar?sub serviceSearchDescriptor: sudoers:dc=foo,dc=bar?sub serviceSearchDescriptor: shadow:dc=foo,dc=bar?sub bindTimeLimit: 10 credentialLevel: proxy profileTTL: 43200 searchTimeLimit: 30 followReferrals: FALSE defaultSearchBase: dc=foo,dc=bar objectClass: top objectClass: DUAConfigProfile authenticationMethod: tls:simple cn: solaris The /var/ldap/ldap_client_file on the Solaris 10 client after restarting ldap/client: # Do not edit this file manually; your changes will be lost.Please use ldapclien t (1M) instead. # NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_SERVERS= ipa01.foo.bar, ipa00.foo.bar NS_LDAP_SEARCH_BASEDN= dc=foo,dc=bar NS_LDAP_AUTH= tls:simple NS_LDAP_SEARCH_REF= FALSE NS_LDAP_SEARCH_SCOPE= one NS_LDAP_SEARCH_TIME= 30 NS_LDAP_SERVER_PREF= ipa01.foo.bar, ipa00.foo.bar NS_LDAP_CACHETTL= 43200 NS_LDAP_PROFILE= solaris NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd:dc=foo,dc=bar?sub NS_LDAP_SERVICE_SEARCH_DESC= group:dc=foo,dc=bar?sub NS_LDAP_SERVICE_SEARCH_DESC= netgroup:dc=foo,dc=bar?sub NS_LDAP_SERVICE_SEARCH_DESC= sudoers:dc=foo,dc=bar?sub NS_LDAP_SERVICE_SEARCH_DESC= shadow:dc=foo,dc=bar?sub NS_LDAP_BIND_TIME= 10 NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount I have name-service-cache disabled and I still can't login with a test user with no objectClass=shadowAccount and the user with this attribute is able to log in via SSH. I will keep trying a few other combinations of attributeMap/objectclassMap and see if I can find one that works. Thanks for the suggestion though and keep them coming if you can think of any others.
I tried to log in again as the user with no objectClass:shadowAccount and it worked. This is with the suggestion you offered. I must have fat-fingered the password earlier. This looks like a good fix for the issue on Solaris 10 clients. I would suggest one of the following: 1) Update the documentation to include the instructions for creating a Solaris proxyagent and profile and client set-up for TLS LDAPS to include ldapclient command syntax and cert8.db/key3.db creation via certutil. 2) Include a Solaris proxyagent and profile as an option or by default when users run ipa-server-install. I can assist with specific instructions if you need them. I am also moving on to sudo and netgroup testing and integration for Solaris clients as well so I should have more info in the coming week or so. Thanks again for the fix.
I got sudo to work on the Solaris10 client by doing the following: Install the following packages from Blastwave (http://www.blastwave.org/) application CSWbdb4 berkeleydb4 - Embedded database libraries and utilities system CSWcommon common - common files and dirs for CSW packages system CSWlibnet libnet - the libnet packet construction library application CSWoldaprt openldap_rt - OpenLDAP runtime libraries (oldaprt) application CSWossl openssl - Openssl meta package application CSWossldevel openssl_devel - Openssl development support application CSWosslrt openssl_rt - Openssl runtime libraries application CSWosslutils openssl_utils - Openssl binaries and related tools application CSWsasl sasl - Simple Authentication and Security Layer application CSWsudo-common sudo_common - sudo common files application CSWsudoldap sudo_ldap - Provides limited super user privileges (LDAP Enabled) Configure /opt/csw/etc/openldap/ldap.conf as follows: # This file should be world readable but not world writable. #BASE dc=example, dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never base dc=foo,dc=bar timelimit 120 bind_timelimit 120 idle_timelimit 3600 uri ldaps://ipa01.foo.bar ldaps://ipa00.foo.bar ssl start_tls sudoers_base ou=SUDOers,dc=foo,dc=bar ssl on TLS_REQCERT allow TLS_CACERT /etc/openldap/cacerts/ca.crt TLS_CACERTFILE /etc/openldap/cacerts/ca.crt TLS_CACERTDIR /etc/openldap/cacerts -snip- Obviously place http://<ipa server>/ipa/config/ca.crt in /etc/openldap/cacerts
Filed RFE https://fedorahosted.org/freeipa/ticket/2561 to add agent Filed doc bug https://bugzilla.redhat.com/show_bug.cgi?id=805080
Moving to right component.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Moving to rawhide as this is still valid RFE.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.