Re: [Freeipa-users] ipactl start fails for no apparent reason
On Wed, Apr 01, 2015 at 01:20:44PM +0200, Martin Babinsky wrote: On 04/01/2015 10:14 AM, Traiano Welcome wrote: Hi Martin Thanks for the response. Check results inline: On Wed, Apr 1, 2015 at 10:37 AM, Martin Babinsky mbabi...@redhat.com wrote: On 04/01/2015 09:20 AM, Traiano Welcome wrote: Some information from the dirsrv error log (sanitized: XYZ = realm): [01/Apr/2015:11:01:49 +0300] - 389-Directory/1.3.1.6 B2014.160.2139 starting up [01/Apr/2015:11:01:49 +0300] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=idm,dc=local [01/Apr/2015:11:01:49 +0300] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=idm,dc=local--no CoS Templates found, which should be added before the CoS Definition. [01/Apr/2015:11:01:49 +0300] NSMMReplicationPlugin - CleanAllRUV Task: cleanAllRUV task found, resuming the cleaning of rid(6)... [01/Apr/2015:11:01:49 +0300] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=idm,dc=local--no CoS Templates found, which should be added before the CoS Definition. [01/Apr/2015:11:01:49 +0300] - slapd started. Listening on All Interfaces port 389 for LDAP requests [01/Apr/2015:11:01:49 +0300] - Listening on All Interfaces port 636 for LDAPS requests [01/Apr/2015:11:01:49 +0300] - Listening on /var/run/slapd-IDM-LOCAL.socket for LDAPI requests [01/Apr/2015:11:01:49 +0300] set_krb5_creds - Could not get initial credentials for principal [ldap/kwtpr-idm-mstr@] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not found) [01/Apr/2015:11:01:49 +0300] set_krb5_creds - Could not get initial credentials for principal [ldap/kwtpr-idm-mstr@] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not found) [01/Apr/2015:11:01:49 +0300] set_krb5_creds - Could not get initial credentials for principal [ldap/kwtpr-idm-mstr@] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not found) [01/Apr/2015:11:01:49 +0300] set_krb5_creds - Could not get initial credentials for principal [ldap/kwtpr-idm-mstr@] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not found) [01/Apr/2015:11:01:49 +0300] set_krb5_creds - Could not get initial credentials for principal [ldap/kwtpr-idm-mstr@] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not found) [01/Apr/2015:11:01:49 +0300] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) [01/Apr/2015:11:01:49 +0300] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) [01/Apr/2015:11:01:49 +0300] NSMMReplicationPlugin - agmt=cn=meTokwtard-idm-slve.idm.local (kwtard-idm-slve:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) [01/Apr/2015:11:01:49 +0300] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) [01/Apr/2015:11:01:49 +0300] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) [01/Apr/2015:11:01:49 +0300] NSMMReplicationPlugin - agmt=cn=meToindpr-idm-slve.idm.local (indpr-idm-slve:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) [01/Apr/2015:11:01:50 +0300] - slapd shutting down - signaling operation threads [01/Apr/2015:11:01:50 +0300] - slapd shutting down - waiting for 27 threads to terminate [01/Apr/2015:11:01:50 +0300] - slapd shutting down - closing down internal subsystems and plugins [01/Apr/2015:11:01:58 +0300] NSMMReplicationPlugin - CleanAllRUV Task: Cleaning rid (6)... [01/Apr/2015:11:01:58 +0300] NSMMReplicationPlugin - CleanAllRUV Task: Waiting to process all the updates from the deleted replica... [01/Apr/2015:11:01:58 +0300] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to be online... [01/Apr/2015:11:01:58 +0300] NSMMReplicationPlugin - CleanAllRUV Task: Server shutting down. Process will resume at server startup [01/Apr/2015:11:02:09 +0300] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 110 (Connection timed out)
Re: [Freeipa-users] Understanding the migration mode
I tried enabling crypt for experimentation, and things seem to work well for both NIS and SSSD clients. I noticed that the crypt format that the NIS plugin in IPA provides is the traditional crypt format with a 2 character salt and 13 character hash. NIS clients can understand newer crypt encodings which allow MD5, SHA256 and SHA512 ( https://docs.python.org/3/library/crypt.html) . Is it possible to force one of those as the storage scheme in the directory server ? On Tue, Mar 31, 2015 at 12:04 PM, Prasun Gera prasun.g...@gmail.com wrote: I've figured it out. You are right. SSSD triggers key generation. For migrated clients though, since ypbind still runs and the NIS-plugin serves maps, they authenticate first using NIS before SSSD. If ypbind is stopped, it is forced to use SSSD, and then it triggers the migration. Thanks for persisting with this. It's pretty clear how it works now. On Tue, Mar 31, 2015 at 11:32 AM, Prasun Gera prasun.g...@gmail.com wrote: ? SSSD does not seem to be involved as user is found in the /etc/passwd and this SSSD should not do anything. It's not a local user. There's no entry in /etc/passwd. Here's the relevant sssd log sssd_ssh (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 'testuser2' matched without domain, user is testuser2 (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [client_recv] (0x0200): Client disconnected! (Tue Mar 31 03:53:17 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Received client version [0]. sssd_pam (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: ipadomain (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): user: testuser2 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: host_ip (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 23983 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): logon name: testuser2 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [0][ipadomain] (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]. (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 27 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [client_recv] (0x0200): Client disconnected! -- 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
Re: [Freeipa-users] Openvpn and Certificates
And et voila! It works! Although it does feel a bit hacky :) I do it the same way as I control my systems and can be sure there is one user per system for VPN access. Works nicely. Is it possible to manage key revocation? I understand that this mechanism is mostly quite broken. How long are you making Certificates valid for? -- 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
Re: [Freeipa-users] Openvpn and Certificates
On Thu, 02 Apr 2015, Andrew Holway wrote: And et voila! It works! Although it does feel a bit hacky :) I do it the same way as I control my systems and can be sure there is one user per system for VPN access. Works nicely. Is it possible to manage key revocation? I understand that this mechanism is mostly quite broken. How long are you making Certificates valid for? Standard mechanism works fine -- 'ipa cert-revoke'. However, you need to deliver CRL to OpenVPN server because OpenVPN only supports checking CRL from a file system. Theoretically one could make a systemd socket unit that would use 'nc' and curl to pick up CRL from a CA every time OpenVPN asks for it (on each client connection) or provide a cached version of it. An easiest way is to make CRL retrieval periodical and populate whatever directory or file crl-verify is pointed to. -- / 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
Re: [Freeipa-users] Openvpn and Certificates
On Thu, 02 Apr 2015, Andrew Holway wrote: Is it possible to generate certs without the host having an entry in the DNS? Yes. Create a host with 'ipa host-add --force' and then use normal ways to generate certificates for this host. -- / 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
Re: [Freeipa-users] freeipa behind a load balancer
OK, to keep this updated. With some Kerberos Guru's we have looked how IPA behaves when you change all DNS names, PTR's and A's to the LB-er and all time you get a ticket from the server service principal itself. With kvno you can get a ticket for the loadbalancer but when you run your failing script you also see a ticket coming back from the ipa server itself. I have seen some mailings from last year too with no solution... it seems to be a showstopper on that part :( 2015-04-01 20:41 GMT+02:00 Matt . yamakasi@gmail.com: Hi, I'm not gicing up on this, so I'm testing. I'm unsure at the moment about the keytab. The keytab is normally for the user that needs to be able to do stuff, but in this case we need one for the loadbalancer name or the client maybe combined ? I lost that overvieuw... would be nice to get some advice here. Thanks! Matt 2015-03-31 21:23 GMT+02:00 Matt . yamakasi@gmail.com: OK, but we need to do this using IPA or (as IPA does some things different it seems). Anyone testing this perhaps ? (/me is multitasking atm) 2015-03-31 20:22 GMT+02:00 Rob Crittenden rcrit...@redhat.com: Brendan Kearney wrote: On Tue, 2015-03-31 at 13:54 -0400, Simo Sorce wrote: On Tue, 2015-03-31 at 13:50 -0400, Simo Sorce wrote: But IPA is more complex and some operations will be performed directly against the specific server name, so you need to keep 2 sets of keys (one for the server name and one for the load balancer name), but that does not work right now. One experiment that can be done is to remove all per-server HTTP services for the IPA server, and instead add their name as aliases on the common load-balancer name. This would mean that all IPA servers would have just one key in their HTTP keytab, but the KDC would release tickets readable by that key for any name the clients may ask for. It is a bit tricky, every time you build a replica you want to load-balance you'll have to go back and remove the service and switch keytabs, but it may be an option. Of course if you brick IPA then you get to keep the pieces :-) Simo. careful there, as kerberos balks at CNAME records. i think you need to use A records. i ran into a couple odd issues and decided to only use A/PTR records for my stuff and never went exploring for options/alternatives. Not DNS aliases, Kerberos principal alises. rob -- 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 -- 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
Re: [Freeipa-users] RHEL 5 client?
On Thu, 02 Apr 2015, Guertin, David S. wrote: Can you try searching the compat tree with ldapsearch to see if an entry turns up? IIRC you need to search for a particular entry, not for any (not ie cn=*), but if you crank up the debug_level in the domain section, then sssd should log the searches to /var/log/sssd/sssd_default.log Here's the result of ldapsearch on the RHEL 5 client (the same command works on RHEL 6): # ldapsearch -h middlebury.edu -p 389 -D 'MIDD\admin' -W -b dc=middlebury,dc=edu -s sub cn=juser,cn=users,dc=middlebury,dc=edu Enter LDAP Password: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No credentials cache found) This is wrong use of ldapsearch -- if you are using simple bind, make sure you tell ldapsearch about it. However, I'm not sure what you wanted to show as both hostname and base DN are different from what SSSD tries in the logs below. Also, unlike Active Directory, IPA LDAP does not (yet) accept short version of bind DN, you have to specify it fully. If you wanted to have Kerberos auth working on RHEL5, that is something that might or might not work for AD users depending on many circumstances, mostly related to the need to manually configure krb5.conf to know about AD realm and how to contact servers there but also due to possible issues with auth_to_local rulesets (if they even exist in that Kerberos library version). In case of AD users there is a sequence to follow for LDAP authentication if you want to repeat what SSSD does: 1. Search user with filter '(uid=username@domain)' to get the entry into compat tree. 2. Bind as uid=username@domain,cn=users,cn=compat,$BASEDN to trigger authentication check. This is how various LDAP-based NSS modules work, be it nss_ldap or pam-nss-ldapd, or SSSD. So, let's say, you have kerberos keytab with a host principal in /etc/krb5.keytba. The sequence to emulate what SSSD does would be kinit -k host/`hostname` ldapsearch -Y GSSAPI -H ldap://genet.ipa.middlebury.edu \ -b cn=compat,dc=ipa,dc=middlebury,dc=edu -s sub \ '(uid=ad...@middlebury.edu)' As result, we have 'ad...@middlebury.edu' inserted in the compat tree, and can do a bind as 'uid=ad...@middlebury.edu,cn=users,cn=compat,dc=ipa,dc=middlebury,dc=edu' ldapsearch -x -H ldap://genet.ipa.middlebury.edu \ -D 'uid=ad...@middlebury.edu,cn=users,cn=compat,dc=ipa,dc=middlebury,dc=edu' \ -b cn=compat,dc=ipa,dc=middlebury,dc=edu -s sub \ '(uid=ad...@middlebury.edu)' This would reproduce what SSSD was supposed to do. If you get these ldapsearches to work, we can look at what is SSSD doing. -- / 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
Re: [Freeipa-users] Understanding the migration mode
I had a look at ldap/servers/plugins/pwdstorage/crypt_pwd.c, and it looks like it is hardcoded in crypt_pw_enc, which uses the default DES crypt method. This only affects the encoding. The verification of passwords works with any of MD5 or SHA-* schemes since the underlying crypt function in recent glibcs supports them. Would it make sense to add the other options to the encoding function ? On Thu, Apr 2, 2015 at 3:27 AM, Prasun Gera prasun.g...@gmail.com wrote: I tried enabling crypt for experimentation, and things seem to work well for both NIS and SSSD clients. I noticed that the crypt format that the NIS plugin in IPA provides is the traditional crypt format with a 2 character salt and 13 character hash. NIS clients can understand newer crypt encodings which allow MD5, SHA256 and SHA512 ( https://docs.python.org/3/library/crypt.html) . Is it possible to force one of those as the storage scheme in the directory server ? On Tue, Mar 31, 2015 at 12:04 PM, Prasun Gera prasun.g...@gmail.com wrote: I've figured it out. You are right. SSSD triggers key generation. For migrated clients though, since ypbind still runs and the NIS-plugin serves maps, they authenticate first using NIS before SSSD. If ypbind is stopped, it is forced to use SSSD, and then it triggers the migration. Thanks for persisting with this. It's pretty clear how it works now. On Tue, Mar 31, 2015 at 11:32 AM, Prasun Gera prasun.g...@gmail.com wrote: ? SSSD does not seem to be involved as user is found in the /etc/passwd and this SSSD should not do anything. It's not a local user. There's no entry in /etc/passwd. Here's the relevant sssd log sssd_ssh (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 'testuser2' matched without domain, user is testuser2 (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [client_recv] (0x0200): Client disconnected! (Tue Mar 31 03:53:17 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Received client version [0]. sssd_pam (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: ipadomain (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): user: testuser2 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: host_ip (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 23983 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): logon name: testuser2 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [0][ipadomain] (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]. (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 27 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [client_recv] (0x0200): Client disconnected! -- 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
[Freeipa-users] bind-dyndb-ldap and stub zones
i am wondering if bind-dyndb-ldap supports stub zones. below would be a use case for me. say i have a network with a lot of external client connectivity (over leased line, MPLS, VPN, etc). the clients connections are used for inbound, outbound or bi-directional traffic (file transfers, web traffic, data exchange, etc). because of the size of my network, my already large and complex routing scheme for my own needs does not need to be made more complex by having to route my client's address space, so i devote specific networks out of my address space to 1-to-1 or static NAT addresses. by doing this, i can push all that traffic to the vpn endpoints or routers that manage that connectivity, without having to route foreign networks in the core. to make life easier, i want to have DNS names assigned to the NAT addresses, but the names are not in my authoritative name space, and may be internet resolvable, should a recursive search be performed. say i have mydomain.tld registered, and i have 300.555.0.0/16 assigned (yes, i know that does not exist). i would devote 300.555.254.0/23 to these 1-to-1 NATs. client Example Corp has dedicated connectivity to me and i want to access their website over that connection. the site, www.example.com, is internet resolvable but i dont want to access the internet accessible site. i want DNS resolution to point to my NAT, and take the traffic to the VPN where the NAT occurs and the traffic is pushed across to the client. with stub zones, i could create a zone, example.com, put a record for www into that zone and assign it my 1-to-1 NAT address of 300.555.254.1. i push my internal requests for that resource towards my vpn or client connection router, and perform the NAT at that device. my routing stays free of foreign networks and the traffic ends up where i want it. can bind-dyndb-ldap manage stub zones? how would one create the necessary ldap entries? sub zones require some extra work, so i would imagine stub zones do too, if they are currently supported. -- 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
Re: [Freeipa-users] freeipa-server on Raspberry Pi 2
On 02/04/15 12:53, Winfried de Heiden wrote:
Hi all,
Because I can try I gave a shot on installing freeipa-server on a
Raspberry Pi 2. I used Fedora 21 for this. Installing looks promising,
but fails somewhere halfway:
[8/27]: starting certificate server instance
[error] RuntimeError: CA did not start in 300.0s
CA did not start in 300.0s
and the install log will tell:
[root@ipa log]# tail /var/log/ipaserver-install.log
File
/usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 279, in start
self.service.start(instance_name,
capture_output=capture_output, wait=wait)
File
/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py,
line 229, in start
self.wait_until_running()
File
/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py,
line 223, in wait_until_running
raise RuntimeError('CA did not start in %ss' % timeout)
2015-04-02T09:58:36Z DEBUG The ipa-server-install command failed,
exception: RuntimeError: CA did not start in 300.0s
I 'm wondering if this is a timing issue... Of course the Pi2 tends to
be slow and no wonder starting things will takes some time... (Yep,
I 'm trying to move tons of stones using only a 2CV car...) The
catalina log (that's the CA (Tomcat) log right?)
tells it needs some more time to start:
[root@ipa pki-tomcat]# tail
/var/log/pki/pki-tomcat/catalina.2015-04-02.log
Apr 02, 2015 11:59:20 AM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deployment of configuration descriptor
/etc/pki/pki-tomcat/Catalina/localhost/ROOT.xml has finished in
84,815 ms
Apr 02, 2015 11:59:20 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [http-bio-8080]
Apr 02, 2015 11:59:20 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [http-bio-8443]
Apr 02, 2015 11:59:20 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [ajp-bio-127.0.0.1-8009]
Apr 02, 2015 11:59:20 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 355603 ms
Anyone got an idea how to set the time out for the CA to start to 10
or 15 minuten? Any other sugestion what is causing this problem? (no,
I am not upgrading from an older version, this is a fresh install)
Kind regards,
Winfried
Hello,
you can try:
https://www.redhat.com/archives/freeipa-users/2015-April/msg00076.html
--
Martin Basti
--
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
[Freeipa-users] freeipa-server on Raspberry Pi 2
Hi all,
"Because I can try" I gave a shot on installing freeipa-server on
a Raspberry Pi 2. I used Fedora 21 for this. Installing looks
promising, but fails somewhere halfway:
[8/27]: starting certificate
server instance
[error] RuntimeError: CA did not start in
300.0s
CA did not start in 300.0s
and the install log will tell:
[root@ipa log]# tail
/var/log/ipaserver-install.log
File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 279, in start
self.service.start(instance_name,
capture_output=capture_output, wait=wait)
File
"/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
line 229, in start
self.wait_until_running()
File
"/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
line 223, in wait_until_running
raise RuntimeError('CA did not start in
%ss' % timeout)
2015-04-02T09:58:36Z DEBUG The
ipa-server-install command failed, exception: RuntimeError: CA
did not start in 300.0s
I 'm wondering if this is a timing issue... Of course the Pi2
tends to be slow and no wonder starting things will takes "some
time"... (Yep, I 'm trying to move tons of stones using only a 2CV
car...) The catalina log (that's the CA (Tomcat) log right?)
tells it needs some more time to start:
[root@ipa pki-tomcat]# tail
/var/log/pki/pki-tomcat/catalina.2015-04-02.log
Apr 02, 2015 11:59:20 AM
org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deployment of configuration descriptor
/etc/pki/pki-tomcat/Catalina/localhost/ROOT.xml has finished in
84,815 ms
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["http-bio-8080"]
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["http-bio-8443"]
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["ajp-bio-127.0.0.1-8009"]
Apr 02, 2015 11:59:20 AM
org.apache.catalina.startup.Catalina start
INFO: Server startup in 355603 ms
Anyone got an idea how to set the time out for
the CA to start to 10 or 15 minuten? Any other sugestion what is
causing this problem? (no, I am not upgrading from an older
version, this is a fresh install)
Kind regards,
Winfried
--
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
[Freeipa-users] Upgrade fail 3.3.3 (rhel7) to 4.1 (rhel7.1)
Hi all! We have 6 IPA Servers here connected to each other. We want to upgrade all from RHEL 7 with IPA 3.3.3 to RHEL 7.1with IPA 4.1. I have done it one of the 6 servers and got a problem. After upgrade if I want to login to Web UI I get: IPA-Error 903: InternalError after typing the credentials... I have activated debug output of IPA and see this in /var/log/httpd/error_log: [Thu Apr 02 14:39:38.848474 2015] [:error] [pid 18020] ipa: ERROR: non-public: KeyError: 'idnsforwardzone' [Thu Apr 02 14:39:38.848536 2015] [:error] [pid 18020] Traceback (most recent call last): [Thu Apr 02 14:39:38.848600 2015] [:error] [pid 18020] File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 348, in wsgi_execute [Thu Apr 02 14:39:38.848607 2015] [:error] [pid 18020] result = self.Command[name](*args, **options) [Thu Apr 02 14:39:38.848612 2015] [:error] [pid 18020] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439, in __call__ [Thu Apr 02 14:39:38.848671 2015] [:error] [pid 18020] ret = self.run(*args, **options) [Thu Apr 02 14:39:38.848701 2015] [:error] [pid 18020] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 754, in run [Thu Apr 02 14:39:38.848707 2015] [:error] [pid 18020] return self.execute(*args, **options) [Thu Apr 02 14:39:38.848776 2015] [:error] [pid 18020] File /usr/lib/python2.7/site-packages/ipalib/plugins/internal.py, line 123, in execute [Thu Apr 02 14:39:38.848783 2015] [:error] [pid 18020] (o.name, json_serialize(o)) for o in self.api.Object() [Thu Apr 02 14:39:38.848789 2015] [:error] [pid 18020] File /usr/lib/python2.7/site-packages/ipalib/plugins/internal.py, line 123, in genexpr [Thu Apr 02 14:39:38.848794 2015] [:error] [pid 18020] (o.name, json_serialize(o)) for o in self.api.Object() [Thu Apr 02 14:39:38.848799 2015] [:error] [pid 18020] File /usr/lib/python2.7/site-packages/ipalib/util.py, line 60, in json_serialize [Thu Apr 02 14:39:38.848804 2015] [:error] [pid 18020] return json_serialize(obj.__json__()) [Thu Apr 02 14:39:38.848809 2015] [:error] [pid 18020] File /usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py, line 710, in __json__ [Thu Apr 02 14:39:38.848814 2015] [:error] [pid 18020] attrs = self.api.Backend.ldap2.schema.attribute_types(objectclasses) [Thu Apr 02 14:39:38.848820 2015] [:error] [pid 18020] File /usr/lib64/python2.7/site-packages/ldap/schema/subentry.py, line 377, in attribute_types [Thu Apr 02 14:39:38.848825 2015] [:error] [pid 18020] object_class = self.sed[ObjectClass][object_class_oid] [Thu Apr 02 14:39:38.848830 2015] [:error] [pid 18020] KeyError: 'idnsforwardzone' I have found this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1180325 It should be fixed in the last version?! I have read there I should start: setup-ds.pl -d --update But Im afraid that it kills the date on the IPA Servers with version 3.3.3... does it? What can I do? how can I fix it? Greetz Christoph Kaminski -- 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
Re: [Freeipa-users] RHEL 5 client?
On Thu, Apr 02, 2015 at 02:43:59PM +, Guertin, David S. wrote: Ah so you are using it with trust. Then you should change the configuration to not use kerberos but rather LDAP instead. More details are here. http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf Thanks. When I ran ipa-adtrust-install on the servers, I hadn't used the --enable-compat flag, so I re-ran ipa-adtrust-install --enable-compat on all three IPA servers. I then cleared the sssd cache on the RHEL 5 client and restarted sssd, but users still couldn't log in. Originally I had run ipa-advise config-redhat-sssd-before-1-9 on the server, so I tried re-running that with ipa-advise config-redhat-nss-ldap instead, and ran the resulting script on the client. Still no success -- I'm still getting the same error. The current sssd.conf file on the client is: [sssd] services = nss, pam config_file_version = 2 domains = default re_expression = (?Pname.+) [domain/default] cache_credentials = True id_provider = ldap auth_provider = ldap ldap_uri = ldap://genet.ipa.middlebury.edu ldap_search_base = cn=compat,dc=ipa,dc=middlebury,dc=edu ldap_tls_cacert = /etc/openldap/cacerts/ipa.crt David Guertin Can you try searching the compat tree with ldapsearch to see if an entry turns up? IIRC you need to search for a particular entry, not for any (not ie cn=*), but if you crank up the debug_level in the domain section, then sssd should log the searches to /var/log/sssd/sssd_default.log -- 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
Re: [Freeipa-users] pks error??
On 02/04/15 15:30, Janelle wrote: Hello, Just wondering how you get rid of this - just kind of annoying: p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute I understand it is related to not setting up DNS, is this correct? Thank you ~J Hello, where is the origin of this message? Which log? Can you send the log? Martin -- Martin Basti -- 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
Re: [Freeipa-users] RES: FreeIPA integration with AIX and sudo
On 04/01/2015 01:58 PM, Luiz Fernando Vianna da Silva wrote: Hi Yves. First a little background information regarding sudo on AIX: Most sudo packages compiled for AIX are _/NOT/_ compiled with LDAP support. Although sudo's documentation states that sudo supports different LDAP implementations, other than OpenLDAP, I suppose it doesn't work well with AIX's LDAP fileset. That's my guess why most sudo packages for AIX aren't compiled with LDAP support. [BTW, you can check this by running, as root, sudo -V| grep -i ldap]. The good news is that Michel Perzl, has successfully compiled a sudo package with LDAP support, although its compiled against OpenLDAP and not AIX's LDAP fileset. So, here is how I did it: (1) Go to http://www.perzl.org/aix/ http://www.perzl.org/aix/ and download the following RPM packages on their latest versions: ·sudo = 1.8.11 ·gettext = 0.10.40 ·openldap = 2.4.23 ·openssl = 1.0.1j-1 ·zlib Make sure you don't have the sudo fileset installed or another sudo rpm package. Don't worry about openssl from this RPM package conflicting with the OpenSSL fileset from AIX, they won't. Don't worry about openldap from this RPM package conflicting with the ldap fileset from AIX, they won't. (2) Upload the rpm packages to you AIX LPAR and put them all in a directory, I used /tmp/sudopack. [From here on I assume you are root on your LPAR]. (3) From the directory where you put your packages run a rpm -ivh *.rpm --test and if all goes well proceed without the --test, otherwise sort out the dependencies and conflicts like the grown man you are :). (4) Once the rpms are installed, add the following line to the bottom of your /etc/netsvc.conf file: sudoers = files, ldap I know this is not expected syntax according to IBM's netsvc.conf documentation, but sudo requires it to work with ldap. According to sudo's documentation it uses that line on netsvc.conf to emulate what sudo would expect to find on /etc/nsswitch.conf on a Linux machine [hack much?]. (5) Create a file called /etc/ldap.conf . This has nothing to do with the /etc/security/ldap/ldap.cfg file you use to configure AIX's LDAP, this is OpenLdap's config only used by sudo. Don't worry, this won't conflict with AIX's LDAP functionality. Add this to your /etc/ldap.conf: tls_cacert /etc/ipa/ca.crt uri ldap://youripaserver.domain.com binddn uid=sudo,cn=sysaccounts,cn=etc,dc=domain,dc=com bindpw yourclientpassword sudoers_base ou=sudoers,dc=domain,dc=com (6) Create a directory called /etc/ipa and download your ca certificate file and place it there. Make sure to permission the directory 755 and the ca.crt file 644. (7) And that's pretty much it, no need to edit a single line on /etc/sudoers. The /etc/sudoers file I have on my LPARs is the one that comes with the rpm, unchanged. Log into your LPAR with a domain user and try running sudo -l, it should output the sudo rules you set on the IPA server. I hope this helps you and other AIX client users out there. Would you mind creating a howto page on the IPA wiki? Atenciosamente/Best Regards *__* *Luiz Fernando Vianna da Silva* ITM-I - Operação Cielo +55 (11) 3626-7126 luiz.via...@tivit.com.br mailto:luiz.via...@tivit.com.br *T I V I T ** *Av. Maria Coelho Aguiar, 215 - Bloco D - 5? Andar São Paulo - SP - CEP 05804-900 www.tivit.com.br http://www.tivit.com.br/ Esta mensagem, incluindo seus anexos, tem caráter confidencial e seu conteúdo é restrito ao destinatário da mensagem. Caso você a tenha recebido por engano, queira, por favor, retorná-la ao destinatário e apagá-la de seus arquivos. Qualquer uso não autorizado, replicação ou disseminação desta mensagem ou parte dela é expressamente proibido. A TIVIT não se responsabilizará pelo conteúdo ou pela veracidade desta informação. *De:*Yves Degauquier [mailto:y...@degauquier.net] *Enviada em:* quarta-feira, 1 de abril de 2015 14:03 *Para:* Luiz Fernando Vianna da Silva *Assunto:* Re: [Freeipa-users] FreeIPA integration with AIX and sudo Hi Luiz, I was not able to make it running, I was a bit lost with the LDAP, PAM, LAM configuration, and didn't found any idea with Google... If you can share the solution or point me to some important point to do, I will be happy. Thanks in advance, Best regards, Yves On 01/04/15 18:57, Luiz Fernando Vianna da Silva wrote: Hello Yves. I was browsing the mailing list archives and found your email from December 2013 (https://www.redhat.com/archives/freeipa-users/2013-December/msg00083.html). I have successfully found a way to have sudo on AIX work with the sudo rules on IPA, just like Linux clients. Give me a reply if you haven't figured out a way to make this work and I'll send you the solution I came up with. Atenciosamente/Best Regards *__* *Luiz Fernando Vianna da Silva* ITM-I - Operação
Re: [Freeipa-users] Expired password change on AIX Client
On 04/01/2015 02:28 PM, Luiz Fernando Vianna da Silva wrote:
Hello Dmitri.
Server is running: ipa-server-3.0.0-37.el6.x86_64
My kerberos configuration looks like this on a client:
# cat /etc/krb5.conf
[libdefaults]
default_realm = DOMAIN.COM
default_keytab_name = FILE:/etc/krb5/krb5.keytab
default_tkt_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts
des-cbc-md5 des-cbc-crc aes128-cts
default_tgs_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts
des-cbc-md5 des-cbc-crc aes128-cts
[realms]
DOMAIN.COM = {
kdc = ldap.domain.com:88
admin_server = ldap.domain.com:749
default_domain = domain.com
}
[domain_realm]
.domain.com = DOMAIN.COM
ldap.domain.com = DOMAIN.COM
[logging]
kdc = FILE:/var/krb5/log/krb5kdc.log
admin_server = FILE:/var/krb5/log/kadmin.log
kadmin_local = FILE:/var/krb5/log/kadmin_local.log
default = FILE:/var/krb5/log/krb5lib.log
#
What does the KDC log show?: Where do I get this log from?
/var/log/krb5kdc.log
Atenciosamente/Best Regards
*__*
*Luiz Fernando Vianna da Silva*
ITM-I - Operação Cielo
+55 (11) 3626-7126
luiz.via...@tivit.com.br mailto:luiz.via...@tivit.com.br
*T I V I T
**
*Av. Maria Coelho Aguiar, 215 - Bloco D - 5˚ Andar
São Paulo - SP - CEP 05804-900
www.tivit.com.br http://www.tivit.com.br/
Esta mensagem, incluindo seus anexos, tem caráter confidencial e seu
conteúdo é restrito ao destinatário da mensagem. Caso você a tenha
recebido por engano, queira, por favor, retorná-la ao destinatário e
apagá-la de seus arquivos. Qualquer uso não autorizado, replicação ou
disseminação desta mensagem ou parte dela é expressamente proibido. A
TIVIT não se responsabilizará pelo conteúdo ou pela veracidade desta
informação.
*De:*freeipa-users-boun...@redhat.com
mailto:freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] *Em nome de *Dmitri Pal
*Enviada em:* quarta-feira, 1 de abril de 2015 13:27
*Para:* freeipa-users@redhat.com mailto:freeipa-users@redhat.com
*Assunto:* [Marketing Mail] Re: [Freeipa-users] Expired password
change on AIX Client
On 04/01/2015 11:14 AM, Luiz Fernando Vianna da Silva wrote:
Hello All.
I’ve searched the archives of this mailing list looking for an
answer for this one, but all I found lead me nowhere. L
Closest thread to help me was:
https://www.redhat.com/archives/freeipa-users/2014-March/msg00153.html
Has anyone figured out a way to have expired password changes work
on AIX clients?
I have tried adding “kpasswd_protocol = SET_CHANGE” as well as
“kpasswd_protocol = RPCSEC_GSS” to the [realms] section but none
of them worked.
Here is the output from an ssh test session for user “teste” on a
AIX 7.1 machine:
-bash-4.2$ ssh teste@localhost
# NICE MOTD
teste@localhost's password:
[KRB5]: 3004-332 Your password has expired.
3004-333 A password change is required.
[KRB5]: 3004-332 Your password has expired.
***
* *
* *
* Welcome to AIX Version
7.1!*
* *
* *
* Please see the README file in /usr/lpp/bos for information
pertinent to*
* this release of the AIX Operating System.
*
* *
* *
***
# NICE MOTD
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for teste
teste's Old password:
teste's New password:
Enter the new password again:
3004-604 Your entry does not match the old password.
Connection to localhost closed.
-bash-4.2$
So you are setting up AIX client using kerberos against IPA server and
trying to log with a user that has expired password. Did I get it right?
What version of the server you are using?
How your kerberos configuration looks on a client?
What does the KDC log show?
Atenciosamente/Best Regards
*__*
*L**uiz Fernando Vianna da Silva*
ITM-I - Operação Cielo
+55 (11) 3626-7126
luiz.via...@tivit.com.br mailto:luiz.via...@tivit.com.br
*T I V I T
**
*Av. Maria Coelho Aguiar, 215 - Bloco D - 5˚ Andar
São Paulo - SP - CEP 05804-900
www.tivit.com.br http://www.tivit.com.br/
Esta mensagem, incluindo seus anexos, tem caráter confidencial e seu
conteúdo é
[Freeipa-users] pks error??
Hello, Just wondering how you get rid of this - just kind of annoying: p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute I understand it is related to not setting up DNS, is this correct? Thank you ~J -- 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
[Freeipa-users] Antwort: Re: Upgrade fail 3.3.3 (rhel7) to 4.1 (rhel7.1)
see this in ipupgrade.log 2015-04-02T11:27:02Z ERROR Pre schema upgrade failed with [Errno 111] Connection refused 2015-04-02T11:27:02Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py, line 128, in __pre_schema_upgrade ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 220, in __init__ self.create_connection() File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 783, in create_connection dm_password=self.dm_password, pw_name=self.pw_name) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 65, in connect conn.do_external_bind(pw_name) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 1173, in wait_for_open_socket raise e error: [Errno 111] Connection refused 2015-04-02T11:27:02Z DEBUG duration: 12 seconds 2015-04-02T11:27:02Z DEBUG [6/10]: updating schema 2015-04-02T11:27:12Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py, line 145, in __update_schema dm_password='', ldapi=True, live_run=self.live_run) or self.modified File /usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py, line 112, in update_schema fqdn=installutils.get_fqdn()) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 65, in connect conn.do_external_bind(pw_name) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 1173, in wait_for_open_socket raise e error: [Errno 111] Connection refused 2015-04-02T11:27:12Z DEBUG [error] error: [Errno 111] Connection refused 2015-04-02T11:27:12Z DEBUG [cleanup]: stopping directory server ... 2015-04-02T12:46:11Z DEBUG stderr= 2015-04-02T12:46:12Z DEBUG File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in execute return_value = self.run() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py, line 213, in run modified = ld.update(self.files, ordered=True) or modified File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 874, in update updates = api.Backend.updateclient.update(POST_UPDATE, self.dm_password, self.ldapi, self.live_run) File /usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py, line 123, in update (restart, apply_now, res) = self.run(update.name, **kw) File /usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py, line 146, in run return self.Updater[method](**kw) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 1399, in __call__ return self.execute(**options) File /usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py, line 76, in execute ldap.add_entry(entry) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1191, in error_handler raise errors.ObjectclassViolation(info=info) 2015-04-02T12:46:12Z DEBUG The ipa-ldap-updater command failed, exception: ObjectclassViolation: unknown object class ipaKeyPolicy 2015-04-02T12:46:12Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: ObjectclassViolation: unknown object class ipaKeyPolicy and: grep -i nsSchemaPolicy /etc/dirsrv/slapd-HSO/schema/01core389.ldif objectClasses: ( 2.16.840.1.113730.3.2.328 NAME 'nsSchemaPolicy' DESC 'Netscape defined objectclass' SUP top MAY ( cn $ schemaUpdateObjectclassAccept $ schemaUpdateObjectclassReject $
[Freeipa-users] RES: RES: FreeIPA integration with AIX and sudo
Hi Dmitri. Working on it right now. :) Atenciosamente/Best Regards __ Luiz Fernando Vianna da Silva ITM-I - Operação Cielo +55 (11) 3626-7126 luiz.via...@tivit.com.brmailto:luiz.via...@tivit.com.br T I V I T Av. Maria Coelho Aguiar, 215 - Bloco D - 5˚ Andar São Paulo - SP - CEP 05804-900 www.tivit.com.brhttp://www.tivit.com.br/ Esta mensagem, incluindo seus anexos, tem caráter confidencial e seu conteúdo é restrito ao destinatário da mensagem. Caso você a tenha recebido por engano, queira, por favor, retorná-la ao destinatário e apagá-la de seus arquivos. Qualquer uso não autorizado, replicação ou disseminação desta mensagem ou parte dela é expressamente proibido. A TIVIT não se responsabilizará pelo conteúdo ou pela veracidade desta informação. De: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] Em nome de Dmitri Pal Enviada em: quinta-feira, 2 de abril de 2015 10:23 Para: freeipa-users@redhat.com Assunto: Re: [Freeipa-users] RES: FreeIPA integration with AIX and sudo On 04/01/2015 01:58 PM, Luiz Fernando Vianna da Silva wrote: Hi Yves. First a little background information regarding sudo on AIX: Most sudo packages compiled for AIX are _NOT_ compiled with LDAP support. Although sudo’s documentation states that sudo supports different LDAP implementations, other than OpenLDAP, I suppose it doesn’t work well with AIX’s LDAP fileset. That’s my guess why most sudo packages for AIX aren’t compiled with LDAP support. [BTW, you can check this by running, as root, sudo -V | grep -i ldap]. The good news is that Michel Perzl, has successfully compiled a sudo package with LDAP support, although its compiled against OpenLDAP and not AIX’s LDAP fileset. So, here is how I did it: (1) Go to http://www.perzl.org/aix/ and download the following RPM packages on their latest versions: #61623 sudo = 1.8.11 #61623 gettext = 0.10.40 #61623 openldap = 2.4.23 #61623 openssl = 1.0.1j-1 #61623 zlib Make sure you don’t have the sudo fileset installed or another sudo rpm package. Don’t worry about openssl from this RPM package conflicting with the OpenSSL fileset from AIX, they won’t. Don’t worry about openldap from this RPM package conflicting with the ldap fileset from AIX, they won’t. (2) Upload the rpm packages to you AIX LPAR and put them all in a directory, I used /tmp/sudopack. [From here on I assume you are root on your LPAR]. (3) From the directory where you put your packages run a “rpm -ivh *.rpm --test” and if all goes well proceed without the “--test”, otherwise sort out the dependencies and conflicts like the grown man you are :). (4) Once the rpms are installed, add the following line to the bottom of your /etc/netsvc.conf file: sudoers = files, ldap I know this is not expected syntax according to IBM’s netsvc.conf documentation, but sudo requires it to work with ldap. According to sudo’s documentation it uses that line on netsvc.conf to emulate what sudo would expect to find on /etc/nsswitch.conf on a Linux machine [hack much?]. (5) Create a file called /etc/ldap.conf . This has nothing to do with the /etc/security/ldap/ldap.cfg file you use to configure AIX’s LDAP, this is OpenLdap’s config only used by sudo. Don’t worry, this won’t conflict with AIX’s LDAP functionality. Add this to your /etc/ldap.conf: tls_cacert /etc/ipa/ca.crt uri ldap://youripaserver.domain.com binddn uid=sudo,cn=sysaccounts,cn=etc,dc=domain,dc=com bindpw yourclientpassword sudoers_base ou=sudoers,dc=domain,dc=com (6) Create a directory called /etc/ipa and download your ca certificate file and place it there. Make sure to permission the directory 755 and the ca.crt file 644. (7) And that’s pretty much it, no need to edit a single line on /etc/sudoers. The /etc/sudoers file I have on my LPARs is the one that comes with the rpm, unchanged. Log into your LPAR with a domain user and try running “sudo -l”, it should output the sudo rules you set on the IPA server. I hope this helps you and other AIX client users out there. Would you mind creating a howto page on the IPA wiki? Atenciosamente/Best Regards __ Luiz Fernando Vianna da Silva ITM-I - Operação Cielo +55 (11) 3626-7126 luiz.via...@tivit.com.brmailto:luiz.via...@tivit.com.br T I V I T Av. Maria Coelho Aguiar, 215 - Bloco D - 5˚ Andar São Paulo - SP - CEP 05804-900 www.tivit.com.brhttp://www.tivit.com.br/ Esta mensagem, incluindo seus anexos, tem caráter confidencial e seu conteúdo é restrito ao destinatário da mensagem. Caso você a tenha recebido por engano, queira, por favor, retorná-la ao destinatário e apagá-la de seus arquivos. Qualquer uso não autorizado, replicação ou disseminação desta mensagem ou parte dela é expressamente proibido. A TIVIT não se responsabilizará pelo conteúdo ou pela veracidade desta informação. De: Yves Degauquier [mailto:y...@degauquier.net] Enviada em: quarta-feira, 1
