Re: [Freeipa-users] error install replication
ipasrv# Service SSSD status sssd is runing nevertheless i restart service sssd but problem do not solved On Mon, Feb 9, 2015 at 11:19 AM, Martin Kosek mko...@redhat.com wrote: On 02/09/2015 07:42 AM, alireza baghery wrote: i check on both server ssh each other's name and ssh successful and resolve name was also correct on each server but i can not login with user admin from ipareplica via ssh (root@ipareplica]# ssh admin@ipasrv === failed) [root@ipareplica ~]# ssh ipasrv root@ipasrv's password: Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 =log /var/secure Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from 10.30.160.20 port 52110 ssh2 Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session opened for user root by (uid=0) = [root@ipasrv ~]# ssh ipareplica root@ipareplica's password: Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 == [root@ipareplica ~]# nslookup ipasrv Server: 10.30.160.19 Address:10.30.160.19#53 Name: ipasrv Address: 10.30.160.19 [root@ipasrv ~]# nslookup ipareplica Server: 127.0.0.1 Address:127.0.0.1#53 Name: ipareplica Address: 10.30.160.20 = Ok, so ssh is running, you can log in with root. I think that by 99% chance, your SSSD service is not running on the IPA server. Please check if this is the case and if yes, please try to (re)start it. If that helped, it would be also useful to see *why* the SSSD is not running (crash, misconfiguration, ...) Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] How do I modify the entry cache size?
On 02/09/2015 09:48 AM, Rich Megginson wrote:
On 02/08/2015 08:23 PM, Chris Mohler wrote:
Thanks for the reply and the link Rich!
dbmon.sh is a handy tool indeed.
I read the instructions and upped my entry cache size to 2gb because
I have enough ram.
Everything went well until
|service dirsrv restart
|
|I Got the following errors:
[06/Feb/2015:10:07:35 -0500] - slapd stopped.
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching
rule [caseIgnoreIA5Match] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching
rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 http://1.2.11.15
B2014.314.1342 starting up
[06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port
7389 for LDAP requests
[06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS
requests
|
|Oddly enough everything appears to be working. Are these messages safe to
ignore?
|
This is definitely not related to the cache size.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.
rpm -q 389-ds-base
find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25
{} /dev/null \;
|
|Another run of dbmon.sh shows that my entry cache was increased.
|||
|Thanks,
|
|-Chris
|
|
|
On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson rmegg...@redhat.com
mailto:rmegg...@redhat.com wrote:
On 02/07/2015 11:25 AM, Chris Mohler wrote:
Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to
increase the entry cache size
I'm trying to follow the directions here
/usr/lib/mozldap/ldapmodify -D cn=directory manager -w secret -p 389
dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 20971520
Is this the correct way to do this? How do I find out what the
cn=/|database_name is supposed to be?
|/
|/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the
script will tell you what the names of your databases are.
/|
|/
/|Thanks,
|/
/|-Chris
|/
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Thanks again Rich,
I have been having an abundance of issues with my FreeIPA server lately.
I'm not surprised that error is not related. I was not sure as It has
not surfaced in my logs before I changed the entry cache size. Possibly
this will be the clue to get me on the road to recovery.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.|
I migrated from OpenLdap about a year ago. So my install is a migration.
I also recently tried to add a replica. Which prompted me to update the
schema on the master before it would replicate.
|rpm -q 389-ds-base|
|389-ds-base-1.2.11.15-48.el6_6.x86_64
|
|find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25
{} /dev/null \;|
|
|/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC
'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR
caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE X-ORIGIN 'RFC 2247' )
/etc/dirsrv/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-CS-OBERLIN-EDU/schema.bak/00core.ldif:attributeTypes:
( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-CS-OBERLIN-EDU/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
Thanks again,
-Chris
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] How do I modify the entry cache size?
On 02/08/2015 08:23 PM, Chris Mohler wrote:
Thanks for the reply and the link Rich!
dbmon.sh is a handy tool indeed.
I read the instructions and upped my entry cache size to 2gb because I
have enough ram.
Everything went well until
|service dirsrv restart
|
|I Got the following errors:
[06/Feb/2015:10:07:35 -0500] - slapd stopped.
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching
rule [caseIgnoreIA5Match] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching
rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 http://1.2.11.15
B2014.314.1342 starting up
[06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port
7389 for LDAP requests
[06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS
requests
|
|Oddly enough everything appears to be working. Are these messages safe to
ignore?
|
This is definitely not related to the cache size.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.
rpm -q 389-ds-base
find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25 {}
/dev/null \;
|
|Another run of dbmon.sh shows that my entry cache was increased.
|||
|Thanks,
|
|-Chris
|
|
|
On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson rmegg...@redhat.com
mailto:rmegg...@redhat.com wrote:
On 02/07/2015 11:25 AM, Chris Mohler wrote:
Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to
increase the entry cache size
I'm trying to follow the directions here
/usr/lib/mozldap/ldapmodify -D cn=directory manager -w secret -p 389
dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 20971520
Is this the correct way to do this? How do I find out what the
cn=/|database_name is supposed to be?
|/
|/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the
script will tell you what the names of your databases are.
/|
|/
/|Thanks,
|/
/|-Chris
|/
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Upgrade from 3x to 4x cant create first replica.
On 02/09/2015 10:18 AM, Martin Kosek wrote: On 02/07/2015 12:27 AM, Chris Mohler wrote: I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos 6.6. It's currently the only master for my domain. I have about 4k user accounts on here and it's a live system called idm I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. (clients can't auth unless service sssd is restarted multiple times 10 (User not known to the underlying authentication module) I think this is possibly unrelated and the topic for another thread. I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called ipa Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. on the master idm I ran ipa-replica-prepare and transfered the file to the future replica ipa Then I ran the install replica script ipa-replica-install --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg Things went well until it failed [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 133 seconds elapsed Update in progress yet not in progress Update in progress yet not in progress Update in progress yet not in progress [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Please help I'm getting nowhere by myself. Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? Maybe you will see messages like ns-slapd: encoded packet size too big (xx 65536) that are know to pop up more with CentOS 6.6. Hi Martin, Thanks for the reply and help I appreciate it. Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. Good to know. I try to be distro agnostic. I've used Redhat 7.1 then went Solaris, then Ubuntu, Now I'm back for Centos and Fedora. I guess I'm equally uncomfortable with either version. That Said. Is there any reason that I could or should not have a replica on a Fedora 21 server and 2nd replica on a Centos 7.1 later? My understanding is the more the merrier. Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? I tried to setup the replica again just now so I have some fresh logs. From the Dirserv error log [08/Feb/2015:22:14:48 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up [08/Feb/2015:22:14:48 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=cs,dc=oberlin,dc=edu [08/Feb/2015:22:14:50 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [08/Feb/2015:22:14:50 -0500] - Listening on All Interfaces port 636 for LDAPS requests [08/Feb/2015:22:14:50 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - agmt=cn=meToipa.cs.oberlin.edu (ipa:389): Schema replication update failed: Server is unwilling to perform [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Warning: unable to replicate schema to host ipa.cs.oberlin.edu, port 389. Continuing with total update session. [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meToipa.cs.oberlin.edu (ipa:389) To be fair and not duplicate efforts I have had the following error [08/Feb/2015:08:51:26 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 12115968B; We recommend to increase the entry cache size nsslapd-cachememsize. To which I have asked another question how do I change the entry cache size https://www.redhat.com/archives/freeipa-users/2015-February/msg00114.html I now get additional errors which I would guess are possibly related. |[06/Feb/2015:10:07:35 -0500] - slapd stopped. [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] [06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] [06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 http://1.2.11.15/ B2014.314.1342 starting up [06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port 7389 for LDAP requests [06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS requests| | Thanks again for having a look at my problem, -Chris | -- Manage your subscription for the Freeipa-users mailing list:
Re: [Freeipa-users] Upgrade from 3x to 4x cant create first replica.
On 02/09/2015 05:16 PM, Chris Mohler wrote: On 02/09/2015 10:18 AM, Martin Kosek wrote: On 02/07/2015 12:27 AM, Chris Mohler wrote: I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos 6.6. It's currently the only master for my domain. I have about 4k user accounts on here and it's a live system called idm I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. (clients can't auth unless service sssd is restarted multiple times 10 (User not known to the underlying authentication module) I think this is possibly unrelated and the topic for another thread. I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called ipa Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. on the master idm I ran ipa-replica-prepare and transfered the file to the future replica ipa Then I ran the install replica script ipa-replica-install --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg Things went well until it failed [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 133 seconds elapsed Update in progress yet not in progress Update in progress yet not in progress Update in progress yet not in progress [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Please help I'm getting nowhere by myself. Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? Maybe you will see messages like ns-slapd: encoded packet size too big (xx 65536) that are know to pop up more with CentOS 6.6. Hi Martin, Thanks for the reply and help I appreciate it. Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. Good to know. I try to be distro agnostic. I've used Redhat 7.1 then went Solaris, then Ubuntu, Now I'm back for Centos and Fedora. I guess I'm equally uncomfortable with either version. That Said. Is there any reason that I could or should not have a replica on a Fedora 21 server and 2nd replica on a Centos 7.1 later? My understanding is the more the merrier. It should just work. Just note that in case of Fedora Server, these are upstream/Fedora bits which are only tested upstream. So if you for example break something in Fedora 21 (not likely to happen though ;-) and then get the change *replicated* to RHEL production instance, I do not think Red Hat support would be happy with that. Also, if for example upstream releases FreeIPA 4.2, I would not just plug it in your production RHEL instance is it would upgrade all the data for 4.2 level - which should get more downstream testing before Red Hat can rubber stamp it. TLDR; if you are happy with the upstream level of support (this list/IRC/Trac), knock yourself out :-) Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? I tried to setup the replica again just now so I have some fresh logs. From the Dirserv error log [08/Feb/2015:22:14:48 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up [08/Feb/2015:22:14:48 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=cs,dc=oberlin,dc=edu [08/Feb/2015:22:14:50 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [08/Feb/2015:22:14:50 -0500] - Listening on All Interfaces port 636 for LDAPS requests [08/Feb/2015:22:14:50 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - agmt=cn=meToipa.cs.oberlin.edu (ipa:389): Schema replication update failed: Server is unwilling to perform [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Warning: unable to replicate schema to host ipa.cs.oberlin.edu, port 389. Continuing with total update session. [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meToipa.cs.oberlin.edu (ipa:389) To be fair and not duplicate efforts I have had the following error [08/Feb/2015:08:51:26 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 12115968B; We recommend to increase the entry cache size nsslapd-cachememsize. To which I have asked another question how do I change the entry cache size https://www.redhat.com/archives/freeipa-users/2015-February/msg00114.html I now get additional errors which I would guess are possibly related. IMO, they this should not be related (should not break replication). I do not see anything useful in the error log though. Did you also
Re: [Freeipa-users] How do I modify the entry cache size?
On 02/09/2015 08:26 AM, Chris Mohler wrote:
On 02/09/2015 09:48 AM, Rich Megginson wrote:
On 02/08/2015 08:23 PM, Chris Mohler wrote:
Thanks for the reply and the link Rich!
dbmon.sh is a handy tool indeed.
I read the instructions and upped my entry cache size to 2gb because
I have enough ram.
Everything went well until
|service dirsrv restart
|
|I Got the following errors:
[06/Feb/2015:10:07:35 -0500] - slapd stopped.
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching
rule [caseIgnoreIA5Match] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching
rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 http://1.2.11.15
B2014.314.1342 starting up
[06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port
7389 for LDAP requests
[06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS
requests
|
|Oddly enough everything appears to be working. Are these messages safe to
ignore?
|
This is definitely not related to the cache size.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.
rpm -q 389-ds-base
find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25
{} /dev/null \;
|
|Another run of dbmon.sh shows that my entry cache was increased.
|||
|Thanks,
|
|-Chris
|
|
|
On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson rmegg...@redhat.com
mailto:rmegg...@redhat.com wrote:
On 02/07/2015 11:25 AM, Chris Mohler wrote:
Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to
increase the entry cache size
I'm trying to follow the directions here
/usr/lib/mozldap/ldapmodify -D cn=directory manager -w secret -p 389
dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 20971520
Is this the correct way to do this? How do I find out what the
cn=/|database_name is supposed to be?
|/
|/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the
script will tell you what the names of your databases are.
/|
|/
/|Thanks,
|/
/|-Chris
|/
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Thanks again Rich,
I have been having an abundance of issues with my FreeIPA server
lately. I'm not surprised that error is not related. I was not sure as
It has not surfaced in my logs before I changed the entry cache size.
Possibly this will be the clue to get me on the road to recovery.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.|
I migrated from OpenLdap about a year ago. So my install is a
migration. I also recently tried to add a replica. Which prompted me
to update the schema on the master before it would replicate.
What exactly did you do? You should not have migrated the standard
schema from openldap. Did you have to override the definition of 'dc'
for some reason?
|rpm -q 389-ds-base|
|389-ds-base-1.2.11.15-48.el6_6.x86_64
|
|find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25
{} /dev/null \;|
|
|/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC
'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR
caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE X-ORIGIN 'RFC 2247' )
This definition is wrong. Both RFC 2247 and RFC 4519 define 'dc' as
syntax 1.3.6.1.4.1.1466.115.121.1.26 - that is, 7-bit ASCII only. Do you
have some application that requires 8-bit or unicode characters (syntax
1.3.6.1.4.1.1466.115.121.1.15) in domain component names? If it is
absolutely required that dc accepts unicode, then you'll have to change
the matching rules as well, to be unicode compatible: EQUALITY
caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - that is, just get rid
of the IA5.
/etc/dirsrv/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-CS-OBERLIN-EDU/schema.bak/00core.ldif:attributeTypes:
Re: [Freeipa-users] Upgrade from 3x to 4x cant create first replica.
On 02/07/2015 12:27 AM, Chris Mohler wrote: I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos 6.6. It's currently the only master for my domain. I have about 4k user accounts on here and it's a live system called idm I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. (clients can't auth unless service sssd is restarted multiple times 10 (User not known to the underlying authentication module) I think this is possibly unrelated and the topic for another thread. I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called ipa Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. on the master idm I ran ipa-replica-prepare and transfered the file to the future replica ipa Then I ran the install replica script ipa-replica-install --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg Things went well until it failed [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 133 seconds elapsed Update in progress yet not in progress Update in progress yet not in progress Update in progress yet not in progress [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Please help I'm getting nowhere by myself. Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? Maybe you will see messages like ns-slapd: encoded packet size too big (xx 65536) that are know to pop up more with CentOS 6.6. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Trust with Active Directory fails
For Active Directory cross-forest trusts to work, we need following records to be in place: _ldap._tcp.DOMAIN _kerberos._udp.DOMAIN _kerberos._tcp.DOMAIN _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _ldap._tcp.dc._msdcs.DOMAIN _kerberos._udp.dc._msdcs.DOMAIN _kerberos._tcp.dc._msdcs.DOMAIN I've checked with nslookup, and for the IPA subdomain csns.example.com, all the records are in place. For the parent example.com domain, though, the following four records are not found: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._udp.dc._msdcs.example.com Do these need to be manually added to our DNS records? I've never had to manually add an SRV record before. If it matters, we are not using our domain controllers as our DNS servers -- we have separate, dedicated DNS servers in our environment. Thanks, David Guertin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] error install replication
On 02/09/2015 03:31 PM, Dmitri Pal wrote: On 02/09/2015 08:34 AM, alireza baghery wrote: yes try ssh admin@hostname but do not work log secure- Feb 9 15:42:20 ipasrv sshd[13414]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 user=admin Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 user=admin Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:account): Access denied for user admin: 6 (Permission denied) Feb 9 15:42:20 ipasrv sshd[13414]: Failed password for admin from 10.30.160.20 port 52123 ssh2 Feb 9 15:42:20 ipasrv sshd[13415]: fatal: Access denied for user admin by PAM account configuration Do you have HBAC rules? Does admin have the rights to log via SSH? If you changed the default rules it might be that admin is not allowed to log via ssh. Good questions. Also note, that if for some special reasons, you do not want to make admins log in to your FreeIPA servers, you can always pass --skip-conncheck to the replica and go straight to the installation, skipping the firewall check. Of course, no guarantees that the installation won't get stuck or crash because of closed ports in that case. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Trust with Active Directory fails
On Mon, 09 Feb 2015, Guertin, David S. wrote: For Active Directory cross-forest trusts to work, we need following records to be in place: _ldap._tcp.DOMAIN _kerberos._udp.DOMAIN _kerberos._tcp.DOMAIN _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _ldap._tcp.dc._msdcs.DOMAIN _kerberos._udp.dc._msdcs.DOMAIN _kerberos._tcp.dc._msdcs.DOMAIN I've checked with nslookup, and for the IPA subdomain csns.example.com, all the records are in place. For the parent example.com domain, though, the following four records are not found: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._udp.dc._msdcs.example.com Do these need to be manually added to our DNS records? I've never had to manually add an SRV record before. If it matters, we are not using our domain controllers as our DNS servers -- we have separate, dedicated DNS servers in our environment. Can you send me (off-list) logs as described in http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] How do I modify the entry cache size?
On 02/09/2015 11:19 AM, Rich Megginson wrote:
On 02/09/2015 08:26 AM, Chris Mohler wrote:
On 02/09/2015 09:48 AM, Rich Megginson wrote:
On 02/08/2015 08:23 PM, Chris Mohler wrote:
Thanks for the reply and the link Rich!
dbmon.sh is a handy tool indeed.
I read the instructions and upped my entry cache size to 2gb
because I have enough ram.
Everything went well until
|service dirsrv restart
|
|I Got the following errors:
[06/Feb/2015:10:07:35 -0500] - slapd stopped.
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching
rule [caseIgnoreIA5Match] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching
rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 http://1.2.11.15
B2014.314.1342 starting up
[06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port
7389 for LDAP requests
[06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS
requests
|
|Oddly enough everything appears to be working. Are these messages safe to
ignore?
|
This is definitely not related to the cache size.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.
rpm -q 389-ds-base
find /etc/dirsrv -name \*.ldif -exec grep 0.9.2342.19200300.100.1.25
{} /dev/null \;
|
|Another run of dbmon.sh shows that my entry cache was increased.
|||
|Thanks,
|
|-Chris
|
|
|
On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson rmegg...@redhat.com
mailto:rmegg...@redhat.com wrote:
On 02/07/2015 11:25 AM, Chris Mohler wrote:
Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to
increase the entry cache size
I'm trying to follow the directions here
/usr/lib/mozldap/ldapmodify -D cn=directory manager -w secret -p 389
dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 20971520
Is this the correct way to do this? How do I find out what the
cn=/|database_name is supposed to be?
|/
|/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the
script will tell you what the names of your databases are.
/|
|/
/|Thanks,
|/
/|-Chris
|/
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Thanks again Rich,
I have been having an abundance of issues with my FreeIPA server
lately. I'm not surprised that error is not related. I was not sure
as It has not surfaced in my logs before I changed the entry cache
size. Possibly this will be the clue to get me on the road to recovery.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.|
I migrated from OpenLdap about a year ago. So my install is a
migration. I also recently tried to add a replica. Which prompted me
to update the schema on the master before it would replicate.
What exactly did you do? You should not have migrated the standard
schema from openldap. Did you have to override the definition of 'dc'
for some reason?
|rpm -q 389-ds-base|
|389-ds-base-1.2.11.15-48.el6_6.x86_64
|
|find /etc/dirsrv -name \*.ldif -exec grep
0.9.2342.19200300.100.1.25 {} /dev/null \;|
|
|/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC
'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR
caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE X-ORIGIN 'RFC 2247' )
This definition is wrong. Both RFC 2247 and RFC 4519 define 'dc' as
syntax 1.3.6.1.4.1.1466.115.121.1.26 - that is, 7-bit ASCII only. Do
you have some application that requires 8-bit or unicode characters
(syntax 1.3.6.1.4.1.1466.115.121.1.15) in domain component names? If
it is absolutely required that dc accepts unicode, then you'll have to
change the matching rules as well, to be unicode compatible: EQUALITY
caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - that is, just get
rid of the IA5.
/etc/dirsrv/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
Re: [Freeipa-users] User certificates with FreeIPA and another question.
I actually think I can get this going at this time if I can just figure out how to submit a subca csr to dogtag, sign it, and acquire it. Documentation on that seems to be hard to come by, but I'm digging to avoid eating up this thread (and trying to RTFM where possible). I still stand by my request for consulting time if anyone has more intimate knowledge, however if someone can point me in the best direction for getting a openssl based subca's csr submitted, signed, acquired, I think I can get the rest going. Your help would be greatly, greatly appreciated. Chris On Mon, Feb 9, 2015 at 12:18 PM, Christopher Young mexigaba...@gmail.com wrote: Would anyone happen to have any guides on how one could get through this process? I'm a one-man IT shop at the moment, so I'm building up a tremendous amount of infrastructure at once. I'm thinking that the option of creating a subCA with something simple like openssl would be the best option, but figuring out that process in a minimal amount of time is going to be tough. I'm going to try and give myself some reading assignments and push that forward, but if anyone happens to have a good handle on that process/commands/etc. and would be interesting in double a couple of hours of consulting to me, I would be very interested in listening provided we could come up with a reasonable rate/timeframe. If anyone is interested, please contact me directly off-list. Thanks again. These answers/ideas have been most helpful. On Fri, Feb 6, 2015 at 9:30 AM, Martin Kosek mko...@redhat.com wrote: On 02/06/2015 12:53 AM, Christopher Young wrote: Obvious next question: Any plans to implement that functionality or advice on how one might get some level of functionality for this? Would it be possible to create another command-line based openssl CA that could issue these but using IPA as the root CA for those? As for FreeIPA plans, we plan to vastly improve our flexibility to process certificates in next upstream version - FreeIPA 4.2. In next version, one should be able to create other certificate profiles (from FreeIPA default service cert profile) or even subCAs to do what you want. As for current workarounds, you would have to issue and sign a for example NSS or openssl based subCA and then sign user certs there. But I would leave Fraser or Jan to tell if this would be really possible. I'm just trying to provide a solution for situations where we would like to utilize client/user cert authentication for situations like secure apache directory access as well as user VPN certificates. Any advise or ideas are great appreciated. Thanks again! On Thu, Feb 5, 2015 at 4:09 PM, Rob Crittenden rcrit...@redhat.com wrote: Christopher Young wrote: Some of this might be rudimentary, so I apologize if this is answered somewhere, though I've tried to search and have not had much luck... Basically, I would like to be able to issue user certificates (Subject: email=sblblabla@blabla.local) in order to use client SSL security on some things. I'm very new to FreeIPA, but have worked with external CAs in the past for similar requests, however this is my first entry into creating/running a localized CA within an organization. IPA doesn't issue user certificates yet, only server certificates. I was wondering if this is possible via the command line, and if so, how to go about submitting the request and receiving the certificate. Any guidance or assistance would be greatly appreciated! Additionally, just as a matter of cleanliness, is there any way possible to just completely wipe out the existence of a certificate/request from FreeIPA. I have done some trial-and-error and obviously have made mistakes that I'd prefer to clean up after. I've revoked those certs, however the perfectionist in me hates seeing them there. I'm quite certain the answer is 'no', but I thought I would ask anyway. Right, the answer is no. In fact it is a good thing that all certificates are accounted for. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] admin password is always expired
On 02/09/2015 05:35 PM, Roderick Johnstone wrote: Hi I seem to have locked myself out of my ipa admin account (on RHEL 6.6). This is an evaluation instance so not too big a deal, but a good learning experience. I suspect its some changes that I made to the password policy that caused this. The admin account has expired and I'm trying to reset the password like this: # kadmin.local Authenticating as principal root/admin@REALM with password. kadmin.local: change_password admin@REALM Enter password for principal admin@REALM: Re-enter password for principal admin@REALM: Password for admin@REALM changed. kadmin.local: q where REALM is my realm. Then when I try to authenticate as admin: # kinit admin Password for admin@REALM: Password expired. You must change it now. Enter new password: Enter it again: kinit: Password has expired while getting initial credentials and the password is not reset. This is what the password policy looks like at the moment: kadmin.local: get_policy global_policy Policy: global_policy Maximum password life: 86400 Minimum password life: 0 Minimum password length: 8 Minimum number of password character classes: 0 Number of old keys kept: 0 Reference count: 0 Maximum password failures before lockout: 6 Password failure count reset interval: 0 days 00:01:00 Password lockout duration: 0 days 00:10:00 I'm trying to set this back to the defaults in the hope that this allows me to reset the admin password properly, but I'm getting eg: kadmin.local: modify_policy -maxlife 90 days global_policy modify_policy: Plugin does not support the operation while modifying policy global_policy. Am I on the right track to fixing the admin password problem? What am I doing wrong in trying to repair the password policy? Actually when I do the following it looks strange that Policy is set to none, but maybe this is a red herring: kadmin.local: get_principal admin Principal: admin@REALM Expiration date: [never] Last password change: Mon Feb 09 18:28:09 GMT 2015 Password expiration date: Tue May 22 11:59:53 GMT 1906 Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Mon Feb 09 18:28:09 GMT 2015 (kadmind@REALM) Last successful authentication: Mon Feb 09 18:27:00 GMT 2015 Last failed authentication: Mon Feb 09 18:25:24 GMT 2015 Failed password attempts: 0 Number of keys: 4 Key: vno 16, aes256-cts-hmac-sha1-96, Version 5 Key: vno 16, aes128-cts-hmac-sha1-96, Version 5 Key: vno 16, des3-cbc-sha1, Version 5 Key: vno 16, arcfour-hmac, Version 5 MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] Thanks for any help in diagnosing this issue or fixing it. Roderick Johnstone Did you set password expiration for admin manually? The attribute shows that it is 1906. This makes me think that you set your expiration to a big number. However the value rolls over in 2038. So you need to make sure what you set translates to a date before 2038. Why are you using kdamin.local? With IPA it is not supported. There is a bunch of IPA commands that do the same. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Upgrade from 3x to 4x cant create first replica.
On 02/09/2015 11:36 AM, Martin Kosek wrote: On 02/09/2015 05:16 PM, Chris Mohler wrote: On 02/09/2015 10:18 AM, Martin Kosek wrote: On 02/07/2015 12:27 AM, Chris Mohler wrote: I'm having some troubles. I have an older IPA install Version 3.0.0. on Centos 6.6. It's currently the only master for my domain. I have about 4k user accounts on here and it's a live system called idm I'm trying to upgrade to V4.x as I am hoping to fix some issues I am having. (clients can't auth unless service sssd is restarted multiple times 10 (User not known to the underlying authentication module) I think this is possibly unrelated and the topic for another thread. I created a new VM and installed Fedora Server 21 and FreeIPA 4.1.2 it's called ipa Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. on the master idm I ran ipa-replica-prepare and transfered the file to the future replica ipa Then I ran the install replica script ipa-replica-install --setup-ca /home/svradm/replica-info-ipa.cs.oberlin.edu.gpg Things went well until it failed [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 133 seconds elapsed Update in progress yet not in progress Update in progress yet not in progress Update in progress yet not in progress [idm.cs.oberlin.edu] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Please help I'm getting nowhere by myself. Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? Maybe you will see messages like ns-slapd: encoded packet size too big (xx 65536) that are know to pop up more with CentOS 6.6. Hi Martin, Thanks for the reply and help I appreciate it. Good. Also note that we RHEL/CentOS 7.1 will have FreeIPA 4.0+ version baked in, so you can also use that platform if you are used to it. Good to know. I try to be distro agnostic. I've used Redhat 7.1 then went Solaris, then Ubuntu, Now I'm back for Centos and Fedora. I guess I'm equally uncomfortable with either version. That Said. Is there any reason that I could or should not have a replica on a Fedora 21 server and 2nd replica on a Centos 7.1 later? My understanding is the more the merrier. It should just work. Just note that in case of Fedora Server, these are upstream/Fedora bits which are only tested upstream. So if you for example break something in Fedora 21 (not likely to happen though ;-) and then get the change *replicated* to RHEL production instance, I do not think Red Hat support would be happy with that. Also, if for example upstream releases FreeIPA 4.2, I would not just plug it in your production RHEL instance is it would upgrade all the data for 4.2 level - which should get more downstream testing before Red Hat can rubber stamp it. TLDR; if you are happy with the upstream level of support (this list/IRC/Trac), knock yourself out :-) Can you please look on the master you are replicating from and look for errors in /var/log/messages or DS errors log? I tried to setup the replica again just now so I have some fresh logs. From the Dirserv error log [08/Feb/2015:22:14:48 -0500] - 389-Directory/1.2.11.15 B2014.314.1342 starting up [08/Feb/2015:22:14:48 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=cs,dc=oberlin,dc=edu [08/Feb/2015:22:14:50 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [08/Feb/2015:22:14:50 -0500] - Listening on All Interfaces port 636 for LDAPS requests [08/Feb/2015:22:14:50 -0500] - Listening on /var/run/slapd-CS-OBERLIN-EDU.socket for LDAPI requests [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - agmt=cn=meToipa.cs.oberlin.edu (ipa:389): Schema replication update failed: Server is unwilling to perform [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Warning: unable to replicate schema to host ipa.cs.oberlin.edu, port 389. Continuing with total update session. [09/Feb/2015:10:40:30 -0500] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meToipa.cs.oberlin.edu (ipa:389) To be fair and not duplicate efforts I have had the following error [08/Feb/2015:08:51:26 -0500] - WARNING: userRoot: entry cache size 10485760B is less than db size 12115968B; We recommend to increase the entry cache size nsslapd-cachememsize. To which I have asked another question how do I change the entry cache size https://www.redhat.com/archives/freeipa-users/2015-February/msg00114.html I now get additional errors which I would guess are possibly related. IMO, they this should not be related (should not break replication). I do not see anything useful in the error log though. Did you also check /var/log/messages for the errors log
Re: [Freeipa-users] User certificates with FreeIPA and another question.
Would anyone happen to have any guides on how one could get through this process? I'm a one-man IT shop at the moment, so I'm building up a tremendous amount of infrastructure at once. I'm thinking that the option of creating a subCA with something simple like openssl would be the best option, but figuring out that process in a minimal amount of time is going to be tough. I'm going to try and give myself some reading assignments and push that forward, but if anyone happens to have a good handle on that process/commands/etc. and would be interesting in double a couple of hours of consulting to me, I would be very interested in listening provided we could come up with a reasonable rate/timeframe. If anyone is interested, please contact me directly off-list. Thanks again. These answers/ideas have been most helpful. On Fri, Feb 6, 2015 at 9:30 AM, Martin Kosek mko...@redhat.com wrote: On 02/06/2015 12:53 AM, Christopher Young wrote: Obvious next question: Any plans to implement that functionality or advice on how one might get some level of functionality for this? Would it be possible to create another command-line based openssl CA that could issue these but using IPA as the root CA for those? As for FreeIPA plans, we plan to vastly improve our flexibility to process certificates in next upstream version - FreeIPA 4.2. In next version, one should be able to create other certificate profiles (from FreeIPA default service cert profile) or even subCAs to do what you want. As for current workarounds, you would have to issue and sign a for example NSS or openssl based subCA and then sign user certs there. But I would leave Fraser or Jan to tell if this would be really possible. I'm just trying to provide a solution for situations where we would like to utilize client/user cert authentication for situations like secure apache directory access as well as user VPN certificates. Any advise or ideas are great appreciated. Thanks again! On Thu, Feb 5, 2015 at 4:09 PM, Rob Crittenden rcrit...@redhat.com wrote: Christopher Young wrote: Some of this might be rudimentary, so I apologize if this is answered somewhere, though I've tried to search and have not had much luck... Basically, I would like to be able to issue user certificates (Subject: email=sblblabla@blabla.local) in order to use client SSL security on some things. I'm very new to FreeIPA, but have worked with external CAs in the past for similar requests, however this is my first entry into creating/running a localized CA within an organization. IPA doesn't issue user certificates yet, only server certificates. I was wondering if this is possible via the command line, and if so, how to go about submitting the request and receiving the certificate. Any guidance or assistance would be greatly appreciated! Additionally, just as a matter of cleanliness, is there any way possible to just completely wipe out the existence of a certificate/request from FreeIPA. I have done some trial-and-error and obviously have made mistakes that I'd prefer to clean up after. I've revoked those certs, however the perfectionist in me hates seeing them there. I'm quite certain the answer is 'no', but I thought I would ask anyway. Right, the answer is no. In fact it is a good thing that all certificates are accounted for. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Heads up - FC20 softhsm -2.0.0b1-8 rpm from mkosek/freeipa copr appears to be broken
To save a day of torture to those of you still on FC20 and using mkosek-freeipa copr repo - it appears that the package ( http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-20-x86_64/softhsm-2.0.0b1-8.fc20/softhsm-2.0.0b1-8.fc20.x86_64.rpm) is somehow broken. Once installed, you get Error: Could not load the library. no matter what you do with softhsm2-utll. You will also not going to be able to start/restart the ipa service because DNS is not functional. I have rebuilt the rpm from the source rpm and things seem to be working. Hope this helps someone to not have a day of hair pulling. You have been warned :-) -M -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] How do I modify the entry cache size?
Rich Megginson wrote:
On 02/09/2015 12:13 PM, Chris Mohler wrote:
On 02/09/2015 11:19 AM, Rich Megginson wrote:
On 02/09/2015 08:26 AM, Chris Mohler wrote:
On 02/09/2015 09:48 AM, Rich Megginson wrote:
On 02/08/2015 08:23 PM, Chris Mohler wrote:
Thanks for the reply and the link Rich!
dbmon.sh is a handy tool indeed.
I read the instructions and upped my entry cache size to 2gb
because I have enough ram.
Everything went well until
|service dirsrv restart
|
|I Got the following errors:
[06/Feb/2015:10:07:35 -0500] - slapd stopped.
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY
matching rule [caseIgnoreIA5Match] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR
matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the
syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15
http://1.2.11.15 B2014.314.1342 starting up
[06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All
Interfaces port 7389 for LDAP requests
[06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for
LDAPS requests
|
|Oddly enough everything appears to be working. Are these messages safe
to ignore?
|
This is definitely not related to the cache size.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.
rpm -q 389-ds-base
find /etc/dirsrv -name \*.ldif -exec grep
0.9.2342.19200300.100.1.25 {} /dev/null \;
|
|Another run of dbmon.sh shows that my entry cache was increased.
|||
|Thanks,
|
|-Chris
|
|
|
On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson
rmegg...@redhat.com mailto:rmegg...@redhat.com wrote:
On 02/07/2015 11:25 AM, Chris Mohler wrote:
Hi Everyone. I'm trying to troubleshoot some issues I'm having. I
want to increase the entry cache size
I'm trying to follow the directions here
/usr/lib/mozldap/ldapmodify -D cn=directory manager -w secret -p
389
dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 20971520
Is this the correct way to do this? How do I find out what the
cn=/|database_name is supposed to be?
|/
|/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the
script will tell you what the names of your databases are.
/|
|/
/|Thanks,
|/
/|-Chris
|/
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Thanks again Rich,
I have been having an abundance of issues with my FreeIPA server
lately. I'm not surprised that error is not related. I was not sure
as It has not surfaced in my logs before I changed the entry cache
size. Possibly this will be the clue to get me on the road to recovery.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.|
I migrated from OpenLdap about a year ago. So my install is a
migration. I also recently tried to add a replica. Which prompted me
to update the schema on the master before it would replicate.
What exactly did you do? You should not have migrated the standard
schema from openldap. Did you have to override the definition of
'dc' for some reason?
|rpm -q 389-ds-base|
|389-ds-base-1.2.11.15-48.el6_6.x86_64
|
|find /etc/dirsrv -name \*.ldif -exec grep
0.9.2342.19200300.100.1.25 {} /dev/null \;|
|
|/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC
'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR
caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE X-ORIGIN 'RFC 2247' )
This definition is wrong. Both RFC 2247 and RFC 4519 define 'dc' as
syntax 1.3.6.1.4.1.1466.115.121.1.26 - that is, 7-bit ASCII only. Do
you have some application that requires 8-bit or unicode characters
(syntax 1.3.6.1.4.1.1466.115.121.1.15) in domain component names? If
it is absolutely required that dc accepts unicode, then you'll have
to change the matching rules as well, to be unicode compatible:
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - that is,
just get rid of the IA5.
Re: [Freeipa-users] Real-time replication status (RFE)?
For sure Rob. It's a dirty hack to get the information that we desperately needed at one point. We had a pretty severe issue with our IPA servers a while back which was eventually solved by reinstalling all but the initial IPA server, deleting the old replication agreements and building the new ones back up. This page was of high value at that time. It's still useful for an occasional check of the status. D -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: 06 February 2015 14:06 To: Innes, Duncan; Baird, Josh; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Real-time replication status (RFE)? Innes, Duncan wrote: Check: https://gist.github.com/duncaninnes/c91985822be9782df581 which contains 2 scripts based on: http://directory.fedoraproject.org/docs/389ds/howto/howto-replicationm on itoring.html I just expanded it to cope with a list of servers, then version 2 sorts by last end, last start, hostname. This version allows me to see more clearly if a certain replication is out of date. Could have done a sort by column and added a refresh button, or automatic refresh, but that wasn't the immediate aim. Since then it's just stuck, so could do with some love from any suitably minded persons. It also doesn't gracefully handle situations where one server in the list is offline, or taking too long to respond. Both scripts are put in /var/www/cgi-bin on one of my IPA servers, and accessed via: https://ipa01.example.com/cgi-bin/monitor2.pl for example. Not sure if I modified the httpd configs - it's a while ago that I sorted it out. HTH Duncan We try to avoid using Directory Manager as much as possible which is one of the reasons we haven't done something like this already. I'd definitely recommend using startTLS for your bind, at a minimum. The issue starts with the fact that we don't have a hostgroup consisting of all IPA masters maintained automatically so there is no easy way to do delegation. You could do this manually if you wanted though, something like: # ipa hostgroup-add ipamasters --desc='Manual list of IPA masters' # ipa hostgroup-add-member --hosts=ipa1.example.com ipamasters # ipa hostgroup-add-member --hosts=ipa2.example.com ipamasters Now create a role that with a privilege to be able to read replication agreements (and add and delete them too, so be aware). # ipa role-add ipamasters --desc='IPA Masters' # ipa role-add-privilege --privileges='Replication Administrators' ipamasters # ipa role-add-member --hostgroup=ipamasters ipamasters You can test this with: # kinit -kt /etc/krb5.keytab # ldapsearch -Y GSSAPI -b 'cn=mapping tree,cn=config' '(objectclass=nsDS5ReplicationAgreement)' You'd just need to the ipamasters hostgroup up-to-date, and considering that this list probably stabilizes over time, shouldn't be a ton of effort. rob -Original Message- From: Baird, Josh [mailto:jba...@follett.com] Sent: 05 February 2015 17:08 To: Innes, Duncan; Rob Crittenden; freeipa-users@redhat.com Subject: RE: [Freeipa-users] Real-time replication status (RFE)? That would be great, thanks! Josh -Original Message- From: Innes, Duncan [mailto:duncan.in...@virginmoney.com] Sent: Thursday, February 05, 2015 11:34 AM To: Rob Crittenden; Baird, Josh; freeipa-users@redhat.com Subject: RE: [Freeipa-users] Real-time replication status (RFE)? The screen mockup in that ticket is based on a Perl script that I stuck in cgi-bin to pull just those stats off each IPA server I have and display them. Can share the code if you're interested. D -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Rob Crittenden Sent: 05 February 2015 14:19 To: Baird, Josh; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Real-time replication status (RFE)? Baird, Josh wrote: Hi, I'm looking for an easy way to validate that all replication agreements are functioning correctly between all of my IPA masters and replicas. I am aware that I can run 'ipa-replica-manage list -v' from each IPA master, but I was looking for something more centralized that could give me a replication health report for all masters/replicas. Ideally, this type of feature would be exposed in the UI and would also include information or insight into the status of any IPA - AD trust relationships. Am I missing a feature that already exists? If not, is there something like this on the IPA roadmap? This is being tracked in https://fedorahosted.org/freeipa/ticket/4390 It depends on some other work being done first. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This
Re: [Freeipa-users] error install replication
Did you try the ssh admin@`hostname` command? It should show if ssh to admin via SSSDFreeIPA really works. On 02/09/2015 11:18 AM, alireza baghery wrote: account admin recognize and show uid gid and groups On Feb 9, 2015 1:42 PM, Martin Kosek mko...@redhat.com wrote: Ok. When on the server, does # id admin or ssh admin@`hostname` work? Maybe it does not recognize the admin user. On 02/09/2015 09:29 AM, alireza baghery wrote: ipasrv# Service SSSD status sssd is runing nevertheless i restart service sssd but problem do not solved On Mon, Feb 9, 2015 at 11:19 AM, Martin Kosek mko...@redhat.com wrote: On 02/09/2015 07:42 AM, alireza baghery wrote: i check on both server ssh each other's name and ssh successful and resolve name was also correct on each server but i can not login with user admin from ipareplica via ssh (root@ipareplica]# ssh admin@ipasrv === failed) [root@ipareplica ~]# ssh ipasrv root@ipasrv's password: Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 =log /var/secure Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from 10.30.160.20 port 52110 ssh2 Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session opened for user root by (uid=0) = [root@ipasrv ~]# ssh ipareplica root@ipareplica's password: Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 == [root@ipareplica ~]# nslookup ipasrv Server: 10.30.160.19 Address:10.30.160.19#53 Name: ipasrv Address: 10.30.160.19 [root@ipasrv ~]# nslookup ipareplica Server: 127.0.0.1 Address:127.0.0.1#53 Name: ipareplica Address: 10.30.160.20 = Ok, so ssh is running, you can log in with root. I think that by 99% chance, your SSSD service is not running on the IPA server. Please check if this is the case and if yes, please try to (re)start it. If that helped, it would be also useful to see *why* the SSSD is not running (crash, misconfiguration, ...) Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] error install replication
yes try ssh admin@hostname but do not work log secure- Feb 9 15:42:20 ipasrv sshd[13414]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 user=admin Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 user=admin Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:account): Access denied for user admin: 6 (Permission denied) Feb 9 15:42:20 ipasrv sshd[13414]: Failed password for admin from 10.30.160.20 port 52123 ssh2 Feb 9 15:42:20 ipasrv sshd[13415]: fatal: Access denied for user admin by PAM account configuration On Mon, Feb 9, 2015 at 3:20 PM, Martin Kosek mko...@redhat.com wrote: Did you try the ssh admin@`hostname` command? It should show if ssh to admin via SSSDFreeIPA really works. On 02/09/2015 11:18 AM, alireza baghery wrote: account admin recognize and show uid gid and groups On Feb 9, 2015 1:42 PM, Martin Kosek mko...@redhat.com wrote: Ok. When on the server, does # id admin or ssh admin@`hostname` work? Maybe it does not recognize the admin user. On 02/09/2015 09:29 AM, alireza baghery wrote: ipasrv# Service SSSD status sssd is runing nevertheless i restart service sssd but problem do not solved On Mon, Feb 9, 2015 at 11:19 AM, Martin Kosek mko...@redhat.com wrote: On 02/09/2015 07:42 AM, alireza baghery wrote: i check on both server ssh each other's name and ssh successful and resolve name was also correct on each server but i can not login with user admin from ipareplica via ssh (root@ipareplica]# ssh admin@ipasrv === failed) [root@ipareplica ~]# ssh ipasrv root@ipasrv's password: Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 =log /var/secure Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from 10.30.160.20 port 52110 ssh2 Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session opened for user root by (uid=0) = [root@ipasrv ~]# ssh ipareplica root@ipareplica's password: Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 == [root@ipareplica ~]# nslookup ipasrv Server: 10.30.160.19 Address:10.30.160.19#53 Name: ipasrv Address: 10.30.160.19 [root@ipasrv ~]# nslookup ipareplica Server: 127.0.0.1 Address:127.0.0.1#53 Name: ipareplica Address: 10.30.160.20 = Ok, so ssh is running, you can log in with root. I think that by 99% chance, your SSSD service is not running on the IPA server. Please check if this is the case and if yes, please try to (re)start it. If that helped, it would be also useful to see *why* the SSSD is not running (crash, misconfiguration, ...) Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] error install replication
account admin recognize and show uid gid and groups On Feb 9, 2015 1:42 PM, Martin Kosek mko...@redhat.com wrote: Ok. When on the server, does # id admin or ssh admin@`hostname` work? Maybe it does not recognize the admin user. On 02/09/2015 09:29 AM, alireza baghery wrote: ipasrv# Service SSSD status sssd is runing nevertheless i restart service sssd but problem do not solved On Mon, Feb 9, 2015 at 11:19 AM, Martin Kosek mko...@redhat.com wrote: On 02/09/2015 07:42 AM, alireza baghery wrote: i check on both server ssh each other's name and ssh successful and resolve name was also correct on each server but i can not login with user admin from ipareplica via ssh (root@ipareplica]# ssh admin@ipasrv === failed) [root@ipareplica ~]# ssh ipasrv root@ipasrv's password: Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 =log /var/secure Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from 10.30.160.20 port 52110 ssh2 Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session opened for user root by (uid=0) = [root@ipasrv ~]# ssh ipareplica root@ipareplica's password: Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 == [root@ipareplica ~]# nslookup ipasrv Server: 10.30.160.19 Address:10.30.160.19#53 Name: ipasrv Address: 10.30.160.19 [root@ipasrv ~]# nslookup ipareplica Server: 127.0.0.1 Address:127.0.0.1#53 Name: ipareplica Address: 10.30.160.20 = Ok, so ssh is running, you can log in with root. I think that by 99% chance, your SSSD service is not running on the IPA server. Please check if this is the case and if yes, please try to (re)start it. If that helped, it would be also useful to see *why* the SSSD is not running (crash, misconfiguration, ...) Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] error install replication
Ok. When on the server, does # id admin or ssh admin@`hostname` work? Maybe it does not recognize the admin user. On 02/09/2015 09:29 AM, alireza baghery wrote: ipasrv# Service SSSD status sssd is runing nevertheless i restart service sssd but problem do not solved On Mon, Feb 9, 2015 at 11:19 AM, Martin Kosek mko...@redhat.com wrote: On 02/09/2015 07:42 AM, alireza baghery wrote: i check on both server ssh each other's name and ssh successful and resolve name was also correct on each server but i can not login with user admin from ipareplica via ssh (root@ipareplica]# ssh admin@ipasrv === failed) [root@ipareplica ~]# ssh ipasrv root@ipasrv's password: Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 =log /var/secure Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from 10.30.160.20 port 52110 ssh2 Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session opened for user root by (uid=0) = [root@ipasrv ~]# ssh ipareplica root@ipareplica's password: Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 == [root@ipareplica ~]# nslookup ipasrv Server: 10.30.160.19 Address:10.30.160.19#53 Name: ipasrv Address: 10.30.160.19 [root@ipasrv ~]# nslookup ipareplica Server: 127.0.0.1 Address:127.0.0.1#53 Name: ipareplica Address: 10.30.160.20 = Ok, so ssh is running, you can log in with root. I think that by 99% chance, your SSSD service is not running on the IPA server. Please check if this is the case and if yes, please try to (re)start it. If that helped, it would be also useful to see *why* the SSSD is not running (crash, misconfiguration, ...) Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] How do I modify the entry cache size?
On 02/09/2015 12:13 PM, Chris Mohler wrote:
On 02/09/2015 11:19 AM, Rich Megginson wrote:
On 02/09/2015 08:26 AM, Chris Mohler wrote:
On 02/09/2015 09:48 AM, Rich Megginson wrote:
On 02/08/2015 08:23 PM, Chris Mohler wrote:
Thanks for the reply and the link Rich!
dbmon.sh is a handy tool indeed.
I read the instructions and upped my entry cache size to 2gb
because I have enough ram.
Everything went well until
|service dirsrv restart
|
|I Got the following errors:
[06/Feb/2015:10:07:35 -0500] - slapd stopped.
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the EQUALITY matching
rule [caseIgnoreIA5Match] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] attr_syntax_create - Error: the SUBSTR matching
rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
[06/Feb/2015:10:07:37 -0500] - 389-Directory/1.2.11.15 http://1.2.11.15
B2014.314.1342 starting up
[06/Feb/2015:10:07:37 -0500] - slapd started. Listening on All Interfaces port
7389 for LDAP requests
[06/Feb/2015:10:07:37 -0500] - Listening on All Interfaces port 7390 for LDAPS
requests
|
|Oddly enough everything appears to be working. Are these messages safe to
ignore?
|
This is definitely not related to the cache size.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.
rpm -q 389-ds-base
find /etc/dirsrv -name \*.ldif -exec grep
0.9.2342.19200300.100.1.25 {} /dev/null \;
|
|Another run of dbmon.sh shows that my entry cache was increased.
|||
|Thanks,
|
|-Chris
|
|
|
On Sun, Feb 8, 2015 at 5:58 PM, Rich Megginson
rmegg...@redhat.com mailto:rmegg...@redhat.com wrote:
On 02/07/2015 11:25 AM, Chris Mohler wrote:
Hi Everyone. I'm trying to troubleshoot some issues I'm having. I want to
increase the entry cache size
I'm trying to follow the directions here
/usr/lib/mozldap/ldapmodify -D cn=directory manager -w secret -p 389
dn: cn=/|database_name|/, cn=ldbm database, cn=plugins, cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 20971520
Is this the correct way to do this? How do I find out what the
cn=/|database_name is supposed to be?
|/
|/see /|https://github.com/richm/scripts/wiki/dbmon.sh - the
script will tell you what the names of your databases are.
/|
|/
/|Thanks,
|/
/|-Chris
|/
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Thanks again Rich,
I have been having an abundance of issues with my FreeIPA server
lately. I'm not surprised that error is not related. I was not sure
as It has not surfaced in my logs before I changed the entry cache
size. Possibly this will be the clue to get me on the road to recovery.
|Not sure what the problem is - looks like something has done an
override of the standard schema definition of dc.
http://tools.ietf.org/html/rfc4519 defines it with syntax
1.3.6.1.4.1.1466.115.121.1.26.|
I migrated from OpenLdap about a year ago. So my install is a
migration. I also recently tried to add a replica. Which prompted me
to update the schema on the master before it would replicate.
What exactly did you do? You should not have migrated the standard
schema from openldap. Did you have to override the definition of
'dc' for some reason?
|rpm -q 389-ds-base|
|389-ds-base-1.2.11.15-48.el6_6.x86_64
|
|find /etc/dirsrv -name \*.ldif -exec grep
0.9.2342.19200300.100.1.25 {} /dev/null \;|
|
|/etc/dirsrv/slapd-PKI-IPA/schema.bak/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-PKI-IPA/schema/05rfc2247.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) DESC
'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR
caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE X-ORIGIN 'RFC 2247' )
This definition is wrong. Both RFC 2247 and RFC 4519 define 'dc' as
syntax 1.3.6.1.4.1.1466.115.121.1.26 - that is, 7-bit ASCII only. Do
you have some application that requires 8-bit or unicode characters
(syntax 1.3.6.1.4.1.1466.115.121.1.15) in domain component names? If
it is absolutely required that dc accepts unicode, then you'll have
to change the matching rules as well, to be unicode compatible:
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - that is,
just get rid of the IA5.
/etc/dirsrv/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME (
[Freeipa-users] admin password is always expired
Hi I seem to have locked myself out of my ipa admin account (on RHEL 6.6). This is an evaluation instance so not too big a deal, but a good learning experience. I suspect its some changes that I made to the password policy that caused this. The admin account has expired and I'm trying to reset the password like this: # kadmin.local Authenticating as principal root/admin@REALM with password. kadmin.local: change_password admin@REALM Enter password for principal admin@REALM: Re-enter password for principal admin@REALM: Password for admin@REALM changed. kadmin.local: q where REALM is my realm. Then when I try to authenticate as admin: # kinit admin Password for admin@REALM: Password expired. You must change it now. Enter new password: Enter it again: kinit: Password has expired while getting initial credentials and the password is not reset. This is what the password policy looks like at the moment: kadmin.local: get_policy global_policy Policy: global_policy Maximum password life: 86400 Minimum password life: 0 Minimum password length: 8 Minimum number of password character classes: 0 Number of old keys kept: 0 Reference count: 0 Maximum password failures before lockout: 6 Password failure count reset interval: 0 days 00:01:00 Password lockout duration: 0 days 00:10:00 I'm trying to set this back to the defaults in the hope that this allows me to reset the admin password properly, but I'm getting eg: kadmin.local: modify_policy -maxlife 90 days global_policy modify_policy: Plugin does not support the operation while modifying policy global_policy. Am I on the right track to fixing the admin password problem? What am I doing wrong in trying to repair the password policy? Actually when I do the following it looks strange that Policy is set to none, but maybe this is a red herring: kadmin.local: get_principal admin Principal: admin@REALM Expiration date: [never] Last password change: Mon Feb 09 18:28:09 GMT 2015 Password expiration date: Tue May 22 11:59:53 GMT 1906 Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Mon Feb 09 18:28:09 GMT 2015 (kadmind@REALM) Last successful authentication: Mon Feb 09 18:27:00 GMT 2015 Last failed authentication: Mon Feb 09 18:25:24 GMT 2015 Failed password attempts: 0 Number of keys: 4 Key: vno 16, aes256-cts-hmac-sha1-96, Version 5 Key: vno 16, aes128-cts-hmac-sha1-96, Version 5 Key: vno 16, des3-cbc-sha1, Version 5 Key: vno 16, arcfour-hmac, Version 5 MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] Thanks for any help in diagnosing this issue or fixing it. Roderick Johnstone -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] error install replication
On 02/09/2015 08:34 AM, alireza baghery wrote: yes try ssh admin@hostname but do not work log secure- Feb 9 15:42:20 ipasrv sshd[13414]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 user=admin Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 user=admin Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:account): Access denied for user admin: 6 (Permission denied) Feb 9 15:42:20 ipasrv sshd[13414]: Failed password for admin from 10.30.160.20 port 52123 ssh2 Feb 9 15:42:20 ipasrv sshd[13415]: fatal: Access denied for user admin by PAM account configuration Do you have HBAC rules? Does admin have the rights to log via SSH? If you changed the default rules it might be that admin is not allowed to log via ssh. On Mon, Feb 9, 2015 at 3:20 PM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: Did you try the ssh admin@`hostname` command? It should show if ssh to admin via SSSDFreeIPA really works. On 02/09/2015 11:18 AM, alireza baghery wrote: account admin recognize and show uid gid and groups On Feb 9, 2015 1:42 PM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: Ok. When on the server, does # id admin or ssh admin@`hostname` work? Maybe it does not recognize the admin user. On 02/09/2015 09:29 AM, alireza baghery wrote: ipasrv# Service SSSD status sssd is runing nevertheless i restart service sssd but problem do not solved On Mon, Feb 9, 2015 at 11:19 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 02/09/2015 07:42 AM, alireza baghery wrote: i check on both server ssh each other's name and ssh successful and resolve name was also correct on each server but i can not login with user admin from ipareplica via ssh (root@ipareplica]# ssh admin@ipasrv === failed) [root@ipareplica ~]# ssh ipasrv root@ipasrv's password: Last login: Mon Feb 9 09:49:54 2015 from 10.30.160.20 =log /var/secure Feb 9 09:50:29 ipasrv sshd[12076]: Accepted password for root from 10.30.160.20 port 52110 ssh2 Feb 9 09:50:29 ipasrv sshd[12076]: pam_unix(sshd:session): session opened for user root by (uid=0) = [root@ipasrv ~]# ssh ipareplica root@ipareplica's password: Last login: Mon Feb 9 09:50:20 2015 from 10.30.160.19 == [root@ipareplica ~]# nslookup ipasrv Server: 10.30.160.19 Address:10.30.160.19#53 Name: ipasrv Address: 10.30.160.19 [root@ipasrv ~]# nslookup ipareplica Server: 127.0.0.1 Address:127.0.0.1#53 Name: ipareplica Address: 10.30.160.20 = Ok, so ssh is running, you can log in with root. I think that by 99% chance, your SSSD service is not running on the IPA server. Please check if this is the case and if yes, please try to (re)start it. If that helped, it would be also useful to see *why* the SSSD is not running (crash, misconfiguration, ...) Martin -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] error install replication
thanks On Mon, Feb 9, 2015 at 6:42 PM, Martin Kosek mko...@redhat.com wrote: On 02/09/2015 03:31 PM, Dmitri Pal wrote: On 02/09/2015 08:34 AM, alireza baghery wrote: yes try ssh admin@hostname but do not work log secure- Feb 9 15:42:20 ipasrv sshd[13414]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 user=admin Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.30.160.20 user=admin Feb 9 15:42:20 ipasrv sshd[13414]: pam_sss(sshd:account): Access denied for user admin: 6 (Permission denied) Feb 9 15:42:20 ipasrv sshd[13414]: Failed password for admin from 10.30.160.20 port 52123 ssh2 Feb 9 15:42:20 ipasrv sshd[13415]: fatal: Access denied for user admin by PAM account configuration Do you have HBAC rules? Does admin have the rights to log via SSH? If you changed the default rules it might be that admin is not allowed to log via ssh. Good questions. Also note, that if for some special reasons, you do not want to make admins log in to your FreeIPA servers, you can always pass --skip-conncheck to the replica and go straight to the installation, skipping the firewall check. Of course, no guarantees that the installation won't get stuck or crash because of closed ports in that case. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
