Re: [Freeipa-users] Upgrade form Centos to Fedora (3.0.0 - 3.3.3)
Will Sheldon wrote: Hello IPA users :) We have implemented IPA using the packaged version in centos 6.5 (which is 3.0.0-37.el6), but have been playing with the more recent version in Fedora 19 (3.3.3-2.fc19) and are quite keen to take advantage of the shiny new features, so are thinking about migrating. Has anyone done this? Is there an easy way to migrate/upgrade? What would happen if I tried to setup a FC19 replica, would it get angry and break? We only have users in production so far, (no production clients or issued certs) so maybe the user migration script mentioned in previous posts would be the best bet? Any pointers would be hugely appreciated.. This is exactly the way to migrate between versions. You'll want to set up a CA on the F19 server for sure, and DNS if you're using that. The idea is that you set up the new master, spend some time (days, weeks not months) verifying that things are working ok, then remove the old server and things should continue to just work. We also recommend having at least two masters with CAs for redundancy and avoiding a single point of failure. We have discovered a bug in the way clients are enrolled though. We store the name of the master you enroll against. Normally this isn't a big deal, especially if you use SRV records. The problem is if that some tools use the master from this file to connect to and not SRV records, so you may want to run around to your clients and change this in /etc/ipa/default.conf once the migration is complete. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-server-install fails (RHEL 6.5)
Steve Dainard wrote: Following this guide: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html STEP 4: ipa-server-install --setup-dns -p 'password' -a 'password' -r MIOVISION.LINUX -n miovision.linux --hostname ipa1.miovision.linux --forwarder=10.0.0.2 --forwarder=10.0.0.5 Server host name [ipa1.miovision.linux]: Warning: skipping DNS resolution of host ipa1.miovision.linux Unable to resolve IP address for host name Please provide the IP address to be used for this host name: 10.0.6.3 Adding [10.0.6.3 ipa1.miovision.linux] to your /etc/hosts file Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [6.0.10.in-addr.arpa.]: Using reverse zone 6.0.10.in-addr.arpa. The IPA Master Server will be configured with: Hostname: ipa1.miovision.linux IP address:10.0.6.3 Domain name: miovision.linux Realm name:MIOVISION.LINUX BIND DNS server will be configured to serve IPA domain with: Forwarders:10.0.0.2, 10.0.0.5 Reverse zone: 6.0.10.in-addr.arpa. Continue to configure the system with these values? [no]: yes The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd ... Done configuring directory server (dirsrv). Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds [1/10]: adding sasl mappings to the directory [2/10]: adding kerberos container to the directory [3/10]: configuring KDC [4/10]: initialize kerberos container Failed to initialize the realm container [5/10]: adding default ACIs [6/10]: creating a keytab for the directory Unexpected error - see /var/log/ipaserver-install.log for details: CalledProcessError: Command 'kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux@MIOVISION.LINUX -x ipa-setup-override-restrictions' returned non-zero exit status 1 */var/log/ipaserver-install.log* add aci: (target=ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,dc=miovision,dc=linux;)(targetattr=userCertificate)(version 3.0; acl Modify CA Certificates for renewals; allow(write) userdn = ldap:///fqdn=ipa1.miovision.linux,cn=computers,cn=accounts,dc=miovision,dc=linux;;) modifying entry cn=ipa,cn=etc,dc=miovision,dc=linux modify complete 2014-02-04T20:45:51Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-MIOVISION-LINUX.socket/??base ) 2014-02-04T20:45:51Z DEBUG duration: 6 seconds 2014-02-04T20:45:51Z DEBUG [6/10]: creating a keytab for the directory 2014-02-04T20:45:51Z DEBUG args=kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux@MIOVISION.LINUX -x ipa-setup-override-restrictions 2014-02-04T20:45:51Z DEBUG stdout=Authenticating as principal root/admin@MIOVISION.LINUX with password. 2014-02-04T20:45:51Z DEBUG stderr=kadmin.local: No such entry in the database while initializing kadmin.local interface 2014-02-04T20:45:51Z INFO File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 614, in run_script return_value = main_function() File /usr/sbin/ipa-server-install, line 1024, in main subject_base=options.subject) File /usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py, line 183, in create_instance self.start_creation(runtime=30) File /usr/lib/python2.6/site-packages/ipaserver/install/service.py, line 358, in start_creation method() File /usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py, line 386, in __create_ds_keytab installutils.kadmin_addprinc(ldap_principal) File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 369, in kadmin_addprinc kadmin(addprinc -randkey + principal) File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 366, in kadmin -x, ipa-setup-override-restrictions]) File /usr/lib/python2.6/site-packages/ipapython/ipautil.py, line 316, in run raise CalledProcessError(p.returncode, args) 2014-02-04T20:45:51Z INFO The ipa-server-install command failed, exception: CalledProcessError: Command 'kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux@MIOVISION.LINUX -x ipa-setup-override-restrictions' returned non-zero exit status 1 Hmm, strange. Nothing is jumping out at me for the cause or solution. What version of IPA is this? rpm -q ipa-server Any chance you can send the entire server install log? You can send it to me privately if you'd like. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CentOS IPA Client using Fedora IPA Server - SSO Fails from AD Trust domain
Thanks, That was what I missed. On Wed, Feb 5, 2014 at 2:39 AM, Alexander Bokovoy aboko...@redhat.comwrote: On Tue, 04 Feb 2014, Mark Gardner wrote: I'm trying to configure our CentOS IPA Client for Single Sign On from our trusted AD domain. SSO works fine when I ssh to the IPA server, but not to the CentOS Client. It prompts for password which it accepts, so it's getting the authentication from the AD domain. Fedora 20 IPA Server CentOS 6.5 IPA Client Win 2012 AD Domain Server Setup as IPA as a subdomain of AD. AD Domain: test.local IPA Domain: hosted.test.local Anybody run into this? Suggestions? Each client needs to be configured to accept AD users' SSO. Check that /etc/krb5.conf contains auth_to_local rules mapping principals from AD to their names as returned by SSSD. SSH daemon is picky about principal/name mapping. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Can't delete users
We've discovered something odd in our current FreeIPA setup (F18, IPA 3.1.5-1.fc18.x86_64). Whenever we go to delete a user, the whole IPA infrastructure will hang. The web page becomes nonresponsive and the server doesn't respond to sudo or authentication requests. DNS requests go unanswered. The only solution we've found thus far is to "ipactl stop ipactl start". Nothing ever shows up in any logfile we've looked at, presumably because whatever ought to be logging an error is hung. The "stop" portion can take up to 10 minutes to complete. What can I be looking at to diagnose and/or debug this? We ought to be able to delete users, not just disable them, right? -- Bret Wortman http://damascusgrp.com/ http://about.me/wortmanbret smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CentOS IPA Client using Fedora IPA Server - SSO Fails from AD Trust domain
Good! Note that we plan to enhance SSSD to leverage the new Kerberos authlocal API to avoid having to update krb5.conf on each system. This is the upstream ticket: https://fedorahosted.org/sssd/ticket/1835 Martin On 02/05/2014 03:27 PM, Mark Gardner wrote: Thanks, That was what I missed. On Wed, Feb 5, 2014 at 2:39 AM, Alexander Bokovoy aboko...@redhat.comwrote: On Tue, 04 Feb 2014, Mark Gardner wrote: I'm trying to configure our CentOS IPA Client for Single Sign On from our trusted AD domain. SSO works fine when I ssh to the IPA server, but not to the CentOS Client. It prompts for password which it accepts, so it's getting the authentication from the AD domain. Fedora 20 IPA Server CentOS 6.5 IPA Client Win 2012 AD Domain Server Setup as IPA as a subdomain of AD. AD Domain: test.local IPA Domain: hosted.test.local Anybody run into this? Suggestions? Each client needs to be configured to accept AD users' SSO. Check that /etc/krb5.conf contains auth_to_local rules mapping principals from AD to their names as returned by SSSD. SSH daemon is picky about principal/name mapping. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Can't delete users
On 02/05/2014 04:24 PM, Bret Wortman wrote: We've discovered something odd in our current FreeIPA setup (F18, IPA 3.1.5-1.fc18.x86_64). Whenever we go to delete a user, the whole IPA infrastructure will hang. The web page becomes nonresponsive and the server doesn't respond to sudo or authentication requests. DNS requests go unanswered. The only solution we've found thus far is to ipactl stop ipactl start. Nothing ever shows up in any logfile we've looked at, presumably because whatever ought to be logging an error is hung. The stop portion can take up to 10 minutes to complete. What can I be looking at to diagnose and/or debug this? We ought to be able to delete users, not just disable them, right? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret This sounds to me as a hang of the 389 Directory Server. Adding Nathan and Rich to CC. They will certainly want to see a stack of the stuck 389 processes: http://directory.fedoraproject.org/wiki/FAQ#Debugging_Hangs Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Can't delete users
Fortunately, I can trigger it at will. ;-) I'll get the packages loaded set up and see what I can find. On 02/05/2014 10:36 AM, Martin Kosek wrote: On 02/05/2014 04:24 PM, Bret Wortman wrote: We've discovered something odd in our current FreeIPA setup (F18, IPA 3.1.5-1.fc18.x86_64). Whenever we go to delete a user, the whole IPA infrastructure will hang. The web page becomes nonresponsive and the server doesn't respond to sudo or authentication requests. DNS requests go unanswered. The only solution we've found thus far is to ipactl stop ipactl start. Nothing ever shows up in any logfile we've looked at, presumably because whatever ought to be logging an error is hung. The stop portion can take up to 10 minutes to complete. What can I be looking at to diagnose and/or debug this? We ought to be able to delete users, not just disable them, right? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret This sounds to me as a hang of the 389 Directory Server. Adding Nathan and Rich to CC. They will certainly want to see a stack of the stuck 389 processes: http://directory.fedoraproject.org/wiki/FAQ#Debugging_Hangs Martin smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CentOS IPA Client using Fedora IPA Server - SSO Fails from AD Trust domain
Any one knows how to add new attribute or object class to the user accounts ...eg. added department and id creation date in those users info field. Can use 389 / redhat driectory console ? I tried to edit 99user.ldif seem not shown up new attribute. barry 2014-02-05 Martin Kosek mko...@redhat.com: Good! Note that we plan to enhance SSSD to leverage the new Kerberos authlocal API to avoid having to update krb5.conf on each system. This is the upstream ticket: https://fedorahosted.org/sssd/ticket/1835 Martin On 02/05/2014 03:27 PM, Mark Gardner wrote: Thanks, That was what I missed. On Wed, Feb 5, 2014 at 2:39 AM, Alexander Bokovoy aboko...@redhat.com wrote: On Tue, 04 Feb 2014, Mark Gardner wrote: I'm trying to configure our CentOS IPA Client for Single Sign On from our trusted AD domain. SSO works fine when I ssh to the IPA server, but not to the CentOS Client. It prompts for password which it accepts, so it's getting the authentication from the AD domain. Fedora 20 IPA Server CentOS 6.5 IPA Client Win 2012 AD Domain Server Setup as IPA as a subdomain of AD. AD Domain: test.local IPA Domain: hosted.test.local Anybody run into this? Suggestions? Each client needs to be configured to accept AD users' SSO. Check that /etc/krb5.conf contains auth_to_local rules mapping principals from AD to their names as returned by SSSD. SSH daemon is picky about principal/name mapping. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-server-install fails (RHEL 6.5)
Steve Dainard wrote: Following this guide: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html STEP 4: ipa-server-install --setup-dns -p 'password' -a 'password' -r MIOVISION.LINUX -n miovision.linux --hostname ipa1.miovision.linux --forwarder=10.0.0.2 --forwarder=10.0.0.5 Server host name [ipa1.miovision.linux]: Warning: skipping DNS resolution of host ipa1.miovision.linux Unable to resolve IP address for host name Please provide the IP address to be used for this host name: 10.0.6.3 Adding [10.0.6.3 ipa1.miovision.linux] to your /etc/hosts file Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [6.0.10.in-addr.arpa.]: Using reverse zone 6.0.10.in-addr.arpa. The IPA Master Server will be configured with: Hostname: ipa1.miovision.linux IP address:10.0.6.3 Domain name: miovision.linux Realm name:MIOVISION.LINUX BIND DNS server will be configured to serve IPA domain with: Forwarders:10.0.0.2, 10.0.0.5 Reverse zone: 6.0.10.in-addr.arpa. Continue to configure the system with these values? [no]: yes The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd ... Done configuring directory server (dirsrv). Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds [1/10]: adding sasl mappings to the directory [2/10]: adding kerberos container to the directory [3/10]: configuring KDC [4/10]: initialize kerberos container Failed to initialize the realm container [5/10]: adding default ACIs [6/10]: creating a keytab for the directory Unexpected error - see /var/log/ipaserver-install.log for details: CalledProcessError: Command 'kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux@MIOVISION.LINUX -x ipa-setup-override-restrictions' returned non-zero exit status 1 */var/log/ipaserver-install.log* add aci: (target=ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,dc=miovision,dc=linux;)(targetattr=userCertificate)(version 3.0; acl Modify CA Certificates for renewals; allow(write) userdn = ldap:///fqdn=ipa1.miovision.linux,cn=computers,cn=accounts,dc=miovision,dc=linux;;) modifying entry cn=ipa,cn=etc,dc=miovision,dc=linux modify complete 2014-02-04T20:45:51Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-MIOVISION-LINUX.socket/??base ) 2014-02-04T20:45:51Z DEBUG duration: 6 seconds 2014-02-04T20:45:51Z DEBUG [6/10]: creating a keytab for the directory 2014-02-04T20:45:51Z DEBUG args=kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux@MIOVISION.LINUX -x ipa-setup-override-restrictions 2014-02-04T20:45:51Z DEBUG stdout=Authenticating as principal root/admin@MIOVISION.LINUX with password. 2014-02-04T20:45:51Z DEBUG stderr=kadmin.local: No such entry in the database while initializing kadmin.local interface 2014-02-04T20:45:51Z INFO File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 614, in run_script return_value = main_function() File /usr/sbin/ipa-server-install, line 1024, in main subject_base=options.subject) File /usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py, line 183, in create_instance self.start_creation(runtime=30) File /usr/lib/python2.6/site-packages/ipaserver/install/service.py, line 358, in start_creation method() File /usr/lib/python2.6/site-packages/ipaserver/install/krbinstance.py, line 386, in __create_ds_keytab installutils.kadmin_addprinc(ldap_principal) File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 369, in kadmin_addprinc kadmin(addprinc -randkey + principal) File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 366, in kadmin -x, ipa-setup-override-restrictions]) File /usr/lib/python2.6/site-packages/ipapython/ipautil.py, line 316, in run raise CalledProcessError(p.returncode, args) 2014-02-04T20:45:51Z INFO The ipa-server-install command failed, exception: CalledProcessError: Command 'kadmin.local -q addprinc -randkey ldap/ipa1.miovision.linux@MIOVISION.LINUX -x ipa-setup-override-restrictions' returned non-zero exit status 1 Steve sent me the logs out-of-band. I think the problem is an earlier failure after generating the master key: 2014-02-04T20:45:45Z DEBUG args=kdb5_util create -s -r MIOVISION.LINUX -x ipa-setup-override-restrictions 2014-02-04T20:45:45Z DEBUG stdout=Loading random data Initializing database '/var/kerberos/krb5kdc/principal' for realm 'MIOVISION.LINUX', master key name 'K/M@MIOVISION.LINUX' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: Re-enter KDC database master key to verify: 2014-02-04T20:45:45Z DEBUG stderr=kdb5_util: add.c:124: ldap_add_ext: Assertion `ld != ((void *)0)' failed. What version of
Re: [Freeipa-users] ipa-server-install fails (RHEL 6.5)
rpm -qa | grep krb5 pam_krb5-2.3.11-9.el6.x86_64 *krb5-server-1.10.3-10.el6_4.6.x86_64* krb5-libs-1.10.3-10.el6_4.6.x86_64 krb5-workstation-1.10.3-10.el6_4.6.x86_64 I don't see any segfaults in messages. /var/log/dirsrv/slapd-MIOVISION-LINUX/errors looks pretty clean: 389-Directory/1.2.11.15 B2013.337.1530 ipa1.miovision.linux:389 (/etc/dirsrv/slapd-MIOVISION-LINUX) [04/Feb/2014:15:39:54 -0500] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [04/Feb/2014:15:39:54 -0500] - check_and_set_import_cache: pagesize: 4096, pages: 1497738, procpages: 51916 [04/Feb/2014:15:39:54 -0500] - Import allocates 2396380KB import cache. [04/Feb/2014:15:39:55 -0500] - import userRoot: Beginning import job... [04/Feb/2014:15:39:55 -0500] - import userRoot: Index buffering enabled with bucket size 100 [04/Feb/2014:15:39:56 -0500] - import userRoot: Processing file /var/lib/dirsrv/boot.ldif [04/Feb/2014:15:39:56 -0500] - import userRoot: Finished scanning file /var/lib/dirsrv/boot.ldif (1 entries) [04/Feb/2014:15:40:03 -0500] - import userRoot: Workers finished; cleaning up... [04/Feb/2014:15:40:04 -0500] - import userRoot: Workers cleaned up. [04/Feb/2014:15:40:05 -0500] - import userRoot: Cleaning up producer thread... [04/Feb/2014:15:40:05 -0500] - import userRoot: Indexing complete. Post-processing... [04/Feb/2014:15:40:06 -0500] - import userRoot: Generating numSubordinates complete. [04/Feb/2014:15:40:07 -0500] - Nothing to do to build ancestorid index [04/Feb/2014:15:40:08 -0500] - import userRoot: Flushing caches... [04/Feb/2014:15:40:08 -0500] - import userRoot: Closing files... [04/Feb/2014:15:40:10 -0500] - All database threads now stopped [04/Feb/2014:15:40:10 -0500] - import userRoot: Import complete. Processed 1 entries in 15 seconds. (0.07 entries/sec) [04/Feb/2014:15:40:18 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [04/Feb/2014:15:40:19 -0500] - Db home directory is not set. Possibly nsslapd-directory (optinally nsslapd-db-home-directory) is missing in the config file. [04/Feb/2014:15:40:19 -0500] - I'm resizing my cache now...cache was 2453893120 and is now 800 [04/Feb/2014:15:40:36 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [04/Feb/2014:15:40:36 -0500] - slapd shutting down - signaling operation threads [04/Feb/2014:15:40:37 -0500] - slapd shutting down - closing down internal subsystems and plugins [04/Feb/2014:15:40:37 -0500] - Waiting for 4 database threads to stop [04/Feb/2014:15:40:38 -0500] - All database threads now stopped [04/Feb/2014:15:40:38 -0500] - slapd stopped. [04/Feb/2014:15:40:40 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [04/Feb/2014:15:40:41 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [04/Feb/2014:15:40:43 -0500] - The change of nsslapd-ldapilisten will not take effect until the server is restarted [04/Feb/2014:15:41:10 -0500] - Warning: Adding configuration attribute nsslapd-security [04/Feb/2014:15:41:13 -0500] - slapd shutting down - signaling operation threads [04/Feb/2014:15:41:14 -0500] - slapd shutting down - waiting for 30 threads to terminate [04/Feb/2014:15:41:14 -0500] - slapd shutting down - closing down internal subsystems and plugins [04/Feb/2014:15:41:15 -0500] - Waiting for 4 database threads to stop [04/Feb/2014:15:41:17 -0500] - All database threads now stopped [04/Feb/2014:15:41:17 -0500] - slapd stopped. [04/Feb/2014:15:41:27 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [04/Feb/2014:15:41:27 -0500] attrcrypt - No symmetric key found for cipher AES in backend userRoot, attempting to create one... [04/Feb/2014:15:41:28 -0500] attrcrypt - Key for cipher AES successfully generated and stored [04/Feb/2014:15:41:29 -0500] attrcrypt - No symmetric key found for cipher 3DES in backend userRoot, attempting to create one... [04/Feb/2014:15:41:29 -0500] attrcrypt - Key for cipher 3DES successfully generated and stored [04/Feb/2014:15:41:31 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [04/Feb/2014:15:41:31 -0500] - Listening on All Interfaces port 636 for LDAPS requests [04/Feb/2014:15:41:32 -0500] - Listening on /var/run/slapd-MIOVISION-LINUX.socket for LDAPI requests [04/Feb/2014:15:42:06 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=miovision,dc=linux--no CoS Templates found, which should be added before the CoS Definition. [04/Feb/2014:15:44:31 -0500] - slapd shutting down - signaling operation threads [04/Feb/2014:15:44:33 -0500] - slapd shutting down - closing down internal subsystems and plugins [04/Feb/2014:15:44:44 -0500] - Waiting for 4 database threads to stop [04/Feb/2014:15:44:47 -0500] - All database threads now stopped [04/Feb/2014:15:44:47 -0500] - slapd stopped. [04/Feb/2014:15:44:49 -0500] - 389-Directory/1.2.11.15 B2013.337.1530 starting up [04/Feb/2014:15:44:51 -0500] schema-compat-plugin - warning: no
Re: [Freeipa-users] ipa AD trust issue
On 02/04/2014 03:28 PM, Steve Dainard wrote: has anyone worked it out. Secondly cifs-utils has dependency on samba3 packages and ipa-ad-trust needs samba4 but samba3 and samba4 don't like each other , so this is the story of my experience with ipa. Any suggestions ? Why do you need cifs-utils on the same server? cifs-utils to make a system a client to MSFT file server, AFAIU you cant make IPA server to be a cifs client. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html Step 3 mentions that cifs-utils is required, but: yum install cifs-utils Loaded plugins: product-id, security, subscription-manager This system is receiving updates from Red Hat Subscription Management. rhel-6-server-cf-tools-1-rpms | 2.8 kB 00:00 rhel-6-server-rhev-agent-rpms | 3.1 kB 00:00 rhel-6-server-rpms| 3.7 kB 00:00 Setting up Install Process Resolving Dependencies -- Running transaction check --- Package cifs-utils.x86_64 0:4.8.1-19.el6 will be installed -- Processing Dependency: libwbclient.so.0()(64bit) for package: cifs-utils-4.8.1-19.el6.x86_64 -- Running transaction check --- Package samba-winbind-clients.x86_64 0:3.6.9-167.el6_5 will be installed -- Processing Dependency: samba-winbind = 3.6.9-167.el6_5 for package: samba-winbind-clients-3.6.9-167.el6_5.x86_64 -- Running transaction check --- Package samba-winbind.x86_64 0:3.6.9-167.el6_5 will be installed -- Processing Dependency: samba-common = 3.6.9-167.el6_5 for package: samba-winbind-3.6.9-167.el6_5.x86_64 -- Running transaction check --- Package samba-common.x86_64 0:3.6.9-167.el6_5 will be installed -- Processing Conflict: samba4-common-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-common 3.9.9 -- Processing Conflict: samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-winbind 3.9.9 -- Processing Conflict: samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-winbind-clients 3.9.9 -- Finished Dependency Resolution Error: samba4-common conflicts with samba-common-3.6.9-167.el6_5.x86_64 Error: samba4-winbind-clients conflicts with samba-winbind-clients-3.6.9-167.el6_5.x86_64 Error: samba4-winbind conflicts with samba-winbind-3.6.9-167.el6_5.x86_64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Is this no longer a requirement? Can this documentation be updated? Steve Can you please file a BZ? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] More SSO Strangeness
Okay, Spent some time on this one... Some users can login SSO no problem, others have to put in their password. Strange as it seems, if the length of the username was greater than 4, the SSO worked. So markg@test.local works, but mark@test.local doesn't. My guess is something to do with the NetBios name length? Fedora 20 IPA Server CentOS 6.5 IPA Client Win 2012 AD Domain Server Setup as IPA as a subdomain of AD. AD Domain: test.local IPA Domain: hosted.test.local ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade form Centos to Fedora (3.0.0 - 3.3.3)
Rob, To add the second master-with-CA, is it as simple as doing this on one of the replicas? # ipa-ca-install /path/to/replica-info-hostname.foo.net.gpg Bret On 02/05/2014 04:35 AM, Rob Crittenden wrote: Will Sheldon wrote: Hello IPA users :) We have implemented IPA using the packaged version in centos 6.5 (which is 3.0.0-37.el6), but have been playing with the more recent version in Fedora 19 (3.3.3-2.fc19) and are quite keen to take advantage of the shiny new features, so are thinking about migrating. Has anyone done this? Is there an easy way to migrate/upgrade? What would happen if I tried to setup a FC19 replica, would it get angry and break? We only have users in production so far, (no production clients or issued certs) so maybe the user migration script mentioned in previous posts would be the best bet? Any pointers would be hugely appreciated.. This is exactly the way to migrate between versions. You'll want to set up a CA on the F19 server for sure, and DNS if you're using that. The idea is that you set up the new master, spend some time (days, weeks not months) verifying that things are working ok, then remove the old server and things should continue to just work. We also recommend having at least two masters with CAs for redundancy and avoiding a single point of failure. We have discovered a bug in the way clients are enrolled though. We store the name of the master you enroll against. Normally this isn't a big deal, especially if you use SRV records. The problem is if that some tools use the master from this file to connect to and not SRV records, so you may want to run around to your clients and change this in /etc/ipa/default.conf once the migration is complete. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade form Centos to Fedora (3.0.0 - 3.3.3)
The installation part is indeed that simple, but you will also want to additionally turn the new CA to be the master CA so that it properly generates the CRL and renews the CA subsystem certificates when the old master CA is decommissioned. See [1] and [2] for more information. Martin [1] http://www.freeipa.org/page/Howto/Migration#Migrating_to_different_platform_or_OS [2] http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Reconfigure_a_CA_as_the_new_master On 02/05/2014 08:38 PM, Bret Wortman wrote: Rob, To add the second master-with-CA, is it as simple as doing this on one of the replicas? # ipa-ca-install /path/to/replica-info-hostname.foo.net.gpg Bret On 02/05/2014 04:35 AM, Rob Crittenden wrote: Will Sheldon wrote: Hello IPA users :) We have implemented IPA using the packaged version in centos 6.5 (which is 3.0.0-37.el6), but have been playing with the more recent version in Fedora 19 (3.3.3-2.fc19) and are quite keen to take advantage of the shiny new features, so are thinking about migrating. Has anyone done this? Is there an easy way to migrate/upgrade? What would happen if I tried to setup a FC19 replica, would it get angry and break? We only have users in production so far, (no production clients or issued certs) so maybe the user migration script mentioned in previous posts would be the best bet? Any pointers would be hugely appreciated.. This is exactly the way to migrate between versions. You'll want to set up a CA on the F19 server for sure, and DNS if you're using that. The idea is that you set up the new master, spend some time (days, weeks not months) verifying that things are working ok, then remove the old server and things should continue to just work. We also recommend having at least two masters with CAs for redundancy and avoiding a single point of failure. We have discovered a bug in the way clients are enrolled though. We store the name of the master you enroll against. Normally this isn't a big deal, especially if you use SRV records. The problem is if that some tools use the master from this file to connect to and not SRV records, so you may want to run around to your clients and change this in /etc/ipa/default.conf once the migration is complete. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade form Centos to Fedora (3.0.0 - 3.3.3)
On 2/5/2014, 1:35 AM, Rob Crittenden wrote: Will Sheldon wrote: Hello IPA users :) We have implemented IPA using the packaged version in centos 6.5 (which is 3.0.0-37.el6), but have been playing with the more recent version in Fedora 19 (3.3.3-2.fc19) and are quite keen to take advantage of the shiny new features, so are thinking about migrating. Has anyone done this? Is there an easy way to migrate/upgrade? What would happen if I tried to setup a FC19 replica, would it get angry and break? We only have users in production so far, (no production clients or issued certs) so maybe the user migration script mentioned in previous posts would be the best bet? Any pointers would be hugely appreciated.. This is exactly the way to migrate between versions. You'll want to set up a CA on the F19 server for sure, and DNS if you're using that. The idea is that you set up the new master, spend some time (days, weeks not months) verifying that things are working ok, then remove the old server and things should continue to just work. We also recommend having at least two masters with CAs for redundancy and avoiding a single point of failure. We have discovered a bug in the way clients are enrolled though. We store the name of the master you enroll against. Normally this isn't a big deal, especially if you use SRV records. The problem is if that some tools use the master from this file to connect to and not SRV records, so you may want to run around to your clients and change this in /etc/ipa/default.conf once the migration is complete. rob Yay! That’s easier than I thought it would be, thanks Rob. Would this work as a solution? 1) Leave current centos server (ipa.domain.com (http://ipa.domain.com)) in production 2) Configure new FC19 ipa server as a replica (newipa.domain.com (http://newipa.domain.com)) using the server install script 3) Check that newipa.domain.com (http://newipa.domain.com) is functioning as expected. 4) Remove centos server from production (not checked, but I assume there is a documented process for this) 5) Install new FC19 replica using same IP and DNS name as the old centos server (ipa.domain.com). ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Cross domain trust
After the initial setup of a trust I'm attempting to get kerberos tickets against the AD domain. Step 12 in this document: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.htmlsays: Then, request service tickets for services within the Active Directory domain. [root@ipaserver ]# kvno cifs/adserver.adexample.com@AD.DOMAIN If the Active Directory service ticket is succcessfully granted, then there will be a cross-realm TGT listed with all of the other requested tickets. This will have the name krbtgt/AD.DOMAIN@IPA.DOMAIN. I get an error back: # kvno cifs/dc1.miovision.c...@miovision.corp kvno: Server not found in Kerberos database while getting credentials for cifs/dc1.miovision.c...@miovision.corp But I do have a krbtgt ticket/AD domain: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: sdainard-r...@miolinux.corp Valid starting ExpiresService principal 02/05/14 14:21:06 02/06/14 14:21:06 krbtgt/miolinux.c...@miolinux.corp 02/05/14 14:21:17 02/06/14 14:21:06 host/ipa1.miolinux.c...@miolinux.corp 02/05/14 14:21:20 02/06/14 14:21:06 krbtgt/miovision.c...@miolinux.corp Also, is it normal to not find the Linux realm listed in the domain trust list on the AD DC? *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa AD trust issue
https://bugzilla.redhat.com/show_bug.cgi?id=1061897 *Steve Dainard * IT Infrastructure Manager Miovision http://miovision.com/ | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog http://miovision.com/blog | **LinkedIn https://www.linkedin.com/company/miovision-technologies | Twitter https://twitter.com/miovision | Facebook https://www.facebook.com/miovision* -- Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Wed, Feb 5, 2014 at 12:34 PM, Dmitri Pal d...@redhat.com wrote: On 02/04/2014 03:28 PM, Steve Dainard wrote: has anyone worked it out. Secondly cifs-utils has dependency on samba3 packages and ipa-ad-trust needs samba4 but samba3 and samba4 don't like each other , so this is the story of my experience with ipa. Any suggestions ? Why do you need cifs-utils on the same server? cifs-utils to make a system a client to MSFT file server, AFAIU you cant make IPA server to be a cifs client. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.html Step 3 mentions that cifs-utils is required, but: yum install cifs-utils Loaded plugins: product-id, security, subscription-manager This system is receiving updates from Red Hat Subscription Management. rhel-6-server-cf-tools-1-rpms | 2.8 kB 00:00 rhel-6-server-rhev-agent-rpms | 3.1 kB 00:00 rhel-6-server-rpms| 3.7 kB 00:00 Setting up Install Process Resolving Dependencies -- Running transaction check --- Package cifs-utils.x86_64 0:4.8.1-19.el6 will be installed -- Processing Dependency: libwbclient.so.0()(64bit) for package: cifs-utils-4.8.1-19.el6.x86_64 -- Running transaction check --- Package samba-winbind-clients.x86_64 0:3.6.9-167.el6_5 will be installed -- Processing Dependency: samba-winbind = 3.6.9-167.el6_5 for package: samba-winbind-clients-3.6.9-167.el6_5.x86_64 -- Running transaction check --- Package samba-winbind.x86_64 0:3.6.9-167.el6_5 will be installed -- Processing Dependency: samba-common = 3.6.9-167.el6_5 for package: samba-winbind-3.6.9-167.el6_5.x86_64 -- Running transaction check --- Package samba-common.x86_64 0:3.6.9-167.el6_5 will be installed -- Processing Conflict: samba4-common-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-common 3.9.9 -- Processing Conflict: samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-winbind 3.9.9 -- Processing Conflict: samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 conflicts samba-winbind-clients 3.9.9 -- Finished Dependency Resolution Error: samba4-common conflicts with samba-common-3.6.9-167.el6_5.x86_64 Error: samba4-winbind-clients conflicts with samba-winbind-clients-3.6.9-167.el6_5.x86_64 Error: samba4-winbind conflicts with samba-winbind-3.6.9-167.el6_5.x86_64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Is this no longer a requirement? Can this documentation be updated? Steve Can you please file a BZ? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs?www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cross domain trust
On Wed, 05 Feb 2014, Steve Dainard wrote: After the initial setup of a trust I'm attempting to get kerberos tickets against the AD domain. Step 12 in this document: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.htmlsays: Then, request service tickets for services within the Active Directory domain. [root@ipaserver ]# kvno cifs/adserver.adexample.com@AD.DOMAIN If the Active Directory service ticket is succcessfully granted, then there will be a cross-realm TGT listed with all of the other requested tickets. This will have the name krbtgt/AD.DOMAIN@IPA.DOMAIN. I get an error back: # kvno cifs/dc1.miovision.c...@miovision.corp kvno: Server not found in Kerberos database while getting credentials for cifs/dc1.miovision.c...@miovision.corp Can you try 'KRB5_TRACE=/dev/stderr kvno -S cifs dc1.miovision.corp'? Ideally, I'd like to see your /etc/krb5.conf, it should have mapping between AD DNS domain and AD realm so that IPA KDC will be able to route the ticket request properly to the AD DC. Without that it may assume miovision.corp belongs to the IPA realm. But I do have a krbtgt ticket/AD domain: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: sdainard-r...@miolinux.corp Valid starting ExpiresService principal 02/05/14 14:21:06 02/06/14 14:21:06 krbtgt/miolinux.c...@miolinux.corp 02/05/14 14:21:17 02/06/14 14:21:06 host/ipa1.miolinux.c...@miolinux.corp 02/05/14 14:21:20 02/06/14 14:21:06 krbtgt/miovision.c...@miolinux.corp Also, is it normal to not find the Linux realm listed in the domain trust list on the AD DC? It should be listed there. If it is not listed, it means no real trust is established on the AD side. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cross domain trust
On Wed, 05 Feb 2014, Alexander Bokovoy wrote: On Wed, 05 Feb 2014, Steve Dainard wrote: After the initial setup of a trust I'm attempting to get kerberos tickets against the AD domain. Step 12 in this document: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-diff-dns-domains.htmlsays: Then, request service tickets for services within the Active Directory domain. [root@ipaserver ]# kvno cifs/adserver.adexample.com@AD.DOMAIN If the Active Directory service ticket is succcessfully granted, then there will be a cross-realm TGT listed with all of the other requested tickets. This will have the name krbtgt/AD.DOMAIN@IPA.DOMAIN. I get an error back: # kvno cifs/dc1.miovision.c...@miovision.corp kvno: Server not found in Kerberos database while getting credentials for cifs/dc1.miovision.c...@miovision.corp Can you try 'KRB5_TRACE=/dev/stderr kvno -S cifs dc1.miovision.corp'? Ideally, I'd like to see your /etc/krb5.conf, it should have mapping between AD DNS domain and AD realm so that IPA KDC will be able to route the ticket request properly to the AD DC. Without that it may assume miovision.corp belongs to the IPA realm. Actually, that mapping should be generated by sssd in /var/lib/sss/pubconf/krb5.include.d/domain_realm_miolinux_corp -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Deny SSH access from selected host
Would it be possible to deny ssh access per host without pulling a host off FreeIPA management? from-host part of the rule is not enforced by default due to the fact that it is pretty easy to fake that one on connection. You can try to create more specific rules allowing access to the systems. With allow_all rule disabled these would help -- when there is no rule for that user to access an SSH service on the host, it will not be able to do so. Are you using allow_all rule right now? Yes, the all_allow rule was in place. I didn't see the allow all from the browser though and wasn't aware of it either. After I disabled it, I was able to achieve selective access. Thank you very much. http://www.freeipa.org/page/Howto/HBAC_and_allow_all -- / Alexander Bokovoy William ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cross domain trust
I didn't have the firewall on my IPA server down while forming the trust. All seems to be working now. Thanks for your help. Steve -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] HBAC - expected behaviour?
That helps, and I read http://www.freeipa.org/page/Howto/HBAC_and_allow_all Now I understand how it works and the expected behaviour. Thanks. Les -Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Tuesday, 4 February 2014 6:30 PM To: Les Stott; freeipa-users@redhat.com Subject: Re: [Freeipa-users] HBAC - expected behaviour? On 02/04/2014 05:11 AM, Les Stott wrote: Hi, Running freeipa 3.0.0-37.el6 on rhel 6.4 and just had a query about HBAC rules and how the global allow_all rule applies. I configured a rule for a single host (host1) allowing access via ssh to only a single user (john) via ssh. i.e. # ipa hbacrule-show host1_access Rule name: host1_access Description: Only john can access host1 Enabled: TRUE Users: john Hosts: host1.domain.com Services: sshd When I run the hbac test against the rule, checking another user jane, it works as expected to deny access to jane. But if I include the allow_all rule in the test jane is granted access and can login. I also proved this by actually using ssh to login. If I access the host host1 and remove allow_all from its defined HBAC rules in the web ui, jane can still access host1 via ssh (actually tested login). In the end, for the rule to work as expected (jane to be disallowed access to host1), I've had to modify the allow_all HBAC rule and set it to apply to all hosts except host1. # ipa hbacrule-show allow_all Rule name: allow_all User category: all sourcehostcategory: all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE Hosts: host2.domain.com, host3.domain.com, host4.domain.com Is this how its supposed to be? Or is it a bug in this older version? I would have thought that if the host didn't have the hbac rule allow_all applied to it, just the restrictive host1_access rule, that allow_all wouldn't apply. Thanks, Les Hello Les, I am not aware of any recent bugs in HBAC, this is likely a configuration issue. This is how the default HBAC allow_all looks like: # ipa hbacrule-show allow_all Rule name: allow_all User category: all Host category: all sourcehostcategory: all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE Host category: all means that the rule is effective for all hosts. By selectively specifying the hosts, you disabled this selector. Does it help? Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
