Re: [Freeipa-users] ipa: ERROR: attribute 'idnsAllowTransfer' not allowed
On 02/25/2013 03:38 PM, Sigbjorn Lie wrote: On Mon, February 25, 2013 12:59, Christian Horn wrote: Hi, On Mon, Feb 25, 2013 at 09:46:49AM +0100, Sigbjorn Lie wrote: $ ipa dnszone-add example.com --name-server=ns01.example.com --admin-email=hostmaster.example.com ipa: ERROR: attribute idnsAllowTransfer not allowed [..] Is this a known error? Yes, the idnsZone objectClass entry was not updated properly during ipa-server update process. To fix this the schema has to be modified, https://access.redhat.com/knowledge/solutions/301213 has the details. Thank you. That worked just fine. :) Regards, Siggi Hi guys, I am glad you resolved the issue. I am just curious - from what version to what version did you upgrade? Is this is a bug in IPA in RHEL 6.4? Thank you, Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-replica-install command failed
On 02/26/2013 09:01 AM, Umarzuki Mochlis wrote: hi, on tried to create a free-ipa replica on fedora 18 with freeipa-server-3.1.2-1.fc18.x86_64 below is last few lines of /var/log/ipareplica-install.log 2013-02-25T16:16:33Z DEBUG retrieving schema for SchemaCache url=ldap://ipa.domain.com:389 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x3b77758 2013-02-25T16:18:42Z INFO File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 617, in run_script return_value = main_function() File /usr/sbin/ipa-replica-install, line 633, in main ds = install_replica_ds(config) File /usr/sbin/ipa-replica-install, line 161, in install_replica_ds pkcs12_info) File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py, line 303, in create_replica self.start_creation(runtime=60) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 358, in start_creation method() File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py, line 316, in __setup_replica r_bindpw=self.dm_password) File /usr/lib/python2.7/site-packages/ipaserver/install/replication.py, line 864, in setup_replication raise RuntimeError(Failed to start replication) 2013-02-25T16:18:42Z INFO The ipa-replica-install command failed, exception: RuntimeError: Failed to start replication is this a known issue/bug or simply errors on my part? Hello Umarzuki, I am not aware of this bug. Can you please check 389-ds-base logs on the replica and see if there is any bug? The log should be in /var/log/dirsrv/slapd-YOUR-IPA-INSTANCE/errors. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Password expiry when account provisioned/updated via JSON RPC
On 02/25/2013 04:38 PM, Brian Smith wrote: It seems that regardless of the global password expiry setting, that setting a password via the methods user-add passwd i will always have a password that expires in 90 days. I followed the instructions here http://freeipa.org/page/PasswordSynchronization to avoid the immediate expiry, but I need at least 180 days for my configuration to work. Any help would be appreciated! -- Brian Smith Assistant Director Research Computing, University of South Florida 4202 E. Fowler Ave. SVC4010 Office Phone: +1 813 974-1467 Organization URL: http://rc.usf.edu Hello Brian, Updating maximum password expiration time with ipa pwpolicy-mod affects only new passwords, i.e. password that you already changed will have the old lifetime. When I tested this on Fedora 18, password change worked for me: # ipa pwpolicy-mod --maxlife 180 Group: global_policy Max lifetime (days): 180 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 600 # ipa user-add --first=Foo --last=Bar fbar - Added user fbar - User login: fbar First name: Foo Last name: Bar Full name: Foo Bar Display name: Foo Bar Initials: FB Home directory: /home/fbar GECOS field: Foo Bar Login shell: /bin/sh Kerberos principal: f...@example.com Email address: f...@example.com UID: 175821 GID: 175821 Password: False Member of groups: ipausers Kerberos keys available: False # ipa passwd fbar New Password: Enter New Password again to verify: --- Changed password for f...@example.com --- $ ssh f...@ipa.client.fqdn f...@ipa.client.fqdn's password: Password expired. Change your password now. Last login: Tue Feb 26 09:16:39 2013 from 10.0.0.1 WARNING: Your password has expired. You must change your password now and login again! Changing password for user fbar. Current Password: New password: Retype new password: Your password will expire in 180 day(s). passwd: all authentication tokens updated successfully. Connection to ipa.client.fqdn closed. Does this usecase work for you or are you hitting a bug? As for the warning about expiring password, this is a bug in sssd component which was already fixed upstream: https://fedorahosted.org/sssd/ticket/1808 Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-replica-install command failed
2013/2/26 Martin Kosek mko...@redhat.com: Hi Martin, I found below on errors file [26/Feb/2013:00:16:14 +0800] - 389-Directory/1.3.0.3 B2013.045.10 starting up [26/Feb/2013:00:16:14 +0800] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missin g in the config file. . . [26/Feb/2013:00:16:32 +0800] - 389-Directory/1.3.0.3 B2013.045.10 starting up [26/Feb/2013:00:16:32 +0800] ipaenrollment_start - [file ipa_enrollment.c, line 390]: Failed to get default realm?! . . [26/Feb/2013:00:16:33 +0800] NSMMReplicationPlugin - agmt=cn=meToipa.domain.com (ipa:389): Replica has a different generation ID than the local data. [26/Feb/2013:00:16:33 +0800] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=domain,dc=com is going offline; disabling replication Hello Umarzuki, I am not aware of this bug. Can you please check 389-ds-base logs on the replica and see if there is any bug? The log should be in /var/log/dirsrv/slapd-YOUR-IPA-INSTANCE/errors. Martin -- Regards, Umarzuki Mochlis http://debmal.my ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-replica-install command failed
Hm, all these are usually benign, when we are just setting up a replication. Can you please send me the whole ipareplica-install.log and dirsrv's errors log so I can see these errors in a broader context? You can do it in private message if you want. Btw I assume that you are running on the current Fedora 18 389-ds-base version (389-ds-base-0:1.3.0.2-1.fc18) Thanks, Martin On 02/26/2013 09:36 AM, Umarzuki Mochlis wrote: 2013/2/26 Martin Kosek mko...@redhat.com: Hi Martin, I found below on errors file [26/Feb/2013:00:16:14 +0800] - 389-Directory/1.3.0.3 B2013.045.10 starting up [26/Feb/2013:00:16:14 +0800] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missin g in the config file. . . [26/Feb/2013:00:16:32 +0800] - 389-Directory/1.3.0.3 B2013.045.10 starting up [26/Feb/2013:00:16:32 +0800] ipaenrollment_start - [file ipa_enrollment.c, line 390]: Failed to get default realm?! . . [26/Feb/2013:00:16:33 +0800] NSMMReplicationPlugin - agmt=cn=meToipa.domain.com (ipa:389): Replica has a different generation ID than the local data. [26/Feb/2013:00:16:33 +0800] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=domain,dc=com is going offline; disabling replication Hello Umarzuki, I am not aware of this bug. Can you please check 389-ds-base logs on the replica and see if there is any bug? The log should be in /var/log/dirsrv/slapd-YOUR-IPA-INSTANCE/errors. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA for AMM users management
And what? Is there any result? I try same thing with my AMM and IPA В Пн., 05/11/2012 в 09:32 +0100, Petr Spacek пишет: On 11/03/2012 01:12 PM, Pavel Zhukov wrote: Can you do NS lookup of the IPA server from the AMM box? yes Can you do kinit from the AMM box against IPA? Can you do ldapsearch from the AMM box against IPA? no, AMM has restricted shell and web GUI. Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) on the link between AMM and IPA server? Because there are no records in access log I will bet on some name resolution or firewall problem. Do AMM get right DNS responses (i.e. name and IP address of the IPA server)? Do AMM established TCP connection with the IPA server? -- Petr^2 Spacek Do you see anything in the logs from such activity? ___ 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] nsslapd-changelogmaxage
ok, but setting nsslapd-changelogmaxage parameter doesnt automatically shrink changelog. The file size dosent change. Other idea how to trim changelog file? 2013/2/25 Rich Megginson rmegg...@redhat.com On 02/25/2013 11:33 AM, Kriss Von Prosst wrote: Hi, I have multimaster replication enviroment, IPA v2.2 on Fedora 17. On each replica, folder /var/lib/dirsrv/slapd-cosp/cldb/ has big size (~7GB). This is half of all available space for '/'. I found that changelog file can be trim using 'nsslapd-changelogmaxage' parameter. By default, this parameter is not set in dse.ldif (is this correct?). My questions are: a) where should I put 'nsslapd-changelogmaxage' parameter, into tree: cn=Retro Changelog Plugin, cn=config or cn=changelog5,cn=config. Not Retro Changelog https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring-Replication-cmd.html#Configuring-Replication-Suppliers-cmd b) what are the consequences when I set this parameter to nsslapd-changelogmaxage: 10d? c) Is any other possibility to limit increase of this file? There is also the nsslapd-changelogmaxentries parameter https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnchangelog5 Kriss ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://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] FreeIPA for AMM users management
On 26.2.2013 11:49, Артур Файзуллин wrote: And what? Is there any result? I try same thing with my AMM and IPA Unfortunately, we don't have sufficient information to give you any advice. Please, try to provide output from a sniffer as I asked in last reply. Then we will try to help you. (You can send the data to me privately, if you want.) Petr^2 Spacek В Пн., 05/11/2012 в 09:32 +0100, Petr Spacek пишет: On 11/03/2012 01:12 PM, Pavel Zhukov wrote: Can you do NS lookup of the IPA server from the AMM box? yes Can you do kinit from the AMM box against IPA? Can you do ldapsearch from the AMM box against IPA? no, AMM has restricted shell and web GUI. Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) on the link between AMM and IPA server? Because there are no records in access log I will bet on some name resolution or firewall problem. Do AMM get right DNS responses (i.e. name and IP address of the IPA server)? Do AMM established TCP connection with the IPA server? -- Petr^2 Spacek Do you see anything in the logs from such activity? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL 6.4 , IPA 3.0 and bind-chroot
On 23.2.2013 23:01, Dale Macartney wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/23/2013 09:47 PM, Dmitri Pal wrote: On 02/23/2013 12:48 PM, Dale Macartney wrote: Hi all I've just performed a clean IPA installation and noticed that if you're using integrated DNS, you are still unable to use bind in a chrooted environment with a default IPA install. Basically if its a chrooted environment, named will fail to start. To replicate what I've done, do the following. # yum install ipa-server bind bind-chroot bind-dyndb-ldap -y # ipa-server-install --setup-dns (do your usual thing here) - From what I've been testing, there needs to be quite a few libraries located in the chroot environment. I've done the below to get a little further (I should probably use symbolic links, but for now copying the files is a start). mkdir /var/named/chroot/lib64/ cp /lib64/libldap-2.4.so.2 /var/named/chroot/lib64/ cp /lib64/liblber-2.4.so.2 /var/named/chroot/lib64/ cp /lib64/libplds4.so /var/named/chroot/lib64/ cp /lib64/libplc4.so /var/named/chroot/lib64/ cp /lib64/libnspr4.so /var/named/chroot/lib64/ cp /lib64/libcrypt.so.1 /var/named/chroot/lib64/ cp /lib64/libfreebl3.so /var/named/chroot/lib64/ mkdir /var/named/chroot/usr/lib64/ cp /usr/lib64/libssl3.so /var/named/chroot/usr/lib64/ cp /usr/lib64/libsmime3.so /var/named/chroot/usr/lib64/ cp /usr/lib64/libnss3.so /var/named/chroot/usr/lib64/ cp /usr/lib64/libnssutil3.so /var/named/chroot/usr/lib64/ cp /usr/lib64/libsasl2.so.2 /var/named/chroot/usr/lib64/ Now when I restart named, I get the below error in /var/log/messages. Does anyone have any ideas of the best way to get around this error? Feb 23 17:35:29 ds01 named[2425]: Failed to parse the principal name DNS/ds01.example.com (Configuration file does not specify default realm) It should be DNS/ds01.example.com@YOURREALMNAME.SOMETHING oh of course.. what a face palm moment. Where does the default ipa installation put the DNS keytab file? I did notice an /etc/named.keytab was present, but placing that in /var/named/chroot/etc didn't seem to improve matters. I wrote short how-to: http://freeipa.org/page/Howto/FreeIPA_with_integrated_BIND_inside_chroot In my RHEL 6.4 test environment it worked, but it is a bit hackish. Any improvements are welcome! I do not know the exact reason but it might be that bind ldap driver can't locate its kerberos configuration. I hope it will give you a hint and unblock you before the real masters of DNS chime in. i I know this has been a rather long lasting rfe/bug/how ever you want to label it. https://fedorahosted.org/freeipa/ticket/126 If I make any progress I'll let the team know. -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrading to 6.4 - additional information
On 02/26/2013 04:29 PM, Dmitri Pal wrote: On 02/21/2013 12:31 PM, Dmitri Pal wrote: On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: On 02/21/2013 09:40 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: On 02/21/2013 09:34 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: On 02/21/2013 09:07 AM, Rob Crittenden wrote: add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 'ipaExternalMember' DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ description $$ owner) X-ORIGIN 'IPA v3' ) Well that fails as well, though in sort of a self inflicted way: 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, exception: DatabaseError: Server is unwilling to perform: Minimum SSF not met. arguments: base=cn=config,cn=ldbm database,cn=plugins,cn=config, scope=0, filterstr=(objectclass=*) 2013-02-21T16:24:30Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: DatabaseError: Server is unwilling to perform: Minimum SSF not met. arguments: base=cn=config,cn=ldbm database,cn=plugins,cn=config, scope=0, filterstr=(objectclass=*) Now this probably comes about because I set: nsslapd-minssf: 56 For security. I can cange that back to the default and probably move past this, but is that a known issue? Is there another way around? As root try the --ldapi flag: # ipa-ldap-updater --ldapi /path/to/scheme.update rob ERROR: LDAPUpdate: syntax error: dn is not defined in the update, data source=schema.update -Erinn Sorry, add this to the top of your update file: dn: cn=schema rob No worries! Thanks for the help, after a restart of IPA the web UI is working again. I reckon this is something that needs to be fixed, does opening a support case and pointing them to that bug help you folks out with this in any way? This is a know defect. We just did not realize it would have such a bad impact on upgrade. Sorry, the errata is on the way. I would recommend everyone to not upgrade to 6.4 until the errata is shipped. We will notify you as soon as it goes out. Sorry again. I would like to clarify the impact, we have found out it is broader than currently stated: We did some research of this issue: 1) The upgrade works fine from 6.3 to 6.4 and the issue does not exhibit itself 2) We have been able to reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the expected upgrade part is 6.2 - 6.3 - 6.4 the question comes up whether this fix is actually that urgent. This issue also affects both upgrade paths (6.2 - 6.4 and 6.2 - 6.3 - 6.4). This makes the fix urgent and it should be fixed in 6.4 too. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cannot obtain CA Certificate
Sorry for the late response, so I tried this, and it changed the error to the following: Synchronizing time with KDC... Joining realm failed: HTTP response code is 401, not 200 Installation failed. Rolling back changes. Looking at debug this is what I see: HTTP/1.1 401 Authorization Required Date: Tue, 26 Feb 2013 16:54:21 GMT Server: Apache/2.2.15 (CentOS) * gss_init_sec_context() failed: : Server krbtgt/c...@example.com not found in Kerberos database WWW-Authenticate: Negotiate Last-Modified: Wed, 23 Jan 2013 22:16:50 GMT ETag: 4627-740-4d3fc0cfd7880 Accept-Ranges: bytes Content-Length: 1856 Connection: close Content-Type: text/html; charset=UTF-8 Thanks, _ John Moyer On Feb 19, 2013, at 6:35 AM, Jan-Frode Myklebust janfr...@tanso.net wrote: ipa : ERRORCannot obtain CA certificate 'ldap://ipa1.example.com' doesn't have a certificate. Installation failed. Rolling back changes. IPA client is not configured on this system. FYI, I have this same issue when enrolling RHEL5 clients. Have been doing this as a workaround: wget -O /etc/ipa/ca.crt http://ipa1.example.com/ipa/config/ca.crt ipa-client-install --no-ntp --mkhomedir --ca-cert-file=/etc/ipa/ca.crt -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrading to 6.4 - additional information
On 02/26/2013 10:29 AM, Dmitri Pal wrote: On 02/21/2013 12:31 PM, Dmitri Pal wrote: On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: On 02/21/2013 09:40 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: On 02/21/2013 09:34 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: On 02/21/2013 09:07 AM, Rob Crittenden wrote: add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 'ipaExternalMember' DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ description $$ owner) X-ORIGIN 'IPA v3' ) Well that fails as well, though in sort of a self inflicted way: 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, exception: DatabaseError: Server is unwilling to perform: Minimum SSF not met. arguments: base=cn=config,cn=ldbm database,cn=plugins,cn=config, scope=0, filterstr=(objectclass=*) 2013-02-21T16:24:30Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: DatabaseError: Server is unwilling to perform: Minimum SSF not met. arguments: base=cn=config,cn=ldbm database,cn=plugins,cn=config, scope=0, filterstr=(objectclass=*) Now this probably comes about because I set: nsslapd-minssf: 56 For security. I can cange that back to the default and probably move past this, but is that a known issue? Is there another way around? As root try the --ldapi flag: # ipa-ldap-updater --ldapi /path/to/scheme.update rob ERROR: LDAPUpdate: syntax error: dn is not defined in the update, data source=schema.update -Erinn Sorry, add this to the top of your update file: dn: cn=schema rob No worries! Thanks for the help, after a restart of IPA the web UI is working again. I reckon this is something that needs to be fixed, does opening a support case and pointing them to that bug help you folks out with this in any way? This is a know defect. We just did not realize it would have such a bad impact on upgrade. Sorry, the errata is on the way. I would recommend everyone to not upgrade to 6.4 until the errata is shipped. We will notify you as soon as it goes out. Sorry again. We did some research of this issue: 1) The upgrade works fine from 6.3 to 6.4 and the issue does not exhibit itself 2) We have been able to reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the expected upgrade part is 6.2 - 6.3 - 6.4 the question comes up whether this fix is actually that urgent. 4) In the presence of the simple workaround we feel that it is not that important to include this fix into the errata that we are working on. Please let us know if you think that there is a problem with the plan above. Well all I can tell you on this, is that mine was an upgrade from 6.3 to 6.4, so there is a case where it will fail going from 6.3 to 6.4, but how applicable it is I can't say. Otherwise, sure, sounds great to me. -Erin signature.asc Description: OpenPGP digital signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrading to 6.4 - additional information
On 02/26/2013 06:05 PM, Erinn Looney-Triggs wrote: On 02/26/2013 10:29 AM, Dmitri Pal wrote: On 02/21/2013 12:31 PM, Dmitri Pal wrote: On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: On 02/21/2013 09:40 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: On 02/21/2013 09:34 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: On 02/21/2013 09:07 AM, Rob Crittenden wrote: add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 'ipaExternalMember' DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ description $$ owner) X-ORIGIN 'IPA v3' ) Well that fails as well, though in sort of a self inflicted way: 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, exception: DatabaseError: Server is unwilling to perform: Minimum SSF not met. arguments: base=cn=config,cn=ldbm database,cn=plugins,cn=config, scope=0, filterstr=(objectclass=*) 2013-02-21T16:24:30Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: DatabaseError: Server is unwilling to perform: Minimum SSF not met. arguments: base=cn=config,cn=ldbm database,cn=plugins,cn=config, scope=0, filterstr=(objectclass=*) Now this probably comes about because I set: nsslapd-minssf: 56 For security. I can cange that back to the default and probably move past this, but is that a known issue? Is there another way around? As root try the --ldapi flag: # ipa-ldap-updater --ldapi /path/to/scheme.update rob ERROR: LDAPUpdate: syntax error: dn is not defined in the update, data source=schema.update -Erinn Sorry, add this to the top of your update file: dn: cn=schema rob No worries! Thanks for the help, after a restart of IPA the web UI is working again. I reckon this is something that needs to be fixed, does opening a support case and pointing them to that bug help you folks out with this in any way? This is a know defect. We just did not realize it would have such a bad impact on upgrade. Sorry, the errata is on the way. I would recommend everyone to not upgrade to 6.4 until the errata is shipped. We will notify you as soon as it goes out. Sorry again. We did some research of this issue: 1) The upgrade works fine from 6.3 to 6.4 and the issue does not exhibit itself 2) We have been able to reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the expected upgrade part is 6.2 - 6.3 - 6.4 the question comes up whether this fix is actually that urgent. 4) In the presence of the simple workaround we feel that it is not that important to include this fix into the errata that we are working on. Please let us know if you think that there is a problem with the plan above. Well all I can tell you on this, is that mine was an upgrade from 6.3 to 6.4, so there is a case where it will fail going from 6.3 to 6.4, but how applicable it is I can't say. Hi Erinn, Is 6.3 the original RHEL version where IPA server was installed? Or was IPA installed on RHEL-6.2 and then you upgraded RHEL to 6.3? Thank you, Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrading to 6.4 - additional information
On 02/26/2013 12:08 PM, Martin Kosek wrote: On 02/26/2013 06:05 PM, Erinn Looney-Triggs wrote: On 02/26/2013 10:29 AM, Dmitri Pal wrote: On 02/21/2013 12:31 PM, Dmitri Pal wrote: On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: On 02/21/2013 09:40 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: On 02/21/2013 09:34 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: On 02/21/2013 09:07 AM, Rob Crittenden wrote: add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 'ipaExternalMember' DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ description $$ owner) X-ORIGIN 'IPA v3' ) Well that fails as well, though in sort of a self inflicted way: 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, exception: DatabaseError: Server is unwilling to perform: Minimum SSF not met. arguments: base=cn=config,cn=ldbm database,cn=plugins,cn=config, scope=0, filterstr=(objectclass=*) 2013-02-21T16:24:30Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: DatabaseError: Server is unwilling to perform: Minimum SSF not met. arguments: base=cn=config,cn=ldbm database,cn=plugins,cn=config, scope=0, filterstr=(objectclass=*) Now this probably comes about because I set: nsslapd-minssf: 56 For security. I can cange that back to the default and probably move past this, but is that a known issue? Is there another way around? As root try the --ldapi flag: # ipa-ldap-updater --ldapi /path/to/scheme.update rob ERROR: LDAPUpdate: syntax error: dn is not defined in the update, data source=schema.update -Erinn Sorry, add this to the top of your update file: dn: cn=schema rob No worries! Thanks for the help, after a restart of IPA the web UI is working again. I reckon this is something that needs to be fixed, does opening a support case and pointing them to that bug help you folks out with this in any way? This is a know defect. We just did not realize it would have such a bad impact on upgrade. Sorry, the errata is on the way. I would recommend everyone to not upgrade to 6.4 until the errata is shipped. We will notify you as soon as it goes out. Sorry again. We did some research of this issue: 1) The upgrade works fine from 6.3 to 6.4 and the issue does not exhibit itself 2) We have been able to reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the expected upgrade part is 6.2 - 6.3 - 6.4 the question comes up whether this fix is actually that urgent. 4) In the presence of the simple workaround we feel that it is not that important to include this fix into the errata that we are working on. Please let us know if you think that there is a problem with the plan above. Well all I can tell you on this, is that mine was an upgrade from 6.3 to 6.4, so there is a case where it will fail going from 6.3 to 6.4, but how applicable it is I can't say. Hi Erinn, Is 6.3 the original RHEL version where IPA server was installed? Or was IPA installed on RHEL-6.2 and then you upgraded RHEL to 6.3? Thank you, Martin These systems have gone through all the point releases from 6 on up I believe. -Erinn signature.asc Description: OpenPGP digital signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrading to 6.4 - additional information
On 02/26/2013 06:10 PM, Erinn Looney-Triggs wrote: On 02/26/2013 12:08 PM, Martin Kosek wrote: On 02/26/2013 06:05 PM, Erinn Looney-Triggs wrote: On 02/26/2013 10:29 AM, Dmitri Pal wrote: On 02/21/2013 12:31 PM, Dmitri Pal wrote: On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: On 02/21/2013 09:40 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: On 02/21/2013 09:34 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: On 02/21/2013 09:07 AM, Rob Crittenden wrote: add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 'ipaExternalMember' DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ description $$ owner) X-ORIGIN 'IPA v3' ) Well that fails as well, though in sort of a self inflicted way: 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, exception: DatabaseError: Server is unwilling to perform: Minimum SSF not met. arguments: base=cn=config,cn=ldbm database,cn=plugins,cn=config, scope=0, filterstr=(objectclass=*) 2013-02-21T16:24:30Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: DatabaseError: Server is unwilling to perform: Minimum SSF not met. arguments: base=cn=config,cn=ldbm database,cn=plugins,cn=config, scope=0, filterstr=(objectclass=*) Now this probably comes about because I set: nsslapd-minssf: 56 For security. I can cange that back to the default and probably move past this, but is that a known issue? Is there another way around? As root try the --ldapi flag: # ipa-ldap-updater --ldapi /path/to/scheme.update rob ERROR: LDAPUpdate: syntax error: dn is not defined in the update, data source=schema.update -Erinn Sorry, add this to the top of your update file: dn: cn=schema rob No worries! Thanks for the help, after a restart of IPA the web UI is working again. I reckon this is something that needs to be fixed, does opening a support case and pointing them to that bug help you folks out with this in any way? This is a know defect. We just did not realize it would have such a bad impact on upgrade. Sorry, the errata is on the way. I would recommend everyone to not upgrade to 6.4 until the errata is shipped. We will notify you as soon as it goes out. Sorry again. We did some research of this issue: 1) The upgrade works fine from 6.3 to 6.4 and the issue does not exhibit itself 2) We have been able to reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the expected upgrade part is 6.2 - 6.3 - 6.4 the question comes up whether this fix is actually that urgent. 4) In the presence of the simple workaround we feel that it is not that important to include this fix into the errata that we are working on. Please let us know if you think that there is a problem with the plan above. Well all I can tell you on this, is that mine was an upgrade from 6.3 to 6.4, so there is a case where it will fail going from 6.3 to 6.4, but how applicable it is I can't say. Hi Erinn, Is 6.3 the original RHEL version where IPA server was installed? Or was IPA installed on RHEL-6.2 and then you upgraded RHEL to 6.3? Thank you, Martin These systems have gone through all the point releases from 6 on up I believe. -Erinn Ok, then this use case is also covered by the upcoming 6.4 fix. I just wanted to check that. Thanks, Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] IPA,NFS4,krb5p Ticket expired error
Hi, I have a IPA server, NFS4 Server sharing home directories with autofs and krb5p as only valid authentication. Mail Postfix/Dovecot both with startTLS and GSSAPI. All servers and clients are Red Hat 6.3 and updated with latest kernel and everything else. If i start and log in locally as user1 on a IPA Client machine everything works perfect including mail and home directory initially. I then start experience errors when trying to ssh other servers as ssh us...@mail.example.com. Nothing happens, no password question, nothing until i have to ctrl-c (tried leaving it overnight - still same). Mail stops working, thunderbird complain about expired credentials. If i use ssh as root to the server and then try either: su user1 or su - user1 both get same result as ssh user1. Sometimes a su have actually worked and i can browse to my mounted home directory but get permission denied when trying to access. id works and permissions on home directory shows ok but can't access anyway. The only thing i have found helping is to logout user1 on the client, login root and then ssh as user1. In that case i get password question and it works with home directory. If i logout root then, login user1 then mail, ssh and su works again for some time. I guess the credential renewal works in that case. Firewalls turned off, tried setenforce=0 and autofs on debug log mode but find nothing. Even sshd logging on and verbose ssh shows nothing wrong. It is like everything works but a expired ticket or something similar generate the error, tickets are new though and should be valid. Only error messages i have been able to find is: IPA server /var/log/messages show: rpc.gssd[1116]: Error doing stat on file '/tmp/krb5cc_48' automount[1197]: sasl_log_func:98: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired) Anyone have a idea what this could be and how to solve it? I am really thankful for any help. Regards, Johan. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] New User - Possible to point authentication to external KDC
On 02/26/2013 01:31 AM, Trey Dockendorf wrote: On Feb 25, 2013 1:23 AM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 02/23/2013 10:33 PM, Trey Dockendorf wrote: I just begun evaluating FreeIPA, after having successfully used 389ds for a few months. The move from 389 ds to FreeIPA is to leverage the authorization for host logins and also for simpler management. The University I am deploying at has a campus wide KDC and for security and audit reasons I prefer to point my authentication services at that Kerberos realm rather than storing passwords. I have successfully implemented this using the 389 ds pam pass through authentication plug-in , but have not found any documentation on how to do this same thing with FreeIPA. The complication with doing this is I do not have even a 1 way trust with the KDC. Getting a trust (even 1-way) is very difficult if not impossible, but so far I've been able to make PAM work with that situation both using local authentication and now 389 ds, both through PAM. Is it possible to have FreeIPA query a remote KDC while still being able to fallback to the local password store (ie external users not in campus domain). IPA uses the 389 DS so it might be possible to configure PAM pass through but there might be implications because if users are not in IPA you would not get a ticket and since you cant get a ticket you can't use UI and CLI. You can still bind using LDAP though as you do with the 389. So to manage IPA you would still have to have a user in IPA. However you will have two KDCs and I do not know what implications there would be for the clients, they might be confused. Frankly you are better off with 389 now untill we make setting up trusts with other IPAs or MIT KDCs simple. We did that for AD but it requires a clean DNS setup. I suspect DNS setup will be an issue in any case. Thanks - Trey ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ http://www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Thanks for the response! I do plan to have all my users in freeIPA. My goal is to have my freeIPA install just attempt a password authentication against external KDC via pam on the IPA server before trying the local password store. With my current 389 setup, clients are unaware of our campus KDC, the authentication is handled my 389 server and currently users in my LDAP who have campus accounts get their password verified via PAM and others in my LDAP use the local password stored in 389. The aspects of IPA aside from 389 are where my uncertainty lies. For example, if I have LDAP authenticate against an external KDC via PAM, can the user still get a ticket from my IPA? Also getting a trust may not be possible even if freeipa makes the process easier. This is a politics issue with our campus' main IT group and something I've worked around thus far. Is there anything in changes of the stock 389 that would prevent this from working in IPA? Also is there a preferred method for enabling plugins in IPA? Also how could I test this? Would a client machine joined to my IPA install be the best method? Thanks - Trey If you hit IPA with a kerberos authentication to the best of my knowledge KDC will read the data from LDAP and use it for authentication. It would not do PAM proxy in this case. The pam proxy would be possible only for the LDAP binds so I am not sure whether things would work for you. I see that you try to augment the existing infrastructure but I am not sure I have a clear picture in my mind of the architecture you envision. Is there any chance that you can put together a diagram? -- 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] proper way to clear sssd cache without sss_cache?
I know that at some point the sssd package (or maybe the tools package) started including sss_cache for managing the sssd cache. I have some RHEL5 boxes that don't have this utility. I've been stopping the sssd service, deleting the contents of /var/lib/sss/db/ and then restarting and things seem to be working OK, but I wanted to find out if there was a proper procedure? Thanks! -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
On 02/25/2013 02:29 PM, Mercer, Rodney wrote: I think that this is a good explanation or the solaris rbac model. http://www.softpanorama.org/Solaris/Security/solaris_rbac.shtml Regards, Rodney. I will definitely read it. But assume I did. What are the next steps? The schema is the right one so do you plan to start the design work? Would you start with the server side or with SSSD side? Adding schema to IPA and populating it with ldap modify or my loading ldif might give you enough to start designing and developing the SSSD component. The management interface for the server side can be added after the SSSD side is done. -- 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] proper way to clear sssd cache without sss_cache?
On 02/26/2013 02:29 PM, KodaK wrote: I know that at some point the sssd package (or maybe the tools package) started including sss_cache for managing the sssd cache. I have some RHEL5 boxes that don't have this utility. I've been stopping the sssd service, deleting the contents of /var/lib/sss/db/ and then restarting and things seem to be working OK, but I wanted to find out if there was a proper procedure? Thanks! Yes it was the proper procedure until we added a tool. -- 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] proper way to clear sssd cache without sss_cache?
Hi, Its what I have to do on most client side issues and what RH support advise. I was told that the sssd daemon would be upgraded in 6.4, its certainly seems to be my main pain point right now. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of KodaK [sako...@gmail.com] Sent: Wednesday, 27 February 2013 8:29 a.m. To: freeipa-users@redhat.com Subject: [Freeipa-users] proper way to clear sssd cache without sss_cache? I know that at some point the sssd package (or maybe the tools package) started including sss_cache for managing the sssd cache. I have some RHEL5 boxes that don't have this utility. I've been stopping the sssd service, deleting the contents of /var/lib/sss/db/ and then restarting and things seem to be working OK, but I wanted to find out if there was a proper procedure? Thanks! -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ 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] Non-Prod instance
On 02/25/2013 09:58 AM, Guy Matz wrote: Hello! Does anyone out there run two instances of freeipa, prod non-prod instances? Are there any issues to be wary of in this scenario? Any gotchas? Do you use the same realms domain names between instances? As long as you completely isolate one from another network wise you can use whatever names you want. Perhaps the fellow who upgraded his prod server to 6.4 might appreciate this . . . Thanks a lot, Guy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- 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] Non-Prod instance
Thanks! Is it a matter of isolating the networks? Or just making sure clients are pointing to the correct server? Thanks again, Guy On 02/26/2013 02:45 PM, Dmitri Pal wrote: On 02/25/2013 09:58 AM, Guy Matz wrote: Hello! Does anyone out there run two instances of freeipa, prod non-prod instances? Are there any issues to be wary of in this scenario? Any gotchas? Do you use the same realms domain names between instances? As long as you completely isolate one from another network wise you can use whatever names you want. Perhaps the fellow who upgraded his prod server to 6.4 might appreciate this . . . Thanks a lot, Guy ___ 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] proper way to clear sssd cache without sss_cache?
On Tue, Feb 26, 2013 at 02:36:42PM -0500, Dmitri Pal wrote: On 02/26/2013 02:29 PM, KodaK wrote: I know that at some point the sssd package (or maybe the tools package) started including sss_cache for managing the sssd cache. I have some RHEL5 boxes that don't have this utility. I've been stopping the sssd service, deleting the contents of /var/lib/sss/db/ and then restarting and things seem to be working OK, but I wanted to find out if there was a proper procedure? Thanks! Yes it was the proper procedure until we added a tool. The only thing to keep in mind is that by wiping out the whole cache removes all cached passwords. Depending on whether you use cache_credentials=True or whether your clients need to cache credentials at all you do or don't care :-) If you care, you might want to use the ldbmodify utility to instead set the dataExpire timestamp to a timestamp from the past (this is what sss_cache does internally btw) ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] FQDN Hostname Requirement
Hi All, Spec: Red Hat Enterprise Linux Server release 6.3 (Santiago) ipa-server-2.2.0-16.el6.x86_64 Issue: I made a post a while back regarding IPA and the forcing of the hostname to be a FQDN entry, rather than utilising `hostname --fqdn` ref: https://www.redhat.com/archives/freeipa-users/2012-March/msg00012.html Has this issue ever been addressed? As I've now bumped into an issue with RSA Securid Auth Manager 6.1, which will not work on a server with more than 27 characters in the hostname. Sadly our hostname does break this is some cases. cya Craig ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA for AMM users management
Ok! I will try :) but would you give me some advice :) what configs to put. should I use: * Use LDAP Servers for Authentication and Authorization * Use DNS to find LDAP Servers and put here domain name if IPA-server? * should in Active Directory Settings Enhanced role-based security be enabled? And what means AMM Target Name? * root dn = something like this dc=example,dc=com ? * Binding method which one to choose? w/ Configured Credentials w/ Login Credentials Some questions may be stupid, but I want to be sure in them :) В Вт., 26/02/2013 в 12:41 +0100, Petr Spacek пишет: On 26.2.2013 11:49, Артур Файзуллин wrote: And what? Is there any result? I try same thing with my AMM and IPA Unfortunately, we don't have sufficient information to give you any advice. Please, try to provide output from a sniffer as I asked in last reply. Then we will try to help you. (You can send the data to me privately, if you want.) Petr^2 Spacek В Пн., 05/11/2012 в 09:32 +0100, Petr Spacek пишет: On 11/03/2012 01:12 PM, Pavel Zhukov wrote: Can you do NS lookup of the IPA server from the AMM box? yes Can you do kinit from the AMM box against IPA? Can you do ldapsearch from the AMM box against IPA? no, AMM has restricted shell and web GUI. Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) on the link between AMM and IPA server? Because there are no records in access log I will bet on some name resolution or firewall problem. Do AMM get right DNS responses (i.e. name and IP address of the IPA server)? Do AMM established TCP connection with the IPA server? -- Petr^2 Spacek Do you see anything in the logs from such activity? ___ 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] Transferring mastership to a new server
Is is still required if the replica is created using the following command:- # ipa-replica-install --setup-ca --setup-dns -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] meaning of several domains in sssd.conf
What does it mean to have several domains listed in sssd.conf ? Will they all be queried on each login, or will only the first domain be queried if the user/groups is found there? Does having an IPA domain, and an LDAP domain pointing at the same servers give any protection against failures in the sssd_BE process allowing sssd to fail over to the next sssd_BE ? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
