date:20150408

On 04/07/2015 11:29 PM, Dmitri Pal wrote:
On 04/07/2015 03:04 PM, Natxo Asenjo wrote:
hi,

On Fri, Apr 3, 2015 at 4:41 PM, Dmitri Pal d...@redhat.com
mailto:d...@redhat.com wrote:

On 04/03/2015 09:46 AM, Brian Topping wrote:
On Apr 3, 2015, at 6:48 AM, Tamas Papptom...@martos.bme.hu
mailto:tom...@martos.bme.hu wrote:

hi All,

I have CentOS 6.6 server and want to upgrade to 7.1.

What is the upgrade path, can I do it directly or first I need to make
it to 3.3?
Also is there any known issue I should expect with workarounds?
I just did this yesterday, so here's my experience. If you have a simple
single-server installation with no custom LDAP DIT modifications, you should
find yum upgrade does the right thing.

If you do have DIT mods, you should ask yourself why they are there and
whether the data will still be accessible after the ACLs are changed. In my
case, I had Postfix using a LDAP hash and mail delivery stopped working
(although the domain data was still there just fine).

Note that the ACLs will propagate from the 4.1 server to your 3.0 if
they are replicated. To be safe, back up all replicas (snapshot or whatnot)
before the first upgrade and if you decide to restore any of them, be sure
everything is shut down and restore all of them to avoid 4.x schema
contaminating 3.0 as they come up.

The general recommendation for 3.3 - 4.1 migration is to start
introducing 4.1 replicas into your 3.3 environment and then turn
your 3.3 replicas off. Do not forget to install the CA component
with one of your 4.1 replicas before removing all the 3.3
instanced with CAs. With this procedure you would also need to
move the CRL generation and cert tracking.

See details in migration section

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#migrating-ipa-proc

Will this excellent documentation work too on the migration from 3.0x (rhel
6) to 4.1.x (rhel 7.1)?

I will be migrating the coming months to 7.1 or 7.2 (whichever is the current
stable then), so just wondering.

Yes, though it is recommended to get to the latest 6.x first before you start
introducing 7.x replicas.

Strongly recommended I would say. Before adding RHEL-7.1 replica, please update
to RHEL-6.6 + all it's z-streams to avoid compatibility issues in Directory
Server or bind-dyndb-ldap if you are using DNS forward zones.

HTH,
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] Slow logins on FreeIPA 4.1.2 (F21)

2015-04-08 Thread Martin (Lists)

Am 08.04.2015 um 10:27 schrieb Jakub Hrozek:
 Can you run:
 KRB5_TRACE=/dev/stderr kinit yourprinc@YOUR.REALM

 So that we can compare with the krb5_child.log you sent earlier? I
 wonder if SSSD talks to a KDC that is slower or far away from your
 client..

This is my trace from kinit:

[2422] 1428482081.62208: AS key obtained for encrypted timestamp:
aes256-cts/61D1
[2422] 1428482081.62288: Encrypted timestamp (for 1428482081.868994):
plain ***, encrypted ***
[2422] 1428482081.62328: Preauth module encrypted_timestamp (2) (real)
returned: 0/Success
[2422] 1428482081.62342: Produced preauth for next request: 133, 2
[2422] 1428482081.62379: Sending request (265 bytes) to MITTELERDE.DE
[2422] 1428482081.62484: Sending initial UDP request to dgram 1.2.3.4:88
[2422] 1428482081.201814: Received answer (740 bytes) from dgram 1.2.3.4:88
[2422] 1428482081.201872: Response was from master KDC
[2422] 1428482081.201905: Processing preauth types: 19
[2422] 1428482081.201914: Selected etype info: etype aes256-cts, salt
***, params 
[2422] 1428482081.201920: Produced preauth for next request: (empty)
[2422] 1428482081.201929: AS key determined by preauth: aes256-cts/61D1
[2422] 1428482081.201973: Decrypted AS reply; session key is:
aes256-cts/C464
[2422] 1428482081.201991: FAST negotiation: available
[2422] 1428482081.202014: Initializing KEYRING:persistent:0:0 with
default princ fr...@mittelerde.de
[2422] 1428482081.202058: Removing fr...@mittelerde.de -
krbtgt/mittelerde...@mittelerde.de from KEYRING:persistent:0:0
[2422] 1428482081.202065: Storing fr...@mittelerde.de -
krbtgt/mittelerde...@mittelerde.de in KEYRING:persistent:0:0
[2422] 1428482081.202110: Storing config in KEYRING:persistent:0:0 for
krbtgt/mittelerde...@mittelerde.de: fast_avail: yes
[2422] 1428482081.202126: Removing fr...@mittelerde.de -
krb5_ccache_conf_data/fast_avail/krbtgt\/MITTELERDE.DE\@MITTELERDE.DE@X-CACHECONF:
from KEYRING:persistent:0:0
[2422] 1428482081.202133: Storing fr...@mittelerde.de -
krb5_ccache_conf_data/fast_avail/krbtgt\/MITTELERDE.DE\@MITTELERDE.DE@X-CACHECONF:
in KEYRING:persistent:0:0
[2422] 1428482081.202166: Storing config in KEYRING:persistent:0:0 for
krbtgt/mittelerde...@mittelerde.de: pa_type: 2
[2422] 1428482081.202177: Removing fr...@mittelerde.de -
krb5_ccache_conf_data/pa_type/krbtgt\/MITTELERDE.DE\@MITTELERDE.DE@X-CACHECONF:
from
KEYRING:persistent:0:0  

   

[2422] 1428482081.202184: Storing fr...@mittelerde.de -
krb5_ccache_conf_data/pa_type/krbtgt\/MITTELERDE.DE\@MITTELERDE.DE@X-CACHECONF:
in
KEYRING:persistent:0:0  

  


Most of the host can only communicate in the local net, which has not
that much hosts (10). The wired ones are connected via GBit Network,
wireless it is up to 150MBit. Server is a Xeon E3-1225 with 8GB Mem. All
Systems have Fedora 21 installed

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

[Freeipa-users] Accident upgrade 3.3 to 4.1

Hello!
We used have a geo-replicated IPA with RHEL 7.0, and on one site ipa servers 
was upgraded by mistake to RHEL 7.1 (ipa-server-4.1.0-18.el7_1.3.x86_64).
Now it is broken globally, in logs I see these:

[08/Apr/2015:13:06:47 +0600] NSACLPlugin - ACL PARSE ERR(rv=-5): 
(targetattr=ipaProtectedOperation;write_keys
[08/Apr/2015:13:06:47 +0600] NSACLPlugin - __aclp__init_targetattr: targetattr 
ipaProtectedOperation;write_keys does not exist in schema. Please add 
attributeTypes ipaProtectedOperation;write_keys to schema if necessary.

What can I do to fix this catastrophe, or it is fatal?
As it seems from the client servers, hbac is not working at all, maybe all 
other things as well :(

With best regards,
Alexander Frolushkin





?? ?  ? ? ? ??? ?? ???, 
??? ??? ??. ? ? ? ???  
??, ??? ?? ?   ???  ???-, ? 
?.  ?? ?? ??? ? ?, ?? ?, ?, 
??? ??? ??? ?? ? ??? ??? ? ? ? 
?.  ??  ??? ? , ??, ??? 
 ??? ??  ? ??? ??  ??  ? ? 
? ? ??? ? ? ??.

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. The 
contents may not be disclosed or used by anyone other than the addressee. If 
you are not the intended recipient(s), any use, disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. If you have received this communication in 
error please notify us immediately by responding to this email and then delete 
the e-mail and all attachments and any copies thereof.

(c)20mf50
-- 
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] Accident upgrade 3.3 to 4.1

-Original Message-
From: Martin Kosek [mailto:mko...@redhat.com]
Sent: Wednesday, April 08, 2015 4:04 PM
To: Alexander Frolushkin (SIB); freeipa-users@redhat.com; Ludwig Krispenz; 
Thierry Bordaz
Subject: Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

On 04/08/2015 11:52 AM, Alexander Frolushkin wrote:
 Hello!
 We used have a geo-replicated IPA with RHEL 7.0, and on one site ipa servers 
 was upgraded by mistake to RHEL 7.1 (ipa-server-4.1.0-18.el7_1.3.x86_64).
 Now it is broken globally, in logs I see these:

 [08/Apr/2015:13:06:47 +0600] NSACLPlugin - ACL PARSE ERR(rv=-5):
 (targetattr=ipaProtectedOperation;write_keys
 [08/Apr/2015:13:06:47 +0600] NSACLPlugin - __aclp__init_targetattr: 
 targetattr ipaProtectedOperation;write_keys does not exist in schema. 
 Please add attributeTypes ipaProtectedOperation;write_keys to schema if 
 necessary.

 What can I do to fix this catastrophe, or it is fatal?
 As it seems from the client servers, hbac is not working at all, maybe
 all other things as well :(

 With best regards,
 Alexander Frolushkin

AFAIK, this particular error message should not be fatal to the function and 
new ACI should just be ignored. Maybe the new schema did not replicate 
properly. Do you see other DS errors? (CCing DS guys)

Non-working HBAC is also strange, SSSD developers will want logs to analyze, 
see https://fedorahosted.org/sssd/wiki/Troubleshooting

In any case, upgrade from 3.3 to 4.1 should just work, you just need to have a 
recent enough RHEL-6 servers - at least RHEL-6.6+z-streams.

Please note, we currently have a three servers with IPA 4.1.0, and 13 servers 
with IPA 3.3.3 working simultaneously.
Also about hbac:

[hbac_eval_user_element] (0x0080): Parse error on [cn=system: read replication 
agreements+nsuniqueid=..,cn=permissions,cn=pbac,dc=unix,dc=ad,dc=com]

Информация в этом сообщении предназначена исключительно для конкретных лиц, 
которым она адресована. В сообщении может содержаться конфиденциальная 
информация, которая не может быть раскрыта или использована кем-либо, кроме 
адресатов. Если вы не адресат этого сообщения, то использование, переадресация, 
копирование или распространение содержания сообщения или его части незаконно и 
запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно 
сообщите отправителю об этом и удалите со всем содержимым само сообщение и 
любые возможные его копии и приложения.

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. The 
contents may not be disclosed or used by anyone other than the addressee. If 
you are not the intended recipient(s), any use, disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. If you have received this communication in 
error please notify us immediately by responding to this email and then delete 
the e-mail and all attachments and any copies thereof.

(c)20mf50

-- 
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] Accident upgrade 3.3 to 4.1

On 04/08/2015 01:40 PM, Alexander Frolushkin wrote:

 -Original Message-
 From: Jakub Hrozek [mailto:jhro...@redhat.com]
 Sent: Wednesday, April 08, 2015 5:12 PM
 To: Alexander Frolushkin (SIB)
 Cc: 'Martin Kosek'; freeipa-users@redhat.com; Ludwig Krispenz; Thierry Bordaz
 Subject: Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

 On Wed, Apr 08, 2015 at 11:07:25AM +, Alexander Frolushkin wrote:
 -Original Message-
 From: Martin Kosek [mailto:mko...@redhat.com]
 Sent: Wednesday, April 08, 2015 4:47 PM
 To: Alexander Frolushkin (SIB); freeipa-users@redhat.com; Ludwig
 Krispenz; Thierry Bordaz; Jakub Hrozek
 Subject: Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

 In any case, upgrade from 3.3 to 4.1 should just work, you just need to 
 have a recent enough RHEL-6 servers - at least RHEL-6.6+z-streams.

 Please note, we currently have a three servers with IPA 4.1.0, and 13 
 servers with IPA 3.3.3 working simultaneously.
 Also about hbac:

 [hbac_eval_user_element] (0x0080): Parse error on [cn=system: read
 replication
 agreements+nsuniqueid=..,cn=permissions,cn=pbac,dc=unix,dc=
 agreements+ad,
 dc=com]

 CCing Jakub, but this looks like

 https://bugzilla.redhat.com/show_bug.cgi?id=1135433

 This is actually https://fedorahosted.org/sssd/ticket/2603

 According to the RDN: agreements+nsuniqueid= there is a replication 
 conflict on the servers. Latest SSSD builds are able to handle those, but 
 you should fix the server anyway.

 Thank You!
 Conflict already has been resolved:

 # ldapsearch -D uid=admin,cn=users,cn=accounts,dc=unix,dc=ad,dc=com -W  -b 
 nsds5ReplConflict=* \* nsds5ReplConflict
 Enter LDAP Password:
 # extended LDIF
 #
 # LDAPv3
 # base nsds5ReplConflict=* with scope subtree
 # filter: (objectclass=*)
 # requesting: * nsds5ReplConflict
 #

 # search result
 search: 2
 result: 32 No such object

 # numResponses: 1

 After that, client are able to login via ssh on servers connected to 7.1 
 servers, but still no login on client servers connected to 7.0 IPA servers...

Good! Does it only happen for users that have any RBAC role assigned or are
non-privileged users able to log in?

I suspect you may be hitting
https://bugzilla.redhat.com/show_bug.cgi?id=1140888

fixed in RHEL-7.1 DS and IPA.

-- 
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] Accident upgrade 3.3 to 4.1

2015-04-08 Thread Ludwig Krispenz



On 04/08/2015 12:04 PM, Martin Kosek wrote:

On 04/08/2015 11:52 AM, Alexander Frolushkin wrote:

Hello!
We used have a geo-replicated IPA with RHEL 7.0, and on one site ipa servers 
was upgraded by mistake to RHEL 7.1 (ipa-server-4.1.0-18.el7_1.3.x86_64).
Now it is broken globally, in logs I see these:

[08/Apr/2015:13:06:47 +0600] NSACLPlugin - ACL PARSE ERR(rv=-5): 
(targetattr=ipaProtectedOperation;write_keys
[08/Apr/2015:13:06:47 +0600] NSACLPlugin - __aclp__init_targetattr: targetattr 
ipaProtectedOperation;write_keys does not exist in schema. Please add attributeTypes 
ipaProtectedOperation;write_keys to schema if necessary.

What can I do to fix this catastrophe, or it is fatal?
As it seems from the client servers, hbac is not working at all, maybe all 
other things as well :(

With best regards,
Alexander Frolushkin

AFAIK, this particular error message should not be fatal to the function and
new ACI should just be ignored.
yes, but I don't know if any IPA component would rely on access granted 
by this aci.

Maybe the new schema did not replicate

is this message logged on all servers ?

properly. Do you see other DS errors? (CCing DS guys)

Non-working HBAC is also strange, SSSD developers will want logs to analyze,
see https://fedorahosted.org/sssd/wiki/Troubleshooting

In any case, upgrade from 3.3 to 4.1 should just work, you just need to have a
recent enough RHEL-6 servers - at least RHEL-6.6+z-streams.


--
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] krb5kdc: Server error

2015-04-08 Thread Traiano Welcome

Hi Ben



On Wed, Apr 8, 2015 at 12:39 PM, Ben .T.George bentech4...@gmail.com wrote:
 HI

 i am getting krb5kdc: Server error on ligs:

 krb5kdc: Server error - while fetching master key K/M for realm SUN.LOCAL

 and the ipactl status is taking long time. Web interface is not able to
 athenticate.

 If i issue ipactl restart, noting is happening

 to solve this issue currently i am restarting full server..


 How can i fix this?


Check the tail-end of  this thread:

https://www.redhat.com/archives/freeipa-users/2015-April/msg00011.html

You may want to begin by checking /etc/hosts for the right format (ip
address fqdn hostname).
DNS is probably the very next thing you want to check... thoroughly.






 Regards,
 Ben

 --
 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] Accident upgrade 3.3 to 4.1

-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Wednesday, April 08, 2015 4:18 PM
To: Martin Kosek
Cc: Alexander Frolushkin (SIB); freeipa-users@redhat.com; Thierry Bordaz
Subject: Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

On 04/08/2015 12:04 PM, Martin Kosek wrote:
 On 04/08/2015 11:52 AM, Alexander Frolushkin wrote:
 Hello!
 We used have a geo-replicated IPA with RHEL 7.0, and on one site ipa servers 
 was upgraded by mistake to RHEL 7.1 (ipa-server-4.1.0-18.el7_1.3.x86_64).
 Now it is broken globally, in logs I see these:

 [08/Apr/2015:13:06:47 +0600] NSACLPlugin - ACL PARSE ERR(rv=-5):
 (targetattr=ipaProtectedOperation;write_keys
 [08/Apr/2015:13:06:47 +0600] NSACLPlugin - __aclp__init_targetattr: 
 targetattr ipaProtectedOperation;write_keys does not exist in schema. 
 Please add attributeTypes ipaProtectedOperation;write_keys to schema if 
 necessary.

 What can I do to fix this catastrophe, or it is fatal?
 As it seems from the client servers, hbac is not working at all,
 maybe all other things as well :(

 With best regards,
 Alexander Frolushkin
 AFAIK, this particular error message should not be fatal to the
 function and new ACI should just be ignored.
yes, but I don't know if any IPA component would rely on access granted by this 
aci.
 Maybe the new schema did not replicate
is this message logged on all servers ?
 properly. Do you see other DS errors? (CCing DS guys)

 Non-working HBAC is also strange, SSSD developers will want logs to
 analyze, see https://fedorahosted.org/sssd/wiki/Troubleshooting

 In any case, upgrade from 3.3 to 4.1 should just work, you just need
 to have a recent enough RHEL-6 servers - at least RHEL-6.6+z-streams.

Error messages are differs on 7.0 and 7.1 servers.
On one of accidently upgraded server I have following error in dirsrv logs:

[08/Apr/2015:13:24:12 +0300] connection - conn=1095 fd=131 Incoming BER Element 
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize 
attribute in cn=config to increase.
[08/Apr/2015:13:24:12 +0300] connection - conn=1094 fd=124 Incoming BER Element 
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize 
attribute in cn=config to increase.
[08/Apr/2015:13:24:12 +0300] connection - conn=1096 fd=124 Incoming BER Element 
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize 
attribute in cn=config to increase.
[08/Apr/2015:13:24:12 +0300] connection - conn=1097 fd=131 Incoming BER Element 
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize 
attribute in cn=config to increase.
[08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:13:25:15 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://vlg-rhidm02.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:13:25:15 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://vlg-rhidm02.unix.ad.com:389/o%3Dipaca) failed.

Информация в этом сообщении предназначена исключительно для конкретных лиц, 
которым она адресована. В сообщении может содержаться конфиденциальная 
информация, которая не может быть раскрыта или использована кем-либо, кроме 
адресатов. Если вы не адресат этого сообщения, то использование, переадресация, 
копирование или распространение содержания сообщения или его части незаконно и 
запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно 
сообщите отправителю об этом и удалите со всем содержимым само сообщение и 
любые возможные его копии и приложения.

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. The 
contents may not be disclosed or used by anyone other than the addressee. If 
you are not the intended recipient(s), any use, disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. If you have received this communication in 
error please notify us immediately by responding to this email and then delete 
the e-mail and all attachments and any copies thereof.

(c)20mf50

-- 
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] krb5kdc: Server error

2015-04-08 Thread Ben .T.George

HI Traino,

thanks for the info

i have checked the hots and confirmed that entry was ip FQDN Alias
format


And the DNS everything is working

[root@kwtprsolipa01 slapd-SUN-LOCAL]# for i in _ldap._tcp _kerberos._tcp
_kerberos._udp _kerberos-master._tcp _kerberos-master._udp _ntp._udp; do
echo ; dig @mha.local ${i}.SUN.LOCAL srv +nocmd +noquestion +nocomments
+nostats +noaa +noadditional +noauthority; done | egrep -v ^; | egrep _

_ldap._tcp.SUN.LOCAL.   21965   IN  SRV 0 100 389
kwtprsolipa01.sun.local.
_kerberos._tcp.SUN.LOCAL. 1957  IN  SRV 0 100 88
kwtprsolipa01.sun.local.
_kerberos._udp.SUN.LOCAL. 86400 IN  SRV 0 100 88
kwtprsolipa01.sun.local.
_kerberos-master._tcp.SUN.LOCAL. 86400 IN SRV   0 100 88
kwtprsolipa01.sun.local.
_kerberos-master._udp.SUN.LOCAL. 9112 IN SRV0 100 88
kwtprsolipa01.sun.local.
_ntp._udp.SUN.LOCAL.86400   IN  SRV 0 100 123
kwtprsolipa01.sun.local.

[root@kwtprsolipa01 slapd-SUN-LOCAL]# for i in _ldap._tcp _kerberos._tcp
_kerberos._udp _kerberos-master._tcp _kerberos-master._udp _ntp._udp; do
echo ; dig @mha.local ${i}.MHA.LOCAL srv +nocmd +noquestion +nocomments
+nostats +noaa +noadditional +noauthority; done | egrep -v ^; | egrep _

_ldap._tcp.MHA.LOCAL.   600 IN  SRV 0 100 389
dxbprdc002.mha.local.
_ldap._tcp.MHA.LOCAL.   600 IN  SRV 0 100 389
kwtprdc001.mha.local.
_ldap._tcp.MHA.LOCAL.   600 IN  SRV 0 100 389
dxbprdc001.mha.local.
_ldap._tcp.MHA.LOCAL.   600 IN  SRV 0 100 389
rusmosprdc002.mha.local.
_ldap._tcp.MHA.LOCAL.   600 IN  SRV 0 100 389
kwtprdc002.mha.local.
_kerberos._tcp.MHA.LOCAL. 600   IN  SRV 0 100 88
kwtprdc001.mha.local.
_kerberos._tcp.MHA.LOCAL. 600   IN  SRV 0 100 88
dxbprdc002.mha.local.
_kerberos._tcp.MHA.LOCAL. 600   IN  SRV 0 100 88
dxbprdc001.mha.local.
_kerberos._tcp.MHA.LOCAL. 600   IN  SRV 0 100 88
kwtprdc002.mha.local.
_kerberos._udp.MHA.LOCAL. 600   IN  SRV 0 100 88
kwtprdc002.mha.local.
_kerberos._udp.MHA.LOCAL. 600   IN  SRV 0 100 88
dxbprdc002.mha.local.
_kerberos._udp.MHA.LOCAL. 600   IN  SRV 0 100 88
kwtprdc001.mha.local.
_kerberos._udp.MHA.LOCAL. 600   IN  SRV 0 100 88
dxbprdc001.mha.local.

[root@kwtprsolipa01 slapd-SUN-LOCAL]# host 172.16.99.99
99.99.16.172.in-addr.arpa domain name pointer kwtprsolipa01.sun.local.
[root@kwtprsolipa01 slapd-SUN-LOCAL]# host kwtprsolipa01.sun.local
kwtprsolipa01.sun.local has address 172.16.99.99

[root@kwtprsolipa01 slapd-SUN-LOCAL]# host mha.local
mha.local has address 172.16.98.171
mha.local has address 172.16.100.180
mha.local has address 10.10.10.11
mha.local has address 10.10.10.10


[root@kwtprsolipa01 slapd-SUN-LOCAL]# dig kwtprsolipa01.sun.local

;  DiG 9.9.4-RedHat-9.9.4-18.el7  kwtprsolipa01.sun.local
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 23767
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;kwtprsolipa01.sun.local.   IN  A

;; ANSWER SECTION:
kwtprsolipa01.sun.local. 38 IN  A   172.16.99.99

;; Query time: 0 msec
;; SERVER: 172.16.100.180#53(172.16.100.180)
;; WHEN: Wed Apr 08 13:54:02 AST 2015
;; MSG SIZE  rcvd: 68



On Wed, Apr 8, 2015 at 1:27 PM, Traiano Welcome trai...@gmail.com wrote:

 Hi Ben



 On Wed, Apr 8, 2015 at 12:39 PM, Ben .T.George bentech4...@gmail.com
 wrote:
  HI
 
  i am getting krb5kdc: Server error on ligs:
 
  krb5kdc: Server error - while fetching master key K/M for realm SUN.LOCAL
 
  and the ipactl status is taking long time. Web interface is not able to
  athenticate.
 
  If i issue ipactl restart, noting is happening
 
  to solve this issue currently i am restarting full server..
 
 
  How can i fix this?
 

 Check the tail-end of  this thread:

 https://www.redhat.com/archives/freeipa-users/2015-April/msg00011.html

 You may want to begin by checking /etc/hosts for the right format (ip
 address fqdn hostname).
 DNS is probably the very next thing you want to check... thoroughly.






  Regards,
  Ben
 
  --
  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] Accident upgrade 3.3 to 4.1

-Original Message-
From: Martin Kosek [mailto:mko...@redhat.com]
Sent: Wednesday, April 08, 2015 4:47 PM
To: Alexander Frolushkin (SIB); freeipa-users@redhat.com; Ludwig Krispenz; 
Thierry Bordaz; Jakub Hrozek
Subject: Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

 In any case, upgrade from 3.3 to 4.1 should just work, you just need to have 
 a recent enough RHEL-6 servers - at least RHEL-6.6+z-streams.

 Please note, we currently have a three servers with IPA 4.1.0, and 13 
 servers with IPA 3.3.3 working simultaneously.
 Also about hbac:

 [hbac_eval_user_element] (0x0080): Parse error on [cn=system: read
 replication
 agreements+nsuniqueid=..,cn=permissions,cn=pbac,dc=unix,dc=ad,
 dc=com]

CCing Jakub, but this looks like

https://bugzilla.redhat.com/show_bug.cgi?id=1135433

that is fixed in sssd-1.12.1-1.el7.

I have one test server with 7.1 and sssd-1.12.2-58.el7_1.6.x86_64
But it is not works also.
And on 6.6 servers (with the latest sssd-1.11.6-30.el6_6.4.x86_64) situation is 
the same.

Информация в этом сообщении предназначена исключительно для конкретных лиц, 
которым она адресована. В сообщении может содержаться конфиденциальная 
информация, которая не может быть раскрыта или использована кем-либо, кроме 
адресатов. Если вы не адресат этого сообщения, то использование, переадресация, 
копирование или распространение содержания сообщения или его части незаконно и 
запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно 
сообщите отправителю об этом и удалите со всем содержимым само сообщение и 
любые возможные его копии и приложения.

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. The 
contents may not be disclosed or used by anyone other than the addressee. If 
you are not the intended recipient(s), any use, disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. If you have received this communication in 
error please notify us immediately by responding to this email and then delete 
the e-mail and all attachments and any copies thereof.

(c)20mf50

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

Sudo seems to be configured correctly but somehow it's not working 

Even if I do a sudo -l under the admin user 

[admin@ironhide tmp]$ sudo -l
[sudo] password for admin: 
Matching Defaults entries for admin on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep=COLORS
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS, env_keep+=MAIL PS1
PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE, env_keep+=LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES, env_keep+=LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE, env_keep+=LC_TIME LC_ALL
LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY,
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User admin may run the following commands on this host:
(admin, chamambom, kamoyob, kumalop, machangeteb, masaitit, masvivic,
matangiraa, nyahumap, pedzisail, tayengwaj : ALL) /usr/bin/vim,
/usr/bin/less
[admin@ironhide tmp]$


tail -f /var/log/sssd/sssd_sudo.log 


[root@ironhide ~]# tail -f /var/log/sssd/sssd_sudo.log 
(Wed Apr  8 13:35:27 2015) [sssd[sudo]] [sysdb_domain_init_internal]
(0x0200): DB File for ai.co.zw: /var/lib/sss/db/cache_ai.co.zw.ldb
(Wed Apr  8 13:35:27 2015) [sssd[sudo]] [ldb] (0x0400): asq: Unable to
register control with rootdse!
(Wed Apr  8 13:35:27 2015) [sssd[sudo]] [sss_process_init] (0x0400):
Responder Initialization complete
(Wed Apr  8 13:35:27 2015) [sssd[sudo]] [sudo_process_init] (0x0400): SUDO
Initialization complete
(Wed Apr  8 13:35:27 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x40c900:doma...@ai.co.zw]
(Wed Apr  8 13:35:27 2015) [sssd[sudo]] [sss_dp_get_domains_msg] (0x0400):
Sending get domains request for [ai.co.zw][forced][]
(Wed Apr  8 13:35:27 2015) [sssd[sudo]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x40c900:doma...@ai.co.zw]
(Wed Apr  8 13:35:27 2015) [sssd[sudo]] [dp_id_callback] (0x0100): Got id
ack and version (1) from DP
(Wed Apr  8 13:35:27 2015) [sssd[sudo]] [id_callback] (0x0100): Got id ack
and version (1) from Monitor
(Wed Apr  8 13:35:28 2015) [sssd[sudo]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x40c900:doma...@ai.co.zw]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [accept_fd_handler] (0x0400): Client
connected!
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Received client version [1].
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Offered version [1].
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'admin' matched without domain, user is admin
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): using default domain [(null)]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'admin' matched without domain, user is admin
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): using default domain [(null)]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting default options for [admin] from [ALL]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [ad...@ai.co.zw]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sudosrv_get_user] (0x0400):
Returning info for user [ad...@ai.co.zw]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
Retrieving default options for [admin] from [ai.co.zw]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[((objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=admin)(sud
oUser=#146820)(sudoUser=%admins)(sudoUser=%trust
admins)(sudoUser=%admins)(sudoUser=+*))((dataExpireTimestamp=1428492937)))
]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with [((objectClass=sudoRule)(|(name=defaults)))]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
(0x0400): Returning 0 rules for [default options@ai.co.zw]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'admin' matched without domain, user is admin
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): using default domain [(null)]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'admin' matched without domain, user is admin
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): using default domain [(null)]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting rules for [admin] from [ALL]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [ad...@ai.co.zw]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sudosrv_get_user] (0x0400):
Returning info for user [ad...@ai.co.zw]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
Retrieving rules for [admin] from [ai.co.zw]
(Wed Apr  8 13:35:37 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]

Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Wednesday, April 08, 2015 5:12 PM
To: Alexander Frolushkin (SIB)
Cc: 'Martin Kosek'; freeipa-users@redhat.com; Ludwig Krispenz; Thierry Bordaz
Subject: Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

On Wed, Apr 08, 2015 at 11:07:25AM +, Alexander Frolushkin wrote:
 -Original Message-
 From: Martin Kosek [mailto:mko...@redhat.com]
 Sent: Wednesday, April 08, 2015 4:47 PM
 To: Alexander Frolushkin (SIB); freeipa-users@redhat.com; Ludwig
 Krispenz; Thierry Bordaz; Jakub Hrozek
 Subject: Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

  In any case, upgrade from 3.3 to 4.1 should just work, you just need to 
  have a recent enough RHEL-6 servers - at least RHEL-6.6+z-streams.

  Please note, we currently have a three servers with IPA 4.1.0, and 13 
  servers with IPA 3.3.3 working simultaneously.
  Also about hbac:

  [hbac_eval_user_element] (0x0080): Parse error on [cn=system: read
  replication
  agreements+nsuniqueid=..,cn=permissions,cn=pbac,dc=unix,dc=
  agreements+ad,
  dc=com]

 CCing Jakub, but this looks like

 https://bugzilla.redhat.com/show_bug.cgi?id=1135433

This is actually https://fedorahosted.org/sssd/ticket/2603

According to the RDN: agreements+nsuniqueid= there is a replication conflict 
on the servers. Latest SSSD builds are able to handle those, but you should 
fix the server anyway.

Thank You!
Conflict already has been resolved:

# ldapsearch -D uid=admin,cn=users,cn=accounts,dc=unix,dc=ad,dc=com -W  -b 
nsds5ReplConflict=* \* nsds5ReplConflict
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base nsds5ReplConflict=* with scope subtree
# filter: (objectclass=*)
# requesting: * nsds5ReplConflict
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

After that, client are able to login via ssh on servers connected to 7.1 
servers, but still no login on client servers connected to 7.0 IPA servers...

Информация в этом сообщении предназначена исключительно для конкретных лиц, 
которым она адресована. В сообщении может содержаться конфиденциальная 
информация, которая не может быть раскрыта или использована кем-либо, кроме 
адресатов. Если вы не адресат этого сообщения, то использование, переадресация, 
копирование или распространение содержания сообщения или его части незаконно и 
запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно 
сообщите отправителю об этом и удалите со всем содержимым само сообщение и 
любые возможные его копии и приложения.

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. The 
contents may not be disclosed or used by anyone other than the addressee. If 
you are not the intended recipient(s), any use, disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. If you have received this communication in 
error please notify us immediately by responding to this email and then delete 
the e-mail and all attachments and any copies thereof.

(c)20mf50

-- 
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] Accident upgrade 3.3 to 4.1

2015-04-08 Thread thierry bordaz

On 04/08/2015 12:36 PM, Alexander Frolushkin wrote:

-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Wednesday, April 08, 2015 4:18 PM
To: Martin Kosek
Cc: Alexander Frolushkin (SIB); freeipa-users@redhat.com; Thierry Bordaz
Subject: Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

On 04/08/2015 12:04 PM, Martin Kosek wrote:

On 04/08/2015 11:52 AM, Alexander Frolushkin wrote:

Hello!
We used have a geo-replicated IPA with RHEL 7.0, and on one site ipa servers 
was upgraded by mistake to RHEL 7.1 (ipa-server-4.1.0-18.el7_1.3.x86_64).
Now it is broken globally, in logs I see these:

[08/Apr/2015:13:06:47 +0600] NSACLPlugin - ACL PARSE ERR(rv=-5):
(targetattr=ipaProtectedOperation;write_keys
[08/Apr/2015:13:06:47 +0600] NSACLPlugin - __aclp__init_targetattr: targetattr 
ipaProtectedOperation;write_keys does not exist in schema. Please add attributeTypes 
ipaProtectedOperation;write_keys to schema if necessary.

What can I do to fix this catastrophe, or it is fatal?
As it seems from the client servers, hbac is not working at all,
maybe all other things as well :(

With best regards,
Alexander Frolushkin

AFAIK, this particular error message should not be fatal to the
function and new ACI should just be ignored.

yes, but I don't know if any IPA component would rely on access granted by this 
aci.

Maybe the new schema did not replicate

is this message logged on all servers ?

properly. Do you see other DS errors? (CCing DS guys)

Non-working HBAC is also strange, SSSD developers will want logs to
analyze, see https://fedorahosted.org/sssd/wiki/Troubleshooting

In any case, upgrade from 3.3 to 4.1 should just work, you just need
to have a recent enough RHEL-6 servers - at least RHEL-6.6+z-streams.

Error messages are differs on 7.0 and 7.1 servers.
On one of accidently upgraded server I have following error in dirsrv logs:

[08/Apr/2015:13:24:12 +0300] connection - conn=1095 fd=131 Incoming BER Element 
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize 
attribute in cn=config to increase.
[08/Apr/2015:13:24:12 +0300] connection - conn=1094 fd=124 Incoming BER Element 
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize 
attribute in cn=config to increase.
[08/Apr/2015:13:24:12 +0300] connection - conn=1096 fd=124 Incoming BER Element 
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize 
attribute in cn=config to increase.
[08/Apr/2015:13:24:12 +0300] connection - conn=1097 fd=131 Incoming BER Element 
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize 
attribute in cn=config to increase.
This message is logged if the received message was too large. But here 
max size was 200Mb.

I can not imagine a such large message.
Being log at the same second, it could be transient error. Have you seen 
others messages like these ?

[08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:13:25:15 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://vlg-rhidm02.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:13:25:15 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://vlg-rhidm02.unix.ad.com:389/o%3Dipaca) failed.

Here it is likely trigger by RUV containing duplicated values (multiple 
replica install ?). You may have to use cleanruv after the upgrade.

ipa-replica-manage list-ruv  and ipa-replica-manager clean-ruv

Информация в этом сообщении предназначена исключительно для конкретных лиц, 
которым она адресована. В сообщении может содержаться конфиденциальная 
информация, которая не может быть раскрыта или использована кем-либо, кроме 
адресатов. Если вы не адресат этого сообщения, то использование, переадресация, 
копирование или распространение содержания сообщения или его части незаконно и 
запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно 
сообщите отправителю об этом и удалите со всем содержимым само сообщение и 
любые возможные его копии и приложения.

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. The 
contents may not be disclosed or used by anyone other than the addressee. If 
you are not the intended recipient(s), any use, disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. If you have received this communication in 
error please notify us immediately by

Re: [Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

2015-04-08 Thread Martin Chamambo



From: Jakub Hrozek [jhro...@redhat.com]
Sent: Wednesday, April 08, 2015 2:01 PM
To: Martin Chamambo
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

On Wed, Apr 08, 2015 at 01:39:44PM +0200, Chamambo Martin wrote:
 Sudo seems to be configured correctly but somehow it's not working

 Even if I do a sudo -l under the admin user

 [admin@ironhide tmp]$ sudo -l
 [sudo] password for admin:
 Matching Defaults entries for admin on this host:
 requiretty, !visiblepw, always_set_home, env_reset, env_keep=COLORS
 DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS, env_keep+=MAIL PS1
 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE, env_keep+=LC_COLLATE
 LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES, env_keep+=LC_MONETARY
 LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE, env_keep+=LC_TIME LC_ALL
 LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY,
 secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

 User admin may run the following commands on this host:
 (admin, chamambom, kamoyob, kumalop, machangeteb, masaitit, masvivic,
 matangiraa, nyahumap, pedzisail, tayengwaj : ALL) /usr/bin/vim,
~~~
 /usr/bin/less
  ~
According to this output, admin can run both vim and less... ??

-- 
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] Accident upgrade 3.3 to 4.1

On Wed, Apr 08, 2015 at 11:40:08AM +, Alexander Frolushkin wrote:
 After that, client are able to login via ssh on servers connected to 7.1 
 servers, but still no login on client servers connected to 7.0 IPA servers...

There we might be a problem with ACIs, can you check the logs on the
clients?

-- 
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] Accident upgrade 3.3 to 4.1

On 04/08/2015 12:12 PM, Alexander Frolushkin wrote:

 -Original Message-
 From: Martin Kosek [mailto:mko...@redhat.com]
 Sent: Wednesday, April 08, 2015 4:04 PM
 To: Alexander Frolushkin (SIB); freeipa-users@redhat.com; Ludwig Krispenz; 
 Thierry Bordaz
 Subject: Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

 On 04/08/2015 11:52 AM, Alexander Frolushkin wrote:
 Hello!
 We used have a geo-replicated IPA with RHEL 7.0, and on one site ipa 
 servers was upgraded by mistake to RHEL 7.1 
 (ipa-server-4.1.0-18.el7_1.3.x86_64).
 Now it is broken globally, in logs I see these:

 [08/Apr/2015:13:06:47 +0600] NSACLPlugin - ACL PARSE ERR(rv=-5):
 (targetattr=ipaProtectedOperation;write_keys
 [08/Apr/2015:13:06:47 +0600] NSACLPlugin - __aclp__init_targetattr: 
 targetattr ipaProtectedOperation;write_keys does not exist in schema. 
 Please add attributeTypes ipaProtectedOperation;write_keys to schema if 
 necessary.

 What can I do to fix this catastrophe, or it is fatal?
 As it seems from the client servers, hbac is not working at all, maybe
 all other things as well :(

 With best regards,
 Alexander Frolushkin

 AFAIK, this particular error message should not be fatal to the function and 
 new ACI should just be ignored. Maybe the new schema did not replicate 
 properly. Do you see other DS errors? (CCing DS guys)

 Non-working HBAC is also strange, SSSD developers will want logs to analyze, 
 see https://fedorahosted.org/sssd/wiki/Troubleshooting

 In any case, upgrade from 3.3 to 4.1 should just work, you just need to have 
 a recent enough RHEL-6 servers - at least RHEL-6.6+z-streams.

 Please note, we currently have a three servers with IPA 4.1.0, and 13 servers 
 with IPA 3.3.3 working simultaneously.
 Also about hbac:

 [hbac_eval_user_element] (0x0080): Parse error on [cn=system: read 
 replication 
 agreements+nsuniqueid=..,cn=permissions,cn=pbac,dc=unix,dc=ad,dc=com]

CCing Jakub, but this looks like

https://bugzilla.redhat.com/show_bug.cgi?id=1135433

that is fixed in sssd-1.12.1-1.el7.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

On Wed, Apr 08, 2015 at 01:39:44PM +0200, Chamambo Martin wrote:
 Sudo seems to be configured correctly but somehow it's not working 
 
 Even if I do a sudo -l under the admin user 
 
 [admin@ironhide tmp]$ sudo -l
 [sudo] password for admin: 
 Matching Defaults entries for admin on this host:
 requiretty, !visiblepw, always_set_home, env_reset, env_keep=COLORS
 DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS, env_keep+=MAIL PS1
 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE, env_keep+=LC_COLLATE
 LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES, env_keep+=LC_MONETARY
 LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE, env_keep+=LC_TIME LC_ALL
 LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY,
 secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
 
 User admin may run the following commands on this host:
 (admin, chamambom, kamoyob, kumalop, machangeteb, masaitit, masvivic,
 matangiraa, nyahumap, pedzisail, tayengwaj : ALL) /usr/bin/vim,
~~~
 /usr/bin/less
  ~
According to this output, admin can run both vim and less... ??

-- 
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] Accident upgrade 3.3 to 4.1

On 04/08/2015 11:52 AM, Alexander Frolushkin wrote:
 Hello!
 We used have a geo-replicated IPA with RHEL 7.0, and on one site ipa servers 
 was upgraded by mistake to RHEL 7.1 (ipa-server-4.1.0-18.el7_1.3.x86_64).
 Now it is broken globally, in logs I see these:
 
 [08/Apr/2015:13:06:47 +0600] NSACLPlugin - ACL PARSE ERR(rv=-5): 
 (targetattr=ipaProtectedOperation;write_keys
 [08/Apr/2015:13:06:47 +0600] NSACLPlugin - __aclp__init_targetattr: 
 targetattr ipaProtectedOperation;write_keys does not exist in schema. 
 Please add attributeTypes ipaProtectedOperation;write_keys to schema if 
 necessary.
 
 What can I do to fix this catastrophe, or it is fatal?
 As it seems from the client servers, hbac is not working at all, maybe all 
 other things as well :(
 
 With best regards,
 Alexander Frolushkin

AFAIK, this particular error message should not be fatal to the function and
new ACI should just be ignored. Maybe the new schema did not replicate
properly. Do you see other DS errors? (CCing DS guys)

Non-working HBAC is also strange, SSSD developers will want logs to analyze,
see https://fedorahosted.org/sssd/wiki/Troubleshooting

In any case, upgrade from 3.3 to 4.1 should just work, you just need to have a
recent enough RHEL-6 servers - at least RHEL-6.6+z-streams.

-- 
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] Accident upgrade 3.3 to 4.1

 On one of accidently upgraded server I have following error in dirsrv logs:

 [08/Apr/2015:13:24:12 +0300] connection - conn=1095 fd=131 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:13:24:12 +0300] connection - conn=1094 fd=124 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:13:24:12 +0300] connection - conn=1096 fd=124 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:13:24:12 +0300] connection - conn=1097 fd=131 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
This message is logged if the received message was too large. But here max 
size was 200Mb.
I can not imagine a such large message.
Being log at the same second, it could be transient error. Have you seen 
others messages like these ?

Yes, it still here.

[08/Apr/2015:14:55:01 +0300] connection - conn=1125 fd=130 Incoming BER Element 
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize 
attribute in cn=config to increase.
[08/Apr/2015:14:55:01 +0300] connection - conn=1124 fd=126 Incoming BER Element 
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize 
attribute in cn=config to increase.
[08/Apr/2015:14:55:01 +0300] connection - conn=1126 fd=126 Incoming BER Element 
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize 
attribute in cn=config to increase.
[08/Apr/2015:14:55:26 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://cnt-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:14:55:26 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://cnt-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:14:55:26 +0300] attrlist_replace - attr_replace (nsslapd-referral, 
ldap://cnt-rhidm01.unix.ad.com:389/o%3Dipaca) failed.


 [08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:13:25:15 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://vlg-rhidm02.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:13:25:15 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://vlg-rhidm02.unix.ad.com:389/o%3Dipaca) failed.

Here it is likely trigger by RUV containing duplicated values (multiple 
replica install ?). You may have to use cleanruv after the upgrade.
ipa-replica-manage list-ruv  and ipa-replica-manager clean-ruv

Do You mean we need to upgrade all 3.3.3 IPA servers to 4.1 first? Or this can 
be cleaned right now on remaining servers?

BTW:
# ipa-replica-manage list-ruv
Directory Manager password:

sib-rhidm03.unix.ad.com:389: 5
dv-rhidm01.unix.ad.com:389: 17
sib-rhidm02.unix.ad.com:389: 3
sib-rhidm01.unix.ad.com:389: 4
url-rhidm01.unix.ad.com:389: 6
url-rhidm02.unix.ad.com:389: 7

nw-rhidm01.unix.ad.com:389: 19




Информация в этом сообщении предназначена исключительно для конкретных лиц, 
которым она адресована. В сообщении может содержаться конфиденциальная 
информация, которая не может быть раскрыта или использована кем-либо, кроме 
адресатов. Если вы не адресат этого сообщения, то использование, переадресация, 
копирование или распространение содержания сообщения или его части незаконно и 
запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно 
сообщите отправителю об этом и удалите со всем содержимым само сообщение и 
любые возможные его копии и приложения.

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. The 
contents may not be disclosed or used by anyone other than the addressee. If 
you are not the intended recipient(s), any use, disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. If you have received this communication in 
error please notify us immediately by responding to this email and then delete 
the e-mail and all attachments and any copies thereof.

(c)20mf50

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

2015-04-08 Thread Lukas Slebodnik

On (08/04/15 09:25), Chamambo Martin wrote:
Good day 

I am running FreeIPA, version: 4.1.0 and everything is working well except
SUDO configuration.

ipa-client-install on CentOS 7.1 should configure sudo by default.

I have 3 questions

   1: I have configured the bare minimum sudo configuration without
hostgroups and netgroups , just sudo commands and sudo command groups that
have been added as sudo rules .this should work right
yes.

and sudo rules with netgroups shuld work on CentOS 7.1 as well
because nisdomainname should be configured.

2: I have centos 6.6 and redhat 6.6 clients using the sssd
service  ,is that enough for sudo to work if the configs are as below


cat /etc/nsswitch.conf

sudoers: files sss

cat /etc/sssd/sssd.conf

[domain/ai.co.zw]

debug_level=6
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ai.co.zw
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ironhide.ai.co.zw
chpass_provider = ipa
ipa_server = _srv_, cyclops.ai.co.zw
ldap_tls_cacert = /etc/ipa/ca.crt

[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2


domains = ai.co.zw
[nss]
homedir_substring = /home
The default value of this option is /home
You can remove it. Where did you find it?


[pam]

[sudo]

[autofs]

[ssh]


If you do not use netgroups (or hostgroups) in sudo rules
then this configuration should work on rhel 6.6 (sssd = 1.10)
The same steps are decribed in manual page sssd-sudo.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

On Wed, Apr 08, 2015 at 10:00:50AM +0200, Chamambo Martin wrote:
 I have these logs and cant seem to make sense of them  

These are not the logs we asked for. What we need is debug_level=6 in
the sudo section, then run sudo, then attach
/var/log/sssd/sssd_sudo.log.

It would also be nice if you could install ldb-tools and run:
ldbsearch -H /var/lib/sss/db/cache_ai.co.zw.ldb
To see if the sudo rules were cached at all by the sudo full refresh
(see man sssd-sudo for description of the different refreshes sssd
does).

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

I have this log after doing a debug_level=6 in the sudo section and have
attached a txt file for the ldbsearch -H /var/lib/sss/db/cache_ai.co.zw.ldb 

[root@ironhide ~]# tail -f /var/log/sssd/sssd_sudo.log
(Wed Apr  8 10:10:03 2015) [sssd[sudo]] [sysdb_domain_init_internal]
(0x0200): DB File for ai.co.zw: /var/lib/sss/db/cache_ai.co.zw.ldb
(Wed Apr  8 10:10:03 2015) [sssd[sudo]] [ldb] (0x0400): asq: Unable to
register control with rootdse!
(Wed Apr  8 10:10:03 2015) [sssd[sudo]] [sss_process_init] (0x0400):
Responder Initialization complete
(Wed Apr  8 10:10:03 2015) [sssd[sudo]] [sudo_process_init] (0x0400): SUDO
Initialization complete
(Wed Apr  8 10:10:03 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x40c900:doma...@ai.co.zw]
(Wed Apr  8 10:10:03 2015) [sssd[sudo]] [sss_dp_get_domains_msg] (0x0400):
Sending get domains request for [ai.co.zw][forced][]
(Wed Apr  8 10:10:03 2015) [sssd[sudo]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x40c900:doma...@ai.co.zw]
(Wed Apr  8 10:10:03 2015) [sssd[sudo]] [dp_id_callback] (0x0100): Got id
ack and version (1) from DP
(Wed Apr  8 10:10:03 2015) [sssd[sudo]] [id_callback] (0x0100): Got id ack
and version (1) from Monitor
(Wed Apr  8 10:10:04 2015) [sssd[sudo]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x40c900:doma...@ai.co.zw]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [accept_fd_handler] (0x0400): Client
connected!
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Received client version [1].
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Offered version [1].
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'admin' matched without domain, user is admin
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): using default domain [(null)]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'admin' matched without domain, user is admin
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): using default domain [(null)]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting default options for [admin] from [ALL]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [ad...@ai.co.zw]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_user] (0x0400):
Returning info for user [ad...@ai.co.zw]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
Retrieving default options for [admin] from [ai.co.zw]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[((objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=admin)(sud
oUser=#146820)(sudoUser=%admins)(sudoUser=%trust
admins)(sudoUser=%admins)(sudoUser=+*))((dataExpireTimestamp=1428480892)))
]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with [((objectClass=sudoRule)(|(name=defaults)))]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
(0x0400): Returning 0 rules for [default options@ai.co.zw]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'admin' matched without domain, user is admin
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): using default domain [(null)]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'admin' matched without domain, user is admin
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): using default domain [(null)]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting rules for [admin] from [ALL]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [ad...@ai.co.zw]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_user] (0x0400):
Returning info for user [ad...@ai.co.zw]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
Retrieving rules for [admin] from [ai.co.zw]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[((objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=admin)(sud
oUser=#146820)(sudoUser=%admins)(sudoUser=%trust
admins)(sudoUser=%admins)(sudoUser=+*))((dataExpireTimestamp=1428480892)))
]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[((objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=admin)(sudoUser=#14682000
00)(sudoUser=%admins)(sudoUser=%trust
admins)(sudoUser=%admins)(sudoUser=+*)))]
(Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
(0x0400): Returning 1 rules for [ad...@ai.co.zw]
(Wed Apr  8 10:15:02 2015) [sssd[sudo]] [client_recv] (0x0200): Client
disconnected!


-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com] 
Sent: Wednesday, April 08,

[Freeipa-users] krb5kdc: Server error

2015-04-08 Thread Ben .T.George

HI

i am getting krb5kdc: Server error on ligs:

krb5kdc: Server error - while fetching master key K/M for realm SUN.LOCAL

and the ipactl status is taking long time. Web interface is not able to
athenticate.

If i issue ipactl restart, noting is happening

to solve this issue currently i am restarting full server..


How can i fix this?

Regards,
Ben
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

Good day 

I am running FreeIPA, version: 4.1.0 and everything is working well except
SUDO configuration.

I have 3 questions

1: I have configured the bare minimum sudo configuration without
hostgroups and netgroups , just sudo commands and sudo command groups that
have been added as sudo rules .this should work right
2: I have centos 6.6 and redhat 6.6 clients using the sssd
service  ,is that enough for sudo to work if the configs are as below 


cat /etc/nsswitch.conf

sudoers: files sss

cat /etc/sssd/sssd.conf

[domain/ai.co.zw]

debug_level=6
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ai.co.zw
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ironhide.ai.co.zw
chpass_provider = ipa
ipa_server = _srv_, cyclops.ai.co.zw
ldap_tls_cacert = /etc/ipa/ca.crt

[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2


domains = ai.co.zw
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]






-- 
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] Setup of freeipa 4.1.3 failed

2015-04-08 Thread Natxo Asenjo

On Wed, Apr 8, 2015 at 7:57 AM, Markus Roth mar...@die5roths.de wrote:


 Yersterday I did the installation of freeipa on my banana Pi with
 modifying the source file ipalib/constants.py:('startup_timeout', 300).
 I changed it to 900 s. And the setup process was successful! The start of
 the CA had a duration of 630s! But after the installation freeipa is usable
 on the banana Pi.

 Thanks to Endi for help.


this is really cooll :-) Thanks for sharing,

If only one could get a small ssd on it starting up would be much faster.


--
Groeten,
natxo
-- 
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] Setup of freeipa 4.1.3 failed

2015-04-08 Thread Markus Roth


 Martin Kosek mko...@redhat.com hat am 8. April 2015 um 10:59 geschrieben:


 On 04/08/2015 07:57 AM, Markus Roth wrote:
 
  Endi Sukma Dewata edew...@redhat.com hat am 1. April 2015 um 23:56
  geschrieben:
 
 
  On 4/1/2015 4:29 PM, Markus Roth wrote:
  Am Mittwoch, 1. April 2015, 16:04:54 schrieben Sie:
  On 4/1/2015 11:56 AM, Endi Sukma Dewata wrote:
  On 03/31/2015 01:54 PM, Markus Roth wrote:
  Hi all,
 
  I want setup freeipa 4.1.3 on a fresh installed fedora 21.
 
  The ipa-server-install shows the following output:
  ...
 
  Done configuring directory server (dirsrv).
  Configuring certificate server (pki-tomcatd): Estimated time 3
  minutes 30
  seconds
 
  [1/27]: creating certificate server user
  [2/27]: configuring certificate server instance
  [3/27]: stopping certificate server instance to update CS.cfg
  [4/27]: backing up CS.cfg
  [5/27]: disabling nonces
  [6/27]: set up CRL publishing
  [7/27]: enable PKIX certificate path discovery and validation
  [8/27]: starting certificate server instance
  [error] RuntimeError: CA did not start in 300.0s
 
  CA did not start in 300.0s
 
  The ipa server install log shows this:
 
  2015-03-31T17:39:35Z DEBUG The CA status is: check interrupted
  2015-03-31T17:39:35Z DEBUG Waiting for CA to start...
 
  ...
 
  I uninstalled the ipa server completely several times and installed
  it again.
  But it always stops at the same step with the setup.
 
  Can anybody help?
 
  Based on the IPA install log alone it looks like the DS is already
  started, and the Dogtag is already started too in step [3/27]. It's the
  restart on step [8/27] that is failing.
 
  We will need to see the Dogtag debug log in order to know if Dogtag is
  indeed failing to restart or the installer for some reason cannot
  connect to Dogtag.
 
  Hi Markus,
 
  Based on the logs that you sent me, the Dogtag took a really long time
  to start:
 
  INFORMATION: Server startup in 739700 ms
 
  More than half of that time was spent starting the CA subsystem alone:
 
  INFORMATION: Deployment of configuration descriptor /etc/pki
  /pki-tomcat/Catalina/localhost/ca.xml has finished in 393,390 ms
 
  The whole (failed) IPA installation took about 38 minutes. Is this
  correct?
 
  It's possible the system was running out of entropy. You might want to
  install haveged or rngd. See:
  http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/
  https://www.digitalocean.com/community/tutorials/how-to-setup-additional-ent
  ropy-for-cloud-servers-using-haveged
 
  However, the system seems to be running very slowly in general. How
  powerful is this machine?
 
  Hi Endi
 
  the system is a banana pi system. Seems that this ARM CPU based system
  isn't
  suitable for FreeIPA
 
  The installation might still succeed if IPA doesn't have the 300s time
  limit. If you want to try, you probably can specify a larger
  startup_timeout in ~/.ipa/default.conf, or change the code in
  ipaplatform/redhat/services.py to wait indefinitely, and see what
  happens. I don't know if it will be usable though.
 
  --
  Endi S. Dewata
 
 
  Yersterday I did the installation of freeipa on my banana Pi with modifying
  the
  source file ipalib/constants.py: ('startup_timeout', 300). I changed it to
  900 s. And the setup process was successful! The start of the CA had a
  duration
  of 630s! But after the installation freeipa is usable on the banana Pi.
 
  Thanks to Endi for help.

 That's cool! Do you think that your experience from making it work could form
 a
 nice HOWTO article on

 http://www.freeipa.org/page/HowTos

 ? Maybe it would help others who would want to follow your example on FreeIPA
 at *Pi devices :-)

Of course, I can write this HowTo.-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

On Wed, Apr 08, 2015 at 09:25:33AM +0200, Chamambo Martin wrote:
 Good day 
 
 I am running FreeIPA, version: 4.1.0 and everything is working well except
 SUDO configuration.
 
 I have 3 questions
 
   1: I have configured the bare minimum sudo configuration without
 hostgroups and netgroups , just sudo commands and sudo command groups that
 have been added as sudo rules .this should work right
 2: I have centos 6.6 and redhat 6.6 clients using the sssd
 service  ,is that enough for sudo to work if the configs are as below 

Didn't you start exactly the same thread yesterday? :-)

Can you provide the sudo responder logs as we asked yesterday?

 
 
 cat /etc/nsswitch.conf
 
 sudoers: files sss
 
 cat /etc/sssd/sssd.conf
 
 [domain/ai.co.zw]
 
 debug_level=6
 cache_credentials = True
 krb5_store_password_if_offline = True
 ipa_domain = ai.co.zw
 id_provider = ipa
 auth_provider = ipa
 access_provider = ipa
 ipa_hostname = ironhide.ai.co.zw
 chpass_provider = ipa
 ipa_server = _srv_, cyclops.ai.co.zw
 ldap_tls_cacert = /etc/ipa/ca.crt
 
 [sssd]
 services = nss, sudo, pam, ssh
 config_file_version = 2
 
 
 domains = ai.co.zw
 [nss]
 homedir_substring = /home
 
 [pam]
 
 [sudo]
 
 [autofs]
 
 [ssh]
 
 
 
 
 
 
 -- 
 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] Slow logins on FreeIPA 4.1.2 (F21)

On Wed, Apr 08, 2015 at 10:11:01AM +0200, Martin (Lists) wrote:
 Am 07.04.2015 um 18:27 schrieb Simo Sorce:
  On Tue, 2015-04-07 at 17:57 +0200, Martin (Lists) wrote:
  Hallo
 
  attached you can find the data from krb_child.log. As far as I can see
  it, the three seconds are due to the communication with the kerberos
  server. (1.2.3.4 is my server).
  
  Do you experience the same latency if you kinit manually ?
  
  Simo.
  
 
 No, kinit completes almost instantly after entering the password.
 
 Martin

Can you run:
KRB5_TRACE=/dev/stderr kinit yourprinc@YOUR.REALM

So that we can compare with the krb5_child.log you sent earlier? I
wonder if SSSD talks to a KDC that is slower or far away from your
client..

-- 
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] Slow logins on FreeIPA 4.1.2 (F21)

2015-04-08 Thread Martin (Lists)

Am 08.04.2015 um 10:57 schrieb Jakub Hrozek:
  
 
 
  Most of the host can only communicate in the local net, which has not
  that much hosts (10). The wired ones are connected via GBit Network,
  wireless it is up to 150MBit. Server is a Xeon E3-1225 with 8GB Mem. All
  Systems have Fedora 21 installed

 Does it communicate with the same KDC as krb5_child?

Yep, same host, same port number. Currently I have only one IPA server
running. Replication is on my todo list though.

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] FreeIPA, version: 4.1.0 and sudo configuration

I have these logs and cant seem to make sense of them  


I have created the hostgroup mailservers and have added the sudo rule that
allows the users to execute sudo vim anyfile

(Wed Apr  8 09:58:45 2015) [sssd[be[ai.co.zw]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'IPA'
(Wed Apr  8 09:58:45 2015) [sssd[be[ai.co.zw]]] [be_resolve_server_process]
(0x0200): Found address for server cyclops.ai.co.zw: [41.57.64.54] TTL 300
(Wed Apr  8 09:58:45 2015) [sssd[be[ai.co.zw]]] [ipa_resolve_callback]
(0x0400): Constructed uri 'ldap://cyclops.ai.co.zw'
(Wed Apr  8 09:58:45 2015) [sssd[be[ai.co.zw]]] [write_pipe_handler]
(0x0400): All data has been sent!
(Wed Apr  8 09:58:47 2015) [sssd[be[ai.co.zw]]] [read_pipe_handler]
(0x0400): EOF received, client finished
(Wed Apr  8 09:58:47 2015) [sssd[be[ai.co.zw]]] [fo_set_port_status]
(0x0100): Marking port 0 of server 'cyclops.ai.co.zw' as 'working'
(Wed Apr  8 09:58:47 2015) [sssd[be[ai.co.zw]]] [set_server_common_status]
(0x0100): Marking server 'cyclops.ai.co.zw' as 'working'
(Wed Apr  8 09:58:47 2015) [sssd[be[ai.co.zw]]] [fo_set_port_status]
(0x0400): Marking port 0 of duplicate server 'cyclops.ai.co.zw' as 'working'
(Wed Apr  8 09:58:47 2015) [sssd[be[ai.co.zw]]] [switch_creds] (0x0200):
Switch user to [146820][146820].
(Wed Apr  8 09:58:47 2015) [sssd[be[ai.co.zw]]] [switch_creds] (0x0200):
Switch user to [0][0].
(Wed Apr  8 09:58:47 2015) [sssd[be[ai.co.zw]]]
[safe_remove_old_ccache_file] (0x0400): New and old ccache file are the
same, none will be deleted.
(Wed Apr  8 09:58:47 2015) [sssd[be[ai.co.zw]]] [be_pam_handler_callback]
(0x0100): Backend returned: (0, 0, NULL) [Success]
(Wed Apr  8 09:58:47 2015) [sssd[be[ai.co.zw]]] [be_pam_handler_callback]
(0x0100): Sending result [0][ai.co.zw]
(Wed Apr  8 09:58:47 2015) [sssd[be[ai.co.zw]]] [be_pam_handler_callback]
(0x0100): Sent result [0][ai.co.zw]
(Wed Apr  8 09:58:47 2015) [sssd[be[ai.co.zw]]] [child_sig_handler]
(0x0100): child [1794] finished successfully.
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [be_req_set_domain]
(0x0400): Changing request domain from [ai.co.zw] to [ai.co.zw]
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [be_pam_handler] (0x0100):
Got request with the following data
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
command: PAM_ACCT_MGMT
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
domain: ai.co.zw
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
user: admin
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
service: sudo
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
tty: /dev/pts/1
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
ruser: admin
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
rhost: 
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
authtok type: 0
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
newauthtok type: 0
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
priv: 0
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
cli_pid: 1793
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [sdap_access_send] (0x0400):
Performing access check for user [admin]
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [sdap_account_expired_rhds]
(0x0400): Performing RHDS access check for user [admin]
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with
[((objectClass=ipaHost)(fqdn=ironhide.ai.co.zw))][cn=accounts,dc=ai,dc=co,d
c=zw].
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [sdap_get_generic_ext_done]
(0x0400): Search result: Success(0), no errmsg set
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [sdap_has_deref_support]
(0x0400): The server supports deref method OpenLDAP
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [sdap_x_deref_search_send]
(0x0400): Dereferencing entry
[fqdn=ironhide.ai.co.zw,cn=computers,cn=accounts,dc=ai,dc=co,dc=zw] using
OpenLDAP deref
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [no
filter][fqdn=ironhide.ai.co.zw,cn=computers,cn=accounts,dc=ai,dc=co,dc=zw].
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [sdap_x_deref_parse_entry]
(0x0400): Got deref control
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [sdap_x_deref_parse_entry]
(0x0400): All deref results from a single control parsed
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [sdap_get_generic_ext_done]
(0x0400): Search result: Success(0), no errmsg set
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [ipa_hostgroup_info_done]
(0x0200): Dereferenced host group: mailservers
(Wed Apr  8 09:58:48 2015) [sssd[be[ai.co.zw]]] [ipa_hbac_service_info_next]
(0x0400): Sending request for next search base:

Re: [Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

On Wed, Apr 08, 2015 at 10:17:59AM +0200, Chamambo Martin wrote:
 I have this log after doing a debug_level=6 in the sudo section and have
 attached a txt file for the ldbsearch -H /var/lib/sss/db/cache_ai.co.zw.ldb 
 

 (Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
 (0x0200): Searching sysdb with
 [((objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=admin)(sud
 oUser=#146820)(sudoUser=%admins)(sudoUser=%trust
 admins)(sudoUser=%admins)(sudoUser=+*))((dataExpireTimestamp=1428480892)))
 ]
 (Wed Apr  8 10:14:52 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
 (0x0200): Searching sysdb with
 [((objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=admin)(sudoUser=#14682000
 00)(sudoUser=%admins)(sudoUser=%trust
 admins)(sudoUser=%admins)(sudoUser=+*)))]

The above are the cache searches sssd ran.

This is how the sudo rule looks in your cache:
# record 29 

   
dn: name=file-commands,cn=sudorules,cn=custom,cn=ai.co.zw,cn=sysdb  

   
cn: file-commands   

   
dataExpireTimestamp: 1428486013 

   
entryUSN: 28714 

   
name: file-commands 

   
objectClass: sudoRule   

   
originalDN: cn=file-commands,ou=sudoers,dc=ai,dc=co,dc=zw   

   
sudoCommand: /usr/bin/vim   

   
sudoCommand: /usr/bin/less  

   
sudoHost: +mailservers  

   
sudoRunAsGroup: ALL 

   
sudoRunAsUser: admin

   
sudoRunAsUser: chamambom

   
sudoRunAsUser: kamoyob  

   
sudoRunAsUser: kumalop  

   
sudoRunAsUser: machangeteb  

   
sudoRunAsUser: masaitit 

   
sudoRunAsUser: masvivic 

   
sudoRunAsUser: matangiraa

Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)

On Wed, Apr 08, 2015 at 10:43:10AM +0200, Martin (Lists) wrote:
 Am 08.04.2015 um 10:27 schrieb Jakub Hrozek:
  Can you run:
  KRB5_TRACE=/dev/stderr kinit yourprinc@YOUR.REALM
 
  So that we can compare with the krb5_child.log you sent earlier? I
  wonder if SSSD talks to a KDC that is slower or far away from your
  client..
 
 This is my trace from kinit:
 
 [2422] 1428482081.62208: AS key obtained for encrypted timestamp:
 aes256-cts/61D1
 [2422] 1428482081.62288: Encrypted timestamp (for 1428482081.868994):
 plain ***, encrypted ***
 [2422] 1428482081.62328: Preauth module encrypted_timestamp (2) (real)
 returned: 0/Success
 [2422] 1428482081.62342: Produced preauth for next request: 133, 2
 [2422] 1428482081.62379: Sending request (265 bytes) to MITTELERDE.DE
 [2422] 1428482081.62484: Sending initial UDP request to dgram 1.2.3.4:88
 [2422] 1428482081.201814: Received answer (740 bytes) from dgram 1.2.3.4:88
 [2422] 1428482081.201872: Response was from master KDC
 [2422] 1428482081.201905: Processing preauth types: 19
 [2422] 1428482081.201914: Selected etype info: etype aes256-cts, salt
 ***, params 
 [2422] 1428482081.201920: Produced preauth for next request: (empty)
 [2422] 1428482081.201929: AS key determined by preauth: aes256-cts/61D1
 [2422] 1428482081.201973: Decrypted AS reply; session key is:
 aes256-cts/C464
 [2422] 1428482081.201991: FAST negotiation: available
 [2422] 1428482081.202014: Initializing KEYRING:persistent:0:0 with
 default princ fr...@mittelerde.de
 [2422] 1428482081.202058: Removing fr...@mittelerde.de -
 krbtgt/mittelerde...@mittelerde.de from KEYRING:persistent:0:0
 [2422] 1428482081.202065: Storing fr...@mittelerde.de -
 krbtgt/mittelerde...@mittelerde.de in KEYRING:persistent:0:0
 [2422] 1428482081.202110: Storing config in KEYRING:persistent:0:0 for
 krbtgt/mittelerde...@mittelerde.de: fast_avail: yes
 [2422] 1428482081.202126: Removing fr...@mittelerde.de -
 krb5_ccache_conf_data/fast_avail/krbtgt\/MITTELERDE.DE\@MITTELERDE.DE@X-CACHECONF:
 from KEYRING:persistent:0:0
 [2422] 1428482081.202133: Storing fr...@mittelerde.de -
 krb5_ccache_conf_data/fast_avail/krbtgt\/MITTELERDE.DE\@MITTELERDE.DE@X-CACHECONF:
 in KEYRING:persistent:0:0
 [2422] 1428482081.202166: Storing config in KEYRING:persistent:0:0 for
 krbtgt/mittelerde...@mittelerde.de: pa_type: 2
 [2422] 1428482081.202177: Removing fr...@mittelerde.de -
 krb5_ccache_conf_data/pa_type/krbtgt\/MITTELERDE.DE\@MITTELERDE.DE@X-CACHECONF:
 from
 KEYRING:persistent:0:0
   

 
 [2422] 1428482081.202184: Storing fr...@mittelerde.de -
 krb5_ccache_conf_data/pa_type/krbtgt\/MITTELERDE.DE\@MITTELERDE.DE@X-CACHECONF:
 in
 KEYRING:persistent:0:0
   
   
 
 
 Most of the host can only communicate in the local net, which has not
 that much hosts (10). The wired ones are connected via GBit Network,
 wireless it is up to 150MBit. Server is a Xeon E3-1225 with 8GB Mem. All
 Systems have Fedora 21 installed

Does it communicate with the same KDC as krb5_child?

-- 
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] Slow logins on FreeIPA 4.1.2 (F21)

2015-04-08 Thread Martin (Lists)

Am 07.04.2015 um 18:27 schrieb Simo Sorce:
 On Tue, 2015-04-07 at 17:57 +0200, Martin (Lists) wrote:
 Hallo

 attached you can find the data from krb_child.log. As far as I can see
 it, the three seconds are due to the communication with the kerberos
 server. (1.2.3.4 is my server).
 
 Do you experience the same latency if you kinit manually ?
 
 Simo.
 

No, kinit completes almost instantly after entering the password.

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] FreeIPA, version: 4.1.0 and sudo configuration

I have done below and its giving me the correct results and at the moment
LET ME enable debugging in sudo itself and see if that will get me somewhere

[root@ironhide ~]# getent netgroup mailservers 
mailservers   (ironhide.ai.co.zw,-,ai.co.zw)
(alvin.ai.co.zw,-,ai.co.zw) (madagascar.ai.co.zw,-,ai.co.zw)
(nemo.ai.co.zw,-,ai.co.zw)
[root@ironhide ~]# 





-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com] 
Sent: Wednesday, April 08, 2015 10:35 AM
To: Chamambo Martin
Cc: freeipa-users@redhat.com; 'Lukas Slebodnik'
Subject: Re: [Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

On Wed, Apr 08, 2015 at 10:17:59AM +0200, Chamambo Martin wrote:
 I have this log after doing a debug_level=6 in the sudo section and 
 have attached a txt file for the ldbsearch -H 
 /var/lib/sss/db/cache_ai.co.zw.ldb
 

 (Wed Apr  8 10:14:52 2015) [sssd[sudo]] 
 [sudosrv_get_sudorules_query_cache]
 (0x0200): Searching sysdb with
 [((objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=admi
 n)(sud oUser=#146820)(sudoUser=%admins)(sudoUser=%trust
 admins)(sudoUser=%admins)(sudoUser=+*))((dataExpireTimestamp=1428480
 892)))
 ]
 (Wed Apr  8 10:14:52 2015) [sssd[sudo]] 
 [sudosrv_get_sudorules_query_cache]
 (0x0200): Searching sysdb with
 [((objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=admin)(sudoUser=#14
 682000
 00)(sudoUser=%admins)(sudoUser=%trust
 admins)(sudoUser=%admins)(sudoUser=+*)))]

The above are the cache searches sssd ran.

This is how the sudo rule looks in your cache:
# record 29

dn: name=file-commands,cn=sudorules,cn=custom,cn=ai.co.zw,cn=sysdb

cn: file-commands

dataExpireTimestamp: 1428486013

entryUSN: 28714

name: file-commands

objectClass: sudoRule

originalDN: cn=file-commands,ou=sudoers,dc=ai,dc=co,dc=zw

sudoCommand: /usr/bin/vim

sudoCommand: /usr/bin/less

sudoHost: +mailservers

sudoRunAsGroup: ALL

sudoRunAsUser: admin

sudoRunAsUser: chamambom

sudoRunAsUser: kamoyob

sudoRunAsUser: kumalop

sudoRunAsUser: machangeteb

sudoRunAsUser: masaitit

sudoRunAsUser: masvivic

sudoRunAsUser: matangiraa

sudoRunAsUser: nyahumap

sudoRunAsUser: pedzisail

sudoRunAsUser: tayengwaj

sudoUser: ALL

distinguishedName:
name=file-commands,cn=sudorules,cn=custom,cn=ai.co.zw,cn=sy

 sdb

 (Wed Apr  8 10:14:52 2015) [sssd[sudo]] 
 [sudosrv_get_sudorules_from_cache]
 (0x0400): Returning 1 rules for [ad...@ai.co.zw]

And here we see that the sudo rule was returned from SSSD to sudo. But then
in sudo, it didn't match for some reason. I expect it's because of the
netgroup, can you check if nisdomainname is really set correctly and getent
netgroup mailservers reports the FQDN of your client?

Also, you can enable debugging in sudo itself. See man sudo.conf and search
for the option Debug. That will show you how exactly sudo matches the
rules.


 (Wed Apr  8 10:15:02 2015) [sssd[sudo]] [client_recv] (0x0200): Client 
 disconnected!

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Setup of freeipa 4.1.3 failed

On 04/08/2015 07:57 AM, Markus Roth wrote:
 
 Endi Sukma Dewata edew...@redhat.com hat am 1. April 2015 um 23:56
 geschrieben:


 On 4/1/2015 4:29 PM, Markus Roth wrote:
 Am Mittwoch, 1. April 2015, 16:04:54 schrieben Sie:
 On 4/1/2015 11:56 AM, Endi Sukma Dewata wrote:
 On 03/31/2015 01:54 PM, Markus Roth wrote:
 Hi all,

 I want setup freeipa 4.1.3 on a fresh installed fedora 21.

 The ipa-server-install shows the following output:
 ...

 Done configuring directory server (dirsrv).
 Configuring certificate server (pki-tomcatd): Estimated time 3
 minutes 30
 seconds

 [1/27]: creating certificate server user
 [2/27]: configuring certificate server instance
 [3/27]: stopping certificate server instance to update CS.cfg
 [4/27]: backing up CS.cfg
 [5/27]: disabling nonces
 [6/27]: set up CRL publishing
 [7/27]: enable PKIX certificate path discovery and validation
 [8/27]: starting certificate server instance
 [error] RuntimeError: CA did not start in 300.0s

 CA did not start in 300.0s

 The ipa server install log shows this:

 2015-03-31T17:39:35Z DEBUG The CA status is: check interrupted
 2015-03-31T17:39:35Z DEBUG Waiting for CA to start...

 ...

 I uninstalled the ipa server completely several times and installed
 it again.
 But it always stops at the same step with the setup.

 Can anybody help?

 Based on the IPA install log alone it looks like the DS is already
 started, and the Dogtag is already started too in step [3/27]. It's the
 restart on step [8/27] that is failing.

 We will need to see the Dogtag debug log in order to know if Dogtag is
 indeed failing to restart or the installer for some reason cannot
 connect to Dogtag.

 Hi Markus,

 Based on the logs that you sent me, the Dogtag took a really long time
 to start:

 INFORMATION: Server startup in 739700 ms

 More than half of that time was spent starting the CA subsystem alone:

 INFORMATION: Deployment of configuration descriptor /etc/pki
 /pki-tomcat/Catalina/localhost/ca.xml has finished in 393,390 ms

 The whole (failed) IPA installation took about 38 minutes. Is this correct?

 It's possible the system was running out of entropy. You might want to
 install haveged or rngd. See:
 http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/
 https://www.digitalocean.com/community/tutorials/how-to-setup-additional-ent
 ropy-for-cloud-servers-using-haveged

 However, the system seems to be running very slowly in general. How
 powerful is this machine?

 Hi Endi

 the system is a banana pi system. Seems that this ARM CPU based system isn't
 suitable for FreeIPA

 The installation might still succeed if IPA doesn't have the 300s time
 limit. If you want to try, you probably can specify a larger
 startup_timeout in ~/.ipa/default.conf, or change the code in
 ipaplatform/redhat/services.py to wait indefinitely, and see what
 happens. I don't know if it will be usable though.

 --
 Endi S. Dewata

  
 Yersterday I did the installation of freeipa on my banana Pi with modifying 
 the
 source file ipalib/constants.py:('startup_timeout', 300). I changed it to
 900 s. And the setup process was successful! The start of the CA had a 
 duration
 of 630s! But after the installation freeipa is usable on the banana Pi.
  
 Thanks to Endi for help.

That's cool! Do you think that your experience from making it work could form a
nice HOWTO article on

http://www.freeipa.org/page/HowTos

? Maybe it would help others who would want to follow your example on FreeIPA
at *Pi devices :-)

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA server in Docker container improved

2015-04-08 Thread Mark Heslin



On 04/08/2015 08:42 AM, Jan Pazdziora wrote:

Hello world!

The ability to run FreeIPA server in a container was recently
improved by adding support for storing the server configuration and
data in a volume, making it easier to backup the server, upgrade it to
newer versions, as well as adding the ability to start a container
as a replica of existing (containerized or non-containerized) IPA
server.

Using IPA in a container can be an easy way to try IPA or test things
on different OSes (there are multiple per-OS branches in the GitHub
repo and multiple images built), as well as running IPA on a machine
where it would otherwise clash with other software. It it still
an unsupported release but working in multiple tests on our side, so
we encourage our community members to try it out.

We will welcome your comments about your experience with the code at

https://github.com/adelton/docker-freeipa

or automated build images at

https://registry.hub.docker.com/u/adelton/freeipa-server/

README was amended to describe the new usage options.


Hi Jan,

Nice work. Has this been tested on Atomic host yet (just curious)?

-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

[Freeipa-users] Private key management

2015-04-08 Thread Andrey Ptashnik

Hello Team,

I know that FreeIPA server supports management of public keys for each user and 
it is a very convenient feature.
Are there any possible way to manage private keys as well including features 
like re-issuing the key pair if it gets compromised?

Regards,
Andrey

-- 
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] Promoting a replica to a FreeIPA server without primary server

2015-04-08 Thread Прохоров Сергей

Hello, I have self-signed freeipa replica. The problem is that I lose my 
freeipa primary server after hdd error.
Now I need to create new replication server but I can't without primary 
server. I read this documentation and a lot of community correspondence 
but don't find my issue:


http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html
http://www.freeipa.org/page/Howto/Promoting_a_self-signed_FreeIPA_CA

How can I resolve it or migrate my kerberos/ldap schema to the new 
primary server?
I'm using ipa-server-3.0.0-42.el6.x86_64 from base oracle linux 6.5 
repository.


--
Best regards,
Prokhorov Sergey
Senior System Engineer
 of INTECH LTD
e-mail: sprokho...@intech-global.com

--
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] ID Ranges in FreeIPA

2015-04-08 Thread Coy Hile


Hi all,

When I installed FreeIPA, it created a default ID range (of which user admin
is currently the only user existing).  Through the UI, I've found that one can
create additional ranges (and that the ipa tools will complain if a user has a
uid assigned manually that falls outside the defined range.)  That  
makes sense.
Is there a way that one can instruct the tools which particular range  
it should
use for a particular operation?  Say one wants different classes of  
users to be
allocated from different ranges (For example, faculty/staff vs  
students, FTE vs
contractors, or 'eyeball' users vs role accounts like jdoe vs  
appteambuildbot)?


Thanks,

-c
--
Coy Hile
coy.h...@coyhile.com

--
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] Accident upgrade 3.3 to 4.1

2015-04-08 Thread thierry bordaz

On 04/08/2015 02:19 PM, Alexander Frolushkin wrote:

On one of accidently upgraded server I have following error in dirsrv logs:

[08/Apr/2015:13:24:12 +0300] connection - conn=1095 fd=131 Incoming BER Element
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize
attribute in cn=config to increase.
[08/Apr/2015:13:24:12 +0300] connection - conn=1094 fd=124 Incoming BER Element
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize
attribute in cn=config to increase.
[08/Apr/2015:13:24:12 +0300] connection - conn=1096 fd=124 Incoming BER Element
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize
attribute in cn=config to increase.
[08/Apr/2015:13:24:12 +0300] connection - conn=1097 fd=131 Incoming BER Element
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize
attribute in cn=config to increase.

This message is logged if the received message was too large. But here max size
was 200Mb.
I can not imagine a such large message.
Being log at the same second, it could be transient error. Have you seen others
messages like these ?

Yes, it still here.

[08/Apr/2015:14:55:01 +0300] connection - conn=1125 fd=130 Incoming BER Element
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize
attribute in cn=config to increase.
[08/Apr/2015:14:55:01 +0300] connection - conn=1124 fd=126 Incoming BER Element
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize
attribute in cn=config to increase.
[08/Apr/2015:14:55:01 +0300] connection - conn=1126 fd=126 Incoming BER Element
was too long, max allowable is 209715200 bytes. Change the nsslapd-maxbersize
attribute in cn=config to increase.

Those logs mean the connection (e.g. conn=1125) got closed.
Would you grep conn=1125 in access log ?

[08/Apr/2015:14:55:26 +0300] attrlist_replace - attr_replace (nsslapd-referral,
ldap://cnt-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:14:55:26 +0300] attrlist_replace - attr_replace (nsslapd-referral,
ldap://cnt-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:14:55:26 +0300] attrlist_replace - attr_replace (nsslapd-referral,
ldap://cnt-rhidm01.unix.ad.com:389/o%3Dipaca) failed.

[08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace (nsslapd-referral,
ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace (nsslapd-referral,
ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace (nsslapd-referral,
ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:13:25:15 +0300] attrlist_replace - attr_replace (nsslapd-referral,
ldap://vlg-rhidm02.unix.ad.com:389/o%3Dipaca) failed.
[08/Apr/2015:13:25:15 +0300] attrlist_replace - attr_replace (nsslapd-referral,
ldap://vlg-rhidm02.unix.ad.com:389/o%3Dipaca) failed.

Here it is likely trigger by RUV containing duplicated values (multiple replica
install ?). You may have to use cleanruv after the upgrade.
ipa-replica-manage list-ruv and ipa-replica-manager clean-ruv

Do You mean we need to upgrade all 3.3.3 IPA servers to 4.1 first? Or this can
be cleaned right now on remaining servers?

BTW:
# ipa-replica-manage list-ruv
Directory Manager password:

sib-rhidm03.unix.ad.com:389: 5
dv-rhidm01.unix.ad.com:389: 17
sib-rhidm02.unix.ad.com:389: 3
sib-rhidm01.unix.ad.com:389: 4
url-rhidm01.unix.ad.com:389: 6
url-rhidm02.unix.ad.com:389: 7

nw-rhidm01.unix.ad.com:389: 19

This message is harmless. It means that some values of nsds50ruv in the
RUV have identical referral.
This should not occur, but replication is smart enough to just log this
warning and continue working.

I would not recommend cleanup right now. Just clarification of the status.
Would you send all the ruv values returned by 'list-ruv' (here there is
no duplicate).

thanks
theirry

Информация в этом сообщении предназначена исключительно для конкретных лиц,
которым она адресована. В сообщении может содержаться конфиденциальная
информация, которая не может быть раскрыта или использована кем-либо, кроме
адресатов. Если вы не адресат этого сообщения, то использование, переадресация,
копирование или распространение содержания сообщения или его части незаконно и
запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно
сообщите отправителю об этом и удалите со всем содержимым само сообщение и
любые возможные его копии и приложения.

The information contained in this communication is intended solely for the use
of the individual or entity to whom it is addressed and others authorized to
receive it. It may contain confidential or legally privileged information. The
contents may not be disclosed or used by anyone other than the addressee. If
you are not the intended recipient(s), any use, disclosure, copying,
distribution or any action taken or

Re: [Freeipa-users] ID Ranges in FreeIPA

Coy Hile wrote:
 Hi all,
 
 When I installed FreeIPA, it created a default ID range (of which user
 admin
 is currently the only user existing).  Through the UI, I've found that
 one can
 create additional ranges (and that the ipa tools will complain if a user
 has a
 uid assigned manually that falls outside the defined range.)  That makes
 sense.
 Is there a way that one can instruct the tools which particular range it
 should
 use for a particular operation?  Say one wants different classes of
 users to be
 allocated from different ranges (For example, faculty/staff vs students,
 FTE vs
 contractors, or 'eyeball' users vs role accounts like jdoe vs
 appteambuildbot)?
 

No. And right now there is little correlation between the ranges
assigned when users and groups are created and the ID range. An ID range
is created for the user/group POSIX range, but any changes made to it
have no affect on the actual values assigned (IIRC there is a ticket to
make this immutable to avoid confusion).

Users and groups ids are generated using the Distributed Numeric Plugin
(DNA) in 389-ds which has its own configuration in cn=config.

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] FreeIPA server in Docker container improved

2015-04-08 Thread Jan Pazdziora


Hello world!

The ability to run FreeIPA server in a container was recently
improved by adding support for storing the server configuration and
data in a volume, making it easier to backup the server, upgrade it to
newer versions, as well as adding the ability to start a container
as a replica of existing (containerized or non-containerized) IPA
server.

Using IPA in a container can be an easy way to try IPA or test things
on different OSes (there are multiple per-OS branches in the GitHub
repo and multiple images built), as well as running IPA on a machine
where it would otherwise clash with other software. It it still
an unsupported release but working in multiple tests on our side, so
we encourage our community members to try it out.

We will welcome your comments about your experience with the code at

https://github.com/adelton/docker-freeipa

or automated build images at

https://registry.hub.docker.com/u/adelton/freeipa-server/

README was amended to describe the new usage options.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
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] Private key management

2015-04-08 Thread Andrey Ptashnik

It looks like Vault is the functionality I was looking for.

Thank you Rob and Dmitri for your responses.

Regards,
Andrey







On 4/8/15, 5:59 PM, Rob Crittenden rcrit...@redhat.com wrote:

Andrey Ptashnik wrote:
 Hello Team,
 
 I know that FreeIPA server supports management of public keys for each
 user and it is a very convenient feature.
 Are there any possible way to manage private keys as well including
 features like re-issuing the key pair if it gets compromised?

I assume you mean SSH keys. IPA doesn't issue keys, so re-issuing is out
and AFAIK no plans to do this.

There are plans for a Key Recovery vault which can store a private key,
see https://fedorahosted.org/freeipa/ticket/3872 . This doesn't help in
the case of compromise but it does mean that keys aren't lost.

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] Expired Certs on 3.0.0 IPA host

2015-04-08 Thread John Williams

I'm looking at the following link for recovering expired certificates on 
FreeeIPA 3.0.0:
https://www.freeipa.org/page/Howto/CA_Certificate_Renewal
  
Problem is when Iook inside my /etc/pki-ca/CS.cfg file for a subsystemCert I do 
not find one.  I see the other three:
auditSigningCert cert-pki-ca =  updatedocspSigningCert cert-pki-ca = 
updatedServer-Cert cert-pki-ca  = no cert heresubsystemCert cert-pki-ca = 
updated 
Has anyone ever run across this?  Any suggestions or hints would be 
appreciated.  If I role the clock back on my system I can login to IPA, but if 
the time is updated, I cannot login.
Please help. 
-- 
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] Replica with external ca + custom subject in certificate

2015-04-08 Thread James James

It's a little bit more clear. Thanks.

I have created a new ipa 4.1 replica but when I want run :

# ipa-cacert-manage renew --self-signed

I've got this message :

[root@ipa-devel-centos7 ~]# ipa-cacert-manage renew --self-signed
CA is not configured on this system

If I want to install the CA I've got this message :

[root@ipa-devel-centos7 system]# ipa-ca-install --password=mypassorwd -U
CA is already installed.

Should I have to promote the replica to a standalone master before
installing the CA ?

Any hints will be appreciated...


James


2015-04-08 7:27 GMT+02:00 Jan Cholasta jchol...@redhat.com:

 Dne 7.4.2015 v 15:31 Martin Kosek napsal(a):

 On 04/07/2015 02:08 PM, James James wrote:

 I will try to give a better explanation :


 I have a CentOS 6.6 with ipa 3.0 named ipa-master. ipa-master has been
 installed with an external CA about 3 years ago and I will have to renew
 the certificate soon.

   I have created a test server (ipa-dev) with the same configuration
 (centos
 6.6 and ipa 3.0) to test the renewal process. I want the new ipa-dev
 sever
 to be installed with an external CA.

 In the same time my external CA has changed and wants the emailAddress
 field in the certificate request 's subject.


 CSR during installation with external CA is produced by Dogtag, so you are
 constrained with the options and capabilities provided by
 ipa-server-install.
 Maybe it would be possible to modify the CSR and update the Subject
 manually,
 but I expect it would crash the installer later (JanC may know more
 (CCed))


 The subject name identifies the CA in server (and other) certificates. If
 you change it, you break the trust chain from the CA certificate to the
 server certificates and that will break all SSL in IPA.


  If it is not possible to add emailAddress in the subject, is it possible
 to
 migrate my ipa-master CA system from an external CA to a CA-less or
 self-signed CA ?


 It is, with ipa-cacert-manage - see links below.


 You can change your external CA to self-signed CA in IPA 4.1 or newer by
 running:

 # ipa-cacert-manage renew --self-signed

 You can't change external CA to CA-less.



  Thanks.

 2015-04-07 13:48 GMT+02:00 Martin Kosek mko...@redhat.com:

  On 04/07/2015 01:44 PM, James James wrote:

 ok.

 Is there a way to migrate from an external CA to a CA-less or a

 self-signed

 CA  ?


 Yes, you can use ipa-cacert-manage tool introduced in FreeIPA 4.1.0:

 https://www.freeipa.org/page/Howto/CA_Certificate_Renewal
 https://www.freeipa.org/page/V4/CA_certificate_renewal

 (Although I am still not sure about your use case and if this would help
 you)


 2015-04-07 12:51 GMT+02:00 Martin Kosek mko...@redhat.com:

  On 04/03/2015 11:39 AM, James James wrote:

 Hello,

 I want to initialize a new replica with an external CA. My
 Certificate
 Authority wants a CSR with the field emailAddress in the subject
 like :

 /C=FR/O=TESTO/OU=TESTOU/CN=*.example.com/emailAddress=n...@none.com


 I am not a bit confused. Do you plan to have FreeIPA *without* a CA or
 with own
 CA signed by external CA?

 FreeIPA supports these kinds of setups right now:
 http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure

How can I do with the ipa-server-install command ?  I have been
 trying

 for

 few days but I still can't.

 Thanks for your help.


 CCing Honza who should know the definitive answer. However, FreeIPA
 was

 not

 very flexible in configuring special subjects for it's CA certificate

 (i.e.

 cn=Certificate Authority, ou=...) or hosts in case of CA-less setup.








 --
 Jan Cholasta

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Freeipa 4 and AD

2015-04-08 Thread Aric Wilisch

I’m having issues with getting my RHEL 7 server running Freeipa 4 to join my 
Windows 2012R2 domain. 

DNS checks out fine. When I try to establish the join I get the below listed 
errors popping up. I’ve tried both creating the trust from Freeipa and just 
this morning I setup the trust on the AD side and tried to use the 
—trust-secret option. There are no firewalls between them, but they are on 
different subnets. 

Any help would be great. This is holding up a project and I’m not able to 
figure out what’s going on. 

Thanks in advance.

finddcs: Skipping DC 10.32.145.134 with server_type=0xf17c - required 
0x0119
finddcs: No matching CLDAP server found
[Wed Apr 08 12:39:48.359684 2015] [:error] [pid 8402] ipa: INFO: 
[jsonserver_session] ad...@preprod.fioptics.int 
mailto:ad...@preprod.fioptics.int: trust_add(u'fioptics.int', 
http://trust_add%28u%27fioptics.int%27%2c/ trust_type=u'ad', 
realm_server=u'ppad01', trust_secret=u'', all=False, raw=False, 
version=u'2.114'): NotFound

Regards,
--
Aric Wilisch
awili...@gmail.com




-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Freeipa 4 and AD

2015-04-08 Thread Alexander Bokovoy


On Wed, 08 Apr 2015, Aric Wilisch wrote:

I’m having issues with getting my RHEL 7 server running Freeipa 4 to
join my Windows 2012R2 domain.

DNS checks out fine. When I try to establish the join I get the below
listed errors popping up. I’ve tried both creating the trust from
Freeipa and just this morning I setup the trust on the AD side and
tried to use the —trust-secret option. There are no firewalls between
them, but they are on different subnets.

Any help would be great. This is holding up a project and I’m not able
to figure out what’s going on.

Thanks in advance.

finddcs: Skipping DC 10.32.145.134 with server_type=0xf17c - required 0x0119 

You need to establish trust using a PDC of the forest root domain.
Your DC is not a PDC (lacks bit 1 in the server type), thus it is not
possible to establish cross-forest trust. This is Active Directory
requirement.


--
/ 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] Private key management

Andrey Ptashnik wrote:
 Hello Team,
 
 I know that FreeIPA server supports management of public keys for each
 user and it is a very convenient feature.
 Are there any possible way to manage private keys as well including
 features like re-issuing the key pair if it gets compromised?

I assume you mean SSH keys. IPA doesn't issue keys, so re-issuing is out
and AFAIK no plans to do this.

There are plans for a Key Recovery vault which can store a private key,
see https://fedorahosted.org/freeipa/ticket/3872 . This doesn't help in
the case of compromise but it does mean that keys aren't lost.

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] Private key management


On 04/08/2015 11:31 AM, Andrey Ptashnik wrote:

Hello Team,

I know that FreeIPA server supports management of public keys for each 
user and it is a very convenient feature.


First of all IPA does not support user certs yet. It supports SSH public 
keys if this is what you are referring to.


Are there any possible way to manage private keys as well including 
features like re-issuing the key pair if it gets compromised?


I am not sure how you envision the management aspect.
If a private key gets compromised you need to generate the new private 
key and upload your public key to IPA (if we are talking about SSH) or 
use CA to sign a CSR if we are talking about certs that will be 
supported for users in 4.2.


The only management for private keys that one can envision is being able 
to escrow them.

IPA will provide a vault facility for that matter in 4.2.

What other use cases do you have in mind?




Regards,
Andrey






--
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] Freeipa 4 and AD


On 04/08/2015 12:42 PM, Aric Wilisch wrote:
I'm having issues with getting my RHEL 7 server running Freeipa 4 to 
join my Windows 2012R2 domain.


DNS checks out fine. When I try to establish the join I get the below 
listed errors popping up. I've tried both creating the trust from 
Freeipa and just this morning I setup the trust on the AD side and 
tried to use the ---trust-secret option. There are no firewalls 
between them, but they are on different subnets.


Any help would be great. This is holding up a project and I'm not able 
to figure out what's going on.


Thanks in advance.

finddcs: Skipping DC 10.32.145.134 with server_type=0xf17c - 
required 0x0119

finddcs: No matching CLDAP server found
[Wed Apr 08 12:39:48.359684 2015] [:error] [pid 8402] ipa: INFO: 
[jsonserver_session] ad...@preprod.fioptics.int 
mailto:ad...@preprod.fioptics.int: trust_add(u'fioptics.int', 
http://trust_add%28u%27fioptics.int%27%2C/trust_type=u'ad', 
realm_server=u'ppad01', trust_secret=u'', all=False, 
raw=False, version=u'2.114'): NotFound


Regards,
--
Aric Wilisch
awili...@gmail.com mailto:awili...@gmail.com








It seems that IPA could not detect the valid AD DC.

What is the version and the type of the DC with mentioned IP? Is it a 
primary DC? If not where is the primary one?



--
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] Promoting a replica to a FreeIPA server without primary server

Прохоров Сергей wrote:
 Hello, I have self-signed freeipa replica. The problem is that I lose my
 freeipa primary server after hdd error.
 Now I need to create new replication server but I can't without primary
 server. I read this documentation and a lot of community correspondence
 but don't find my issue:
 
 http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html

Ouch. This is really old.

 http://www.freeipa.org/page/Howto/Promoting_a_self-signed_FreeIPA_CA

I assume you can't do this because the original host is lost, right?

 How can I resolve it or migrate my kerberos/ldap schema to the new
 primary server?
 I'm using ipa-server-3.0.0-42.el6.x86_64 from base oracle linux 6.5
 repository.
 

Promote is such a terrible word, I really wish I'd never used it.

Every IPA master is a equal, some are just more equal than others. The
key bit that distinguishes them is whether there is a CA installed. The
other bit has to do with CRL generation and renewal which in your
version can only be done on one host (neither of which apply to
--selfsign anyway).

If you installed originally using --selfsign and that initial host is
gone and you have no backups you're in for some trouble. It is a single
point of failure and the reason we no longer support it. The docs
contain a bit of warning about that.

You mention migrating. What new primary server?

So I'd start digging around to see if you have the original CA private
key somewhere. The end of the IPA server install would have recommending
backing up cacert.p12.

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] Promoting a replica to a FreeIPA server without primary server


On 04/08/2015 07:12 AM, Прохоров Сергей wrote:
Hello, I have self-signed freeipa replica. The problem is that I lose 
my freeipa primary server after hdd error.
Now I need to create new replication server but I can't without 
primary server. I read this documentation and a lot of community 
correspondence but don't find my issue:


http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html 


http://www.freeipa.org/page/Howto/Promoting_a_self-signed_FreeIPA_CA

How can I resolve it or migrate my kerberos/ldap schema to the new 
primary server?
I'm using ipa-server-3.0.0-42.el6.x86_64 from base oracle linux 6.5 
repository.




By self-signed you mean you had a self signed CA as a part of the first 
IPA server, right?

Did you install replica with the CA component or not?

If you lost your first server that had CA and have replica that does not 
have CA you are not in a best situation.
There are several options that you can explore. But before we dive into 
that please answer following questions.


1. Is the situation described correctly?
2. Do you take advantage of the cert capabilities of IPA?
3. Did you make any backups of the first server?

--
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] krb5kdc: Server error


On 04/08/2015 06:54 AM, Ben .T.George wrote:

HI Traino,

thanks for the info

i have checked the hots and confirmed that entry was ip FQDN 
Alias format


And the DNS everything is working

[root@kwtprsolipa01 slapd-SUN-LOCAL]# for i in _ldap._tcp 
_kerberos._tcp _kerberos._udp _kerberos-master._tcp 
_kerberos-master._udp _ntp._udp; do echo ; dig @mha.local 
${i}.SUN.LOCAL srv +nocmd +noquestion +nocomments +nostats +noaa 
+noadditional +noauthority; done | egrep -v ^; | egrep _


_ldap._tcp.SUN.LOCAL.   21965   IN  SRV 0 100 389 
kwtprsolipa01.sun.local.
_kerberos._tcp.SUN.LOCAL. 1957  IN  SRV 0 100 88 
kwtprsolipa01.sun.local.
_kerberos._udp.SUN.LOCAL. 86400 IN  SRV 0 100 88 
kwtprsolipa01.sun.local.
_kerberos-master._tcp.SUN.LOCAL. 86400 IN SRV   0 100 88 
kwtprsolipa01.sun.local.
_kerberos-master._udp.SUN.LOCAL. 9112 IN SRV0 100 88 
kwtprsolipa01.sun.local.
_ntp._udp.SUN.LOCAL.86400   IN  SRV 0 100 123 
kwtprsolipa01.sun.local.


[root@kwtprsolipa01 slapd-SUN-LOCAL]# for i in _ldap._tcp 
_kerberos._tcp _kerberos._udp _kerberos-master._tcp 
_kerberos-master._udp _ntp._udp; do echo ; dig @mha.local 
${i}.MHA.LOCAL srv +nocmd +noquestion +nocomments +nostats +noaa 
+noadditional +noauthority; done | egrep -v ^; | egrep _


_ldap._tcp.MHA.LOCAL.   600 IN  SRV 0 100 389 
dxbprdc002.mha.local.
_ldap._tcp.MHA.LOCAL.   600 IN  SRV 0 100 389 
kwtprdc001.mha.local.
_ldap._tcp.MHA.LOCAL.   600 IN  SRV 0 100 389 
dxbprdc001.mha.local.
_ldap._tcp.MHA.LOCAL.   600 IN  SRV 0 100 389 
rusmosprdc002.mha.local.
_ldap._tcp.MHA.LOCAL.   600 IN  SRV 0 100 389 
kwtprdc002.mha.local.
_kerberos._tcp.MHA.LOCAL. 600   IN  SRV 0 100 88 
kwtprdc001.mha.local.
_kerberos._tcp.MHA.LOCAL. 600   IN  SRV 0 100 88 
dxbprdc002.mha.local.
_kerberos._tcp.MHA.LOCAL. 600   IN  SRV 0 100 88 
dxbprdc001.mha.local.
_kerberos._tcp.MHA.LOCAL. 600   IN  SRV 0 100 88 
kwtprdc002.mha.local.
_kerberos._udp.MHA.LOCAL. 600   IN  SRV 0 100 88 
kwtprdc002.mha.local.
_kerberos._udp.MHA.LOCAL. 600   IN  SRV 0 100 88 
dxbprdc002.mha.local.
_kerberos._udp.MHA.LOCAL. 600   IN  SRV 0 100 88 
kwtprdc001.mha.local.
_kerberos._udp.MHA.LOCAL. 600   IN  SRV 0 100 88 
dxbprdc001.mha.local.


[root@kwtprsolipa01 slapd-SUN-LOCAL]# host 172.16.99.99
99.99.16.172.in-addr.arpa domain name pointer kwtprsolipa01.sun.local.
[root@kwtprsolipa01 slapd-SUN-LOCAL]# host kwtprsolipa01.sun.local
kwtprsolipa01.sun.local has address 172.16.99.99

[root@kwtprsolipa01 slapd-SUN-LOCAL]# host mha.local
mha.local has address 172.16.98.171
mha.local has address 172.16.100.180
mha.local has address 10.10.10.11
mha.local has address 10.10.10.10


[root@kwtprsolipa01 slapd-SUN-LOCAL]# dig kwtprsolipa01.sun.local

;  DiG 9.9.4-RedHat-9.9.4-18.el7  kwtprsolipa01.sun.local
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 23767
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;kwtprsolipa01.sun.local.   IN  A

;; ANSWER SECTION:
kwtprsolipa01.sun.local. 38 IN  A 172.16.99.99

;; Query time: 0 msec
;; SERVER: 172.16.100.180#53(172.16.100.180)
;; WHEN: Wed Apr 08 13:54:02 AST 2015
;; MSG SIZE  rcvd: 68



On Wed, Apr 8, 2015 at 1:27 PM, Traiano Welcome trai...@gmail.com 
mailto:trai...@gmail.com wrote:


Hi Ben



On Wed, Apr 8, 2015 at 12:39 PM, Ben .T.George
bentech4...@gmail.com mailto:bentech4...@gmail.com wrote:
 HI

 i am getting krb5kdc: Server error on ligs:

 krb5kdc: Server error - while fetching master key K/M for realm
SUN.LOCAL

 and the ipactl status is taking long time. Web interface is not
able to
 athenticate.

 If i issue ipactl restart, noting is happening

 to solve this issue currently i am restarting full server..


 How can i fix this?


Check the tail-end of  this thread:

https://www.redhat.com/archives/freeipa-users/2015-April/msg00011.html

You may want to begin by checking /etc/hosts for the right format (ip
address fqdn hostname).
DNS is probably the very next thing you want to check... thoroughly.






 Regards,
 Ben

 --
 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







Anything in the DS logs?
The DS might not be starting because there is not enough space or some 
file corruption.


--
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] Expired Certs on 3.0.0 IPA host

John Williams wrote:
 I'm looking at the following link for recovering expired certificates on
 FreeeIPA 3.0.0:
 
 https://www.freeipa.org/page/Howto/CA_Certificate_Renewal
  
 
 Problem is when Iook inside my /etc/pki-ca/CS.cfg file for a
 subsystemCert I do not find one.  I see the other three:
 
 auditSigningCert cert-pki-ca =  updated
 ocspSigningCert cert-pki-ca = updated
 Server-Cert cert-pki-ca  = no cert here
 subsystemCert cert-pki-ca = updated 
 
 Has anyone ever run across this?  Any suggestions or hints would be
 appreciated.  If I role the clock back on my system I can login to IPA,
 but if the time is updated, I cannot login.
 
 Please help. 

Why do you need this value? For the record it is ca.sslserver.cert.

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] Configuring RHEL 5 clients for automatic failover of servers

2015-04-08 Thread Guertin, David S.

I have a mixed environment of RHEL 5 and RHEL 6 clients, and three RHEL 7 IPA 
servers (one master and two duplicates). I'm trying to ensure that if one 
server goes down, the remain server(s) will still allow logins. With the RHEL 6 
clients this is easy -- the line

  ipa_server = _srv_, server1.ipa.middlebury.edu

in /etc/sssd/sssd.conf does this with the _srv_ entry, and everything is fine.

But with the RHEL 5 clients, this doesn't work. If server 1 goes down, logins 
fail. Since RHEL 5 is using LDAP, I figured it was probably in the ldap_uri 
line in the sssd.conf file. I discovered that I could add multiple servers, 
which I did:

  ldap_uri = ldap://server1.ipa.middlebury.edu, 
ldap://server2.ipa.middlebury.edu, ldap://server3.ipa.middlebury.edu

But this still failed. However, if I do something similar in /etc/ldap.conf:

  uri ldap://server1.ipa.middlebury.edu ldap://server2.ipa.middlebury.edu 
ldap://server3.ipa.middlebury.edu

then logins work. In fact, I don't even need the change in sssd.conf. I can put 
that back the way it was, and logins still work. It's only the line in 
/etc/ldap.conf that seems to be necessary.

So, I have two questions:

1. Am I understanding this correctly?

2. If so, is there a way to automate this so that when I run ipa-client-install 
on my RHEL 5 clients, they get the correct LDAP settings from the beginning, 
and I don't have to go and manually edit the ldap.conf file?

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] Configuring RHEL 5 clients for automatic failover of servers

Guertin, David S. wrote:
 I have a mixed environment of RHEL 5 and RHEL 6 clients, and three RHEL
 7 IPA servers (one master and two duplicates). I'm trying to ensure that
 if one server goes down, the remain server(s) will still allow logins.
 With the RHEL 6 clients this is easy -- the line
 
  
 
   ipa_server = _srv_, server1.ipa.middlebury.edu
 
  
 
 in /etc/sssd/sssd.conf does this with the _srv_ entry, and everything is
 fine.
 
  
 
 But with the RHEL 5 clients, this doesn't work. If server 1 goes down,
 logins fail. Since RHEL 5 is using LDAP, I figured it was probably in
 the ldap_uri line in the sssd.conf file. I discovered that I could add
 multiple servers, which I did:
 
  
 
   ldap_uri = ldap://server1.ipa.middlebury.edu,
 ldap://server2.ipa.middlebury.edu, ldap://server3.ipa.middlebury.edu
 
  
 
 But this still failed. However, if I do something similar in /etc/ldap.conf:
 
  
 
   uri ldap://server1.ipa.middlebury.edu
 ldap://server2.ipa.middlebury.edu ldap://server3.ipa.middlebury.edu
 
  
 
 then logins work. In fact, I don't even need the change in sssd.conf. I
 can put that back the way it was, and logins still work. It's only the
 line in /etc/ldap.conf that seems to be necessary.
 
  
 
 So, I have two questions:
 
  
 
 1. Am I understanding this correctly?
 
  
 
 2. If so, is there a way to automate this so that when I run
 ipa-client-install on my RHEL 5 clients, they get the correct LDAP
 settings from the beginning, and I don't have to go and manually edit
 the ldap.conf file?

I think the SSSD guys are going to want to see your full sssd.conf.

An ipaclient-install.log for one of these clients might be handy too so
we can discern how you are configuring the client.

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] granular sudo commands

2015-04-08 Thread Martin Chamambo

For all my sudo commands i do sudo command_name_here 

From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on 
behalf of Craig White [cwh...@skytouchtechnology.com]
Sent: Thursday, April 09, 2015 1:52 AM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] granular sudo commands

rpm -q sssd
sssd-1.11.6-30.el6_6.4.x86_64
rpm -q ipa-client
ipa-client-3.0.0-42.el6.x86_64

[test2.user@app001 ~]$ sudo su - weblogic
[sudo] password for test2.user:
Sorry, user test2.user is not allowed to execute '/bin/su - weblogic' as root 
on app001.stt.local.
[test2.user@app001 ~]$ sudo -l
[sudo] password for test2.user:
Matching Defaults entries for test2.user on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep=COLORS
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS, env_keep+=MAIL PS1
PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE, env_keep+=LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES, env_keep+=LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE, env_keep+=LC_TIME LC_ALL
LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY,
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin, !requiretty

User test2.user may run the following commands on this host:
(ALL) sudo su - tomcat, sudo su – weblogic

How should the actual command be entered? I have tried…
Su – weblogic (ignore autocapitilization)
/bin/su – weblogic
Sudo su – weblogic
Sudo /bin/su – weblogic

But none seem to actually work

Craig White

-- 
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] Accident upgrade 3.3 to 4.1

-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Wednesday, April 08, 2015 6:36 PM
To: Alexander Frolushkin (SIB)
Cc: 'Ludwig Krispenz'; Martin Kosek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

On 04/08/2015 02:19 PM, Alexander Frolushkin wrote:
 On one of accidently upgraded server I have following error in dirsrv logs:

 [08/Apr/2015:13:24:12 +0300] connection - conn=1095 fd=131 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:13:24:12 +0300] connection - conn=1094 fd=124 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:13:24:12 +0300] connection - conn=1096 fd=124 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:13:24:12 +0300] connection - conn=1097 fd=131 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 This message is logged if the received message was too large. But here max 
 size was 200Mb.
 I can not imagine a such large message.
 Being log at the same second, it could be transient error. Have you seen 
 others messages like these ?
 Yes, it still here.

 [08/Apr/2015:14:55:01 +0300] connection - conn=1125 fd=130 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:14:55:01 +0300] connection - conn=1124 fd=126 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:14:55:01 +0300] connection - conn=1126 fd=126 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.

Those logs mean the connection (e.g. conn=1125) got closed.
Would you grep conn=1125 in access log ?

[08/Apr/2015:14:55:00 +0300] conn=1125 fd=130 slot=130 connection from 
10.99.111.42 to 10.163.129.91
[08/Apr/2015:14:55:00 +0300] conn=1125 op=0 SRCH base= scope=0 
filter=(objectClass=*) attrs=subschemaSubentry dsservicename namingContexts 
defaultnamingcontext schemanamingcontext configuratio
nnamingcontext rootdomainnamingcontext supportedControl supportedLDAPVersion 
supportedldappolicies supportedSASLMechanisms dnshostname ldapservicename 
servername supportedcapabilities
[08/Apr/2015:14:55:00 +0300] conn=1125 op=0 RESULT err=0 tag=101 nentries=1 
etime=0

 [08/Apr/2015:14:55:26 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://cnt-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:14:55:26 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://cnt-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:14:55:26 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://cnt-rhidm01.unix.ad.com:389/o%3Dipaca) failed.

 [08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:13:25:15 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://vlg-rhidm02.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:13:25:15 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://vlg-rhidm02.unix.ad.com:389/o%3Dipaca) failed.
 Here it is likely trigger by RUV containing duplicated values (multiple 
 replica install ?). You may have to use cleanruv after the upgrade.
 ipa-replica-manage list-ruv  and ipa-replica-manager clean-ruv
 Do You mean we need to upgrade all 3.3.3 IPA servers to 4.1 first? Or this 
 can be cleaned right now on remaining servers?

 BTW:
 # ipa-replica-manage list-ruv
 Directory Manager password:

 sib-rhidm03.unix.ad.com:389: 5
 dv-rhidm01.unix.ad.com:389: 17
 sib-rhidm02.unix.ad.com:389: 3
 sib-rhidm01.unix.ad.com:389: 4
 url-rhidm01.unix.ad.com:389: 6
 url-rhidm02.unix.ad.com:389: 7

 nw-rhidm01.unix.ad.com:389: 19

This message is harmless. It means that some values of nsds50ruv in the RUV 
have identical referral.
This should not occur, but replication is smart enough to just log this 
warning and continue working.

I would not recommend cleanup right now. Just clarification of the status.
Would you send all the ruv values returned by 'list-ruv' (here there is no 
duplicate).

Here the full command output from the IPA 4.1 server:

# ipa-replica-manage list-ruv
Directory Manager password:

nw-rhidm01.unix.ad.com:389: 19
dv-rhidm02.unix.ad.com:389:

Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

On 04/09/2015 05:59 AM, Alexander Frolushkin wrote:
 -Original Message-
 From: thierry bordaz [mailto:tbor...@redhat.com]
 Sent: Wednesday, April 08, 2015 6:36 PM
 To: Alexander Frolushkin (SIB)
 Cc: 'Ludwig Krispenz'; Martin Kosek; freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] Accident upgrade 3.3 to 4.1

 On 04/08/2015 02:19 PM, Alexander Frolushkin wrote:
 On one of accidently upgraded server I have following error in dirsrv 
 logs:

 [08/Apr/2015:13:24:12 +0300] connection - conn=1095 fd=131 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:13:24:12 +0300] connection - conn=1094 fd=124 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:13:24:12 +0300] connection - conn=1096 fd=124 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:13:24:12 +0300] connection - conn=1097 fd=131 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 This message is logged if the received message was too large. But here max 
 size was 200Mb.
 I can not imagine a such large message.
 Being log at the same second, it could be transient error. Have you seen 
 others messages like these ?
 Yes, it still here.

 [08/Apr/2015:14:55:01 +0300] connection - conn=1125 fd=130 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:14:55:01 +0300] connection - conn=1124 fd=126 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.
 [08/Apr/2015:14:55:01 +0300] connection - conn=1126 fd=126 Incoming BER 
 Element was too long, max allowable is 209715200 bytes. Change the 
 nsslapd-maxbersize attribute in cn=config to increase.

 Those logs mean the connection (e.g. conn=1125) got closed.
 Would you grep conn=1125 in access log ?

 [08/Apr/2015:14:55:00 +0300] conn=1125 fd=130 slot=130 connection from 
 10.99.111.42 to 10.163.129.91
 [08/Apr/2015:14:55:00 +0300] conn=1125 op=0 SRCH base= scope=0 
 filter=(objectClass=*) attrs=subschemaSubentry dsservicename 
 namingContexts defaultnamingcontext schemanamingcontext configuratio
 nnamingcontext rootdomainnamingcontext supportedControl supportedLDAPVersion 
 supportedldappolicies supportedSASLMechanisms dnshostname ldapservicename 
 servername supportedcapabilities
 [08/Apr/2015:14:55:00 +0300] conn=1125 op=0 RESULT err=0 tag=101 nentries=1 
 etime=0

 [08/Apr/2015:14:55:26 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://cnt-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:14:55:26 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://cnt-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:14:55:26 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://cnt-rhidm01.unix.ad.com:389/o%3Dipaca) failed.

 [08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:13:25:11 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://sib-rhidm01.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:13:25:15 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://vlg-rhidm02.unix.ad.com:389/o%3Dipaca) failed.
 [08/Apr/2015:13:25:15 +0300] attrlist_replace - attr_replace 
 (nsslapd-referral, ldap://vlg-rhidm02.unix.ad.com:389/o%3Dipaca) failed.
 Here it is likely trigger by RUV containing duplicated values (multiple 
 replica install ?). You may have to use cleanruv after the upgrade.
 ipa-replica-manage list-ruv  and ipa-replica-manager clean-ruv
 Do You mean we need to upgrade all 3.3.3 IPA servers to 4.1 first? Or this 
 can be cleaned right now on remaining servers?

 BTW:
 # ipa-replica-manage list-ruv
 Directory Manager password:

 sib-rhidm03.unix.ad.com:389: 5
 dv-rhidm01.unix.ad.com:389: 17
 sib-rhidm02.unix.ad.com:389: 3
 sib-rhidm01.unix.ad.com:389: 4
 url-rhidm01.unix.ad.com:389: 6
 url-rhidm02.unix.ad.com:389: 7

 nw-rhidm01.unix.ad.com:389: 19

 This message is harmless. It means that some values of nsds50ruv in the RUV 
 have identical referral.
 This should not occur, but replication is smart enough to just log this 
 warning and continue working.

 I would not recommend cleanup right now. Just clarification of the status.
 Would you send all the ruv values returned by 'list-ruv' (here there is no 
 duplicate).

 Here the full command output from the IPA 4.1 server:

 # ipa-replica-manage list-ruv

Re: [Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

2015-04-08 Thread Martin Chamambo

Good day 

I managed to configure sudo and its working for all my centos 6.6 and RHEL 6.6 
clients. somehow i managed to change the sudo rules ,sudo comands and sudo 
groups to be less restrictive ,thats when i managed to access root owned files 
using sudo

thanx for your help 

My advice when configuring sudo ,  when configuring your sudo rules , start 
with a less restrictive access control e.g where they say Access this host  
say any where they say Run Commands ---say any command and when its working 
,thats when you can then fine tune your access policies

From: Jakub Hrozek [jhro...@redhat.com]
Sent: Wednesday, April 08, 2015 2:01 PM
To: Martin Chamambo
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA, version: 4.1.0 and sudo configuration

On Wed, Apr 08, 2015 at 01:39:44PM +0200, Chamambo Martin wrote:
 Sudo seems to be configured correctly but somehow it's not working

 Even if I do a sudo -l under the admin user

 [admin@ironhide tmp]$ sudo -l
 [sudo] password for admin:
 Matching Defaults entries for admin on this host:
 requiretty, !visiblepw, always_set_home, env_reset, env_keep=COLORS
 DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS, env_keep+=MAIL PS1
 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE, env_keep+=LC_COLLATE
 LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES, env_keep+=LC_MONETARY
 LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE, env_keep+=LC_TIME LC_ALL
 LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY,
 secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

 User admin may run the following commands on this host:
 (admin, chamambom, kamoyob, kumalop, machangeteb, masaitit, masvivic,
 matangiraa, nyahumap, pedzisail, tayengwaj : ALL) /usr/bin/vim,
~~~
 /usr/bin/less
  ~
According to this output, admin can run both vim and less... ??

-- 
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] Replica with external ca + custom subject in certificate

2015-04-08 Thread Jan Cholasta


Dne 8.4.2015 v 17:43 James James napsal(a):

It's a little bit more clear. Thanks.

I have created a new ipa 4.1 replica but when I want run :

# ipa-cacert-manage renew --self-signed

I've got this message :

[root@ipa-devel-centos7 ~]# ipa-cacert-manage renew --self-signed
CA is not configured on this system


You can run ipa-cacert-manage only on IPA servers with CA installed.



If I want to install the CA I've got this message :

[root@ipa-devel-centos7 system]# ipa-ca-install --password=mypassorwd -U
CA is already installed.


This command is used to install CA in CA-less IPA environment. The error 
message is a bit misleading and we have a ticket for that: 
https://fedorahosted.org/freeipa/ticket/4492.




Should I have to promote the replica to a standalone master before
installing the CA ?


You need to run ipa-ca-install with the replica info file used to create 
the replica to install the CA:


# ipa-ca-install path to replica info file



Any hints will be appreciated...


James


2015-04-08 7:27 GMT+02:00 Jan Cholasta jchol...@redhat.com
mailto:jchol...@redhat.com:

Dne 7.4.2015 v 15:31 Martin Kosek napsal(a):

On 04/07/2015 02:08 PM, James James wrote:

I will try to give a better explanation :


I have a CentOS 6.6 with ipa 3.0 named ipa-master.
ipa-master has been
installed with an external CA about 3 years ago and I will
have to renew
the certificate soon.

   I have created a test server (ipa-dev) with the same
configuration (centos
6.6 and ipa 3.0) to test the renewal process. I want the new
ipa-dev sever
to be installed with an external CA.

In the same time my external CA has changed and wants the
emailAddress
field in the certificate request 's subject.


CSR during installation with external CA is produced by Dogtag,
so you are
constrained with the options and capabilities provided by
ipa-server-install.
Maybe it would be possible to modify the CSR and update the
Subject manually,
but I expect it would crash the installer later (JanC may know
more (CCed))


The subject name identifies the CA in server (and other)
certificates. If you change it, you break the trust chain from the
CA certificate to the server certificates and that will break all
SSL in IPA.


If it is not possible to add emailAddress in the subject, is
it possible to
migrate my ipa-master CA system from an external CA to a
CA-less or
self-signed CA ?


It is, with ipa-cacert-manage - see links below.


You can change your external CA to self-signed CA in IPA 4.1 or
newer by running:

 # ipa-cacert-manage renew --self-signed

You can't change external CA to CA-less.



Thanks.

2015-04-07 13:48 GMT+02:00 Martin Kosek mko...@redhat.com
mailto:mko...@redhat.com:

On 04/07/2015 01:44 PM, James James wrote:

ok.

Is there a way to migrate from an external CA to a
CA-less or a

self-signed

CA  ?


Yes, you can use ipa-cacert-manage tool introduced in
FreeIPA 4.1.0:

https://www.freeipa.org/page/__Howto/CA_Certificate_Renewal
https://www.freeipa.org/page/Howto/CA_Certificate_Renewal
https://www.freeipa.org/page/__V4/CA_certificate_renewal
https://www.freeipa.org/page/V4/CA_certificate_renewal

(Although I am still not sure about your use case and if
this would help
you)


2015-04-07 12:51 GMT+02:00 Martin Kosek
mko...@redhat.com mailto:mko...@redhat.com:

On 04/03/2015 11:39 AM, James James wrote:

Hello,

I want to initialize a new replica with an
external CA. My Certificate
Authority wants a CSR with the field
emailAddress in the subject like :


/C=FR/O=TESTO/OU=TESTOU/CN=*.e__xample.com/emailAddress=none@__none.com
http://example.com/emailAddress=n...@none.com


I am not a bit confused. Do you plan to have
FreeIPA *without* a CA or
with own
CA signed by external CA?

FreeIPA supports these kinds of setups right now:

http://www.freeipa.org/page/__PKI#Blending_in_PKI___infrastructure

http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure

[Freeipa-users] granular sudo commands

2015-04-08 Thread Craig White

rpm -q sssd
sssd-1.11.6-30.el6_6.4.x86_64
rpm -q ipa-client
ipa-client-3.0.0-42.el6.x86_64

[test2.user@app001 ~]$ sudo su - weblogic
[sudo] password for test2.user:
Sorry, user test2.user is not allowed to execute '/bin/su - weblogic' as root 
on app001.stt.local.
[test2.user@app001 ~]$ sudo -l
[sudo] password for test2.user:
Matching Defaults entries for test2.user on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep=COLORS
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS, env_keep+=MAIL PS1
PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE, env_keep+=LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES, env_keep+=LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE, env_keep+=LC_TIME LC_ALL
LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY,
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin, !requiretty

User test2.user may run the following commands on this host:
(ALL) sudo su - tomcat, sudo su - weblogic

How should the actual command be entered? I have tried...
Su - weblogic (ignore autocapitilization)
/bin/su - weblogic
Sudo su - weblogic
Sudo /bin/su - weblogic

But none seem to actually work

Craig White

-- 
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] Configuring RHEL 5 clients for automatic failover of servers