Re: [Freeipa-users] Installation on CentOS 6.6 with DNS
Hello, I think that this more related to LDAP server than to DNS server. Could you system check logs (journalctl or /var/log/messages) to see if ns-slapd process crashed or something like that? Petr^2 Spacek On 27.5.2015 12:13, Ricardo Oliveira wrote: > Hi, > > Thanks for your reply. The host is indeed in the hosts file, > and even in the DNS server's "mydomain.com" zone and reverse zone, which > is a local Bind instance which is the one I expect IPA to manage once > the setup is complete. > In fact, if both DNS and reverse DNS > resolution are not configured, IPA server setup fails in the beginning > with something like "Host not found". > > Best, > Ricardo. > > Date: Wed, 27 May 2015 06:14:34 +0700 > Subject: Re: [Freeipa-users] Installation on CentOS 6.6 with DNS > From: dewangg...@xtremenitro.org > To: n3...@hotmail.com > CC: freeipa-users@redhat.com > > Have you add your ipa.domain.com ip address on /etc/hosts file? The error > seems like your installation can't resolve the ip address. > On Wednesday, May 27, 2015, Ricardo Oliveira wrote: > > > > > > > > > > Hi, > > I've been trying to setup IPA on CentOS 6.6 with the --setup-dns option on, > using the CentOS provided packages: > > rpm > > My problem is that everything is installed except when I use this flag. > So, when I run: > > ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r > MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U > > The installation finishes successfully. > If I add DNS switches to the installation, it fails almost at the end: > > ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r > MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U --setup-dns > --no-forwarders > > Output (clipped): > --- > ... > Configuring the web interface (httpd): Estimated time 1 minute > [1/13]: setting mod_nss port to 443 > [2/13]: setting mod_nss password file > [3/13]: enabling mod_nss renegotiate > [4/13]: adding URL rewriting rules > [5/13]: configuring httpd > [6/13]: setting up ssl > [7/13]: setting up browser autoconfig > [8/13]: publish CA cert > [9/13]: creating a keytab for httpd > [10/13]: clean up any existing httpd ccache > [11/13]: configuring SELinux for httpd > [12/13]: restarting httpd > [13/13]: configuring httpd to start on boot > Done configuring the web interface (httpd). > Applying LDAP updates > Restarting the directory server > Restarting the KDC > Can't contact LDAP server > [root@ipa ~]# > --- > The screen output is at http://pastebin.com/HKiUwKq4The end of the error log > is at http://pastebin.com/jDUhBCL7 (it's a 29 MB file so I only pasted the > end of it). > If anyone has come across anything like this, I would appreciate your help. > Thanks. > Ricardo. > > > > > > > -- Petr^2 Spacek -- 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] dereference processing failed : Invalid argument
On Wed, May 27, 2015 at 04:27:45PM -0700, nat...@nathanpeters.com wrote: > > I have a CentOS 6.3 client with sssd 1.11.6-30.el6_6.4 installed and when > > one of my FreeIPA users tries to sudo (he has permissions via group > > membership) I get the following error in /var/log/messages > > > > May 27 20:51:34 ipaclient sssd[be[mydomain.net]]: dereference processing > > failed : Invalid argument > > > > I have read that this is a known bug > > (https://bugzilla.redhat.com/show_bug.cgi?id=1154042) and that the > > suggested fix is to add the following line to the domain section of the > > sssd.conf : > > > > ldap_group_object_class = ipaUserGroup > > > > I tried adding that and then restarting the client, but it did not fix the > > problem. I have also read that this problem may only apply to POSIX > > groups so I removed my user from all POSIX groups, added him to non posix > > groups and then created some new sudo rules and hbac rules. I restarted > > the client again and still had the same issue where I could login but not > > sudo. > > > > Is there a known workaround that actually works? > > > > I see this bug is supposed to be fixed in sssd 1.11.8. Is this version of > > sssd going to be released into any repo for CentOS 6? > > > > I just had a look at the CentOS 6 updates repo and sssd is still at > > 1.11.6-30 > > > > > > -- > > Well, I found that if I updated to CentOS 6.5 and then put the user in all > non posix groups and renamed my sudo rules so they were different names > than my hbac rules I could finally log in and sudo properly with no > messing with my sssd.conf file. > > Nothing I tried in CentOS 6.3 would work though. btw in upstream we relaxed the dereference processing a bit and now we just skip the faulty rules. -- 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] Haunted servers?
Hello Alexander,
Cleanallruv can hang to do the cleanup (depending on task options and if
replica are reachable).
Did you try using CLEANRUV that is a more basic tool but that should not
fail to do the cleanup.
Before using cleanruv, you need to abort all cleanallruv pending tasks.
Then for each RID that you want to clean, you have to log on each
replica and run
dn: cn=replica,cn=,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUV
This task should succeeds but there is possibility that a given RID
resurects in case a replication session occurs before all cleanRUV are
completed.
So we may have to do cleanRUV a second time.
thanks
thierry
On 05/27/2015 11:06 AM, Alexander Frolushkin wrote:
For common information - we also have a "ghost" replica id:
unable to decode: {replica 16} 548a81260010 548a81260010
and trying to get it away with help of Red Hat support, but at this point - no
luck...
WBR,
Alexander Frolushkin
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
Sent: Tuesday, May 26, 2015 8:56 PM
To: thierry bordaz; Martin Kosek
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Haunted servers?
On 5/26/15 7:04 AM, thierry bordaz wrote:
On 05/26/2015 08:47 AM, Martin Kosek wrote:
On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
And just like that, my haunted servers have all returned.
I am going to just put a gun to my head and be done with it. :-(
Why do things run perfectly and then suddenly ???
Logs show little to nothing, mostly because the servers are so
busy, they have already rotated out.
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 23} 5545d61f00020017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
unable to decode {replica 25} 554d78bf0019
555af30200040019
unable to decode {replica 9} 55402c3900030009
55402c3900030009
Don't know what to do anymore. At my wit's end..
~J
So things are getting more interesting. Still trying to find the
"leaking server(s)". here is what I mean by that. As you see, I
continue to find these
-- BUT, notice a new symptom -- replica 9 does NOT show any other
data - it is blank?
Hello Janelle,
Thanks for update. So you worry that there might still be the "rogue
IPA replica" that would be injecting the wrong replica data?
In any case, I bet Ludwig and Thierry will follow up with your
thread, there is just delay caused by the various public holidays and
PTOs this week and we need to rest before digging into the fun with
RUVs - as you already know yourself :-)
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 24} 554d53d300010018
554d54a400020018
unable to decode {replica 25} 554d78bf00020019
555af30200040019
unable to decode {replica 9}
Now, if I delete these from a server using the ldapmodify method -
they go away briefly, but then if I restart the server, they come
back.
Let me try to explain -- given a number of servers, say 8, if I user
ldapmodify to delete from 1 of those, they seem to go away from
maybe 4 of them
-- but if
I wait a few minutes, it is almost as though "replication" is
re-adding these bad replicas from the servers that I have NOT
deleted them from.
On each replica (master/replica) there are one RUV in the database and
one RUV in the changelog.
When cleanallruv succeeds it clears both of them. All replica should
be reachable when you issue cleanallruv, so that it can clean the RUVs
on all the replicas in almost "single"
operation. If some replica are not reachable, they keep information of
about the cleaned RID and then can later propagate those "old" RID to
the rest of the replica.
Ludwig managed to reproduce the issue with a quite complex test case
(3 replicas and multiple cleanallruv).
We have not yet identified the reason how a cleaned replicaId can get
resurrected.
In parallel we just reproduced it without a clear test case but in a 2
replica topology.
So my question is simple - is there something in the logs I can look
for that would indicate the SOURCE of these bogus entries? Is the
replica 9 with NO extra data any indication of something I could
look for?
I guess that if I have the answer to your question we would have
understood the bug ..
A little more information to go on:
I changed my password on a master (actually, the original master) and was able
to login to each replica within a few seconds with the new password. This tells
me replication is working across all the servers.
I also created a new account and it showed up on all the servers, again within
15-20 seconds. This tells me replication is w
Re: [Freeipa-users] dereference processing failed : Invalid argument
On (27/05/15 14:22), nat...@nathanpeters.com wrote: >I have a CentOS 6.3 client with sssd 1.11.6-30.el6_6.4 installed and when >one of my FreeIPA users tries to sudo (he has permissions via group >membership) I get the following error in /var/log/messages > >May 27 20:51:34 ipaclient sssd[be[mydomain.net]]: dereference processing >failed : Invalid argument > >I have read that this is a known bug >(https://bugzilla.redhat.com/show_bug.cgi?id=1154042) and that the >suggested fix is to add the following line to the domain section of the >sssd.conf : > >ldap_group_object_class = ipaUserGroup > You cannot hit BZ1154042, because it is already fixed in 1.11.6-30.el6_6.4 @see https://bugzilla.redhat.com/show_bug.cgi?id=1165074 >I tried adding that and then restarting the client, but it did not fix the >problem. I have also read that this problem may only apply to POSIX >groups so I removed my user from all POSIX groups, added him to non posix >groups and then created some new sudo rules and hbac rules. I restarted >the client again and still had the same issue where I could login but not >sudo. > >Is there a known workaround that actually works? > >I see this bug is supposed to be fixed in sssd 1.11.8. Is this version of >sssd going to be released into any repo for CentOS 6? > No 1.11.8 will not be release in CentOS 6. CentOS just rebuild rhel src.rpm packages. However rhel 6.7-beta has already sssd-1.12.4-x. If you want you can test with pre-release of upstream 1.12.5 https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ 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] Haunted servers?
Hello!
Thank you for this info.
Things seems to be complicated for now...
We have this:
"unable to decode: {replica 16} 548a81260010 548a81260010"
on all of our 17 servers.
After launching cleanallruv we have it disappeared from 16 servers and one
server hangs (any requests addressed ldap just freezes, including "ipactl
status"). After dirsrv restart (via "systemctl restart ipa") I found
"unable to decode: {replica 16} 548a81260010 548a81260010"
on this server (and only on it), run cleanallruv and get it from this server,
but right after that
unable to decode: {replica 16} 548a81260010 548a81260010
reappeared on three other servers.
Now I'm waiting response from support, they requested dirsrv logs form hanged
server and from servers where error appeared again.
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:24 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
Hello Alexander,
Cleanallruv can hang to do the cleanup (depending on task options and if
replica are reachable).
Did you try using CLEANRUV that is a more basic tool but that should not fail
to do the cleanup.
Before using cleanruv, you need to abort all cleanallruv pending tasks.
Then for each RID that you want to clean, you have to log on each replica and
run
dn: cn=replica,cn=,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUV
This task should succeeds but there is possibility that a given RID resurects
in case a replication session occurs before all cleanRUV are completed.
So we may have to do cleanRUV a second time.
thanks
thierry
On 05/27/2015 11:06 AM, Alexander Frolushkin wrote:
> For common information - we also have a "ghost" replica id:
> unable to decode: {replica 16} 548a81260010
> 548a81260010 and trying to get it away with help of Red Hat support,
> but at this point - no luck...
>
> WBR,
> Alexander Frolushkin
>
> -Original Message-
> From: freeipa-users-boun...@redhat.com
> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
> Sent: Tuesday, May 26, 2015 8:56 PM
> To: thierry bordaz; Martin Kosek
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Haunted servers?
>
> On 5/26/15 7:04 AM, thierry bordaz wrote:
>> On 05/26/2015 08:47 AM, Martin Kosek wrote:
>>> On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
> And just like that, my haunted servers have all returned.
> I am going to just put a gun to my head and be done with it. :-(
>
> Why do things run perfectly and then suddenly ???
> Logs show little to nothing, mostly because the servers are so
> busy, they have already rotated out.
>
> unable to decode {replica 16} 5535647200030010
> 5535647200030010
> unable to decode {replica 22} 55371e9e0016
> 553eec6400040016
> unable to decode {replica 23} 5545d61f00020017
> 555432430017
> unable to decode {replica 24} 554d53d30018
> 554d54a400020018
> unable to decode {replica 25} 554d78bf0019
> 555af30200040019
> unable to decode {replica 9} 55402c3900030009
> 55402c3900030009
>
> Don't know what to do anymore. At my wit's end..
>
> ~J
So things are getting more interesting. Still trying to find the
"leaking server(s)". here is what I mean by that. As you see, I
continue to find these
-- BUT, notice a new symptom -- replica 9 does NOT show any other
data - it is blank?
>>> Hello Janelle,
>>>
>>> Thanks for update. So you worry that there might still be the "rogue
>>> IPA replica" that would be injecting the wrong replica data?
>>>
>>> In any case, I bet Ludwig and Thierry will follow up with your
>>> thread, there is just delay caused by the various public holidays
>>> and PTOs this week and we need to rest before digging into the fun
>>> with RUVs - as you already know yourself :-)
>>>
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 24} 554d53d300010018
554d54a400020018
unable to decode {replica 25} 554d78bf00020019
555af30200040019
unable to decode {replica 9}
Now, if I delete these from a server using the ldapmodify method -
they go away briefly, but then if I restart the server, they come
back.
Let me try to explain -- given a number of servers, say 8, if I
user ldapmodify to delete from 1 of those, they seem to go away
from maybe 4 of them
-- but if
I wait a few minutes, it is almost as though "replication" is
re-adding these bad replicas from the
Re: [Freeipa-users] Haunted servers?
On 05/28/2015 09:33 AM, Alexander Frolushkin wrote:
Hello!
Thank you for this info.
Things seems to be complicated for now...
We have this:
"unable to decode: {replica 16} 548a81260010 548a81260010"
on all of our 17 servers.
After launching cleanallruv we have it disappeared from 16 servers and one server hangs (any
requests addressed ldap just freezes, including "ipactl status"). After dirsrv restart
(via "systemctl restart ipa") I found
"unable to decode: {replica 16} 548a81260010 548a81260010"
on this server (and only on it), run cleanallruv and get it from this server,
but right after that
unable to decode: {replica 16} 548a81260010 548a81260010
reappeared on three other servers.
Hello,
Yes this is exactly why cleanallruv is the first tool to use, it does
the job on all replicas.
When you restarted the hanging server, some (3) of them established a
replication session with it and "learned" this old/invalid RUVelement.
Janelle, Alexander, do you remember if you ran the command :
'ipa-replica-manage del --force --clean'. (with the option
--force and --clean) ?
thanks
thierry
Now I'm waiting response from support, they requested dirsrv logs form hanged
server and from servers where error appeared again.
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:24 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
Hello Alexander,
Cleanallruv can hang to do the cleanup (depending on task options and if
replica are reachable).
Did you try using CLEANRUV that is a more basic tool but that should not fail
to do the cleanup.
Before using cleanruv, you need to abort all cleanallruv pending tasks.
Then for each RID that you want to clean, you have to log on each replica and
run
dn: cn=replica,cn=,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUV
This task should succeeds but there is possibility that a given RID resurects
in case a replication session occurs before all cleanRUV are completed.
So we may have to do cleanRUV a second time.
thanks
thierry
On 05/27/2015 11:06 AM, Alexander Frolushkin wrote:
For common information - we also have a "ghost" replica id:
unable to decode: {replica 16} 548a81260010
548a81260010 and trying to get it away with help of Red Hat support,
but at this point - no luck...
WBR,
Alexander Frolushkin
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
Sent: Tuesday, May 26, 2015 8:56 PM
To: thierry bordaz; Martin Kosek
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Haunted servers?
On 5/26/15 7:04 AM, thierry bordaz wrote:
On 05/26/2015 08:47 AM, Martin Kosek wrote:
On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
And just like that, my haunted servers have all returned.
I am going to just put a gun to my head and be done with it. :-(
Why do things run perfectly and then suddenly ???
Logs show little to nothing, mostly because the servers are so
busy, they have already rotated out.
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 23} 5545d61f00020017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
unable to decode {replica 25} 554d78bf0019
555af30200040019
unable to decode {replica 9} 55402c3900030009
55402c3900030009
Don't know what to do anymore. At my wit's end..
~J
So things are getting more interesting. Still trying to find the
"leaking server(s)". here is what I mean by that. As you see, I
continue to find these
-- BUT, notice a new symptom -- replica 9 does NOT show any other
data - it is blank?
Hello Janelle,
Thanks for update. So you worry that there might still be the "rogue
IPA replica" that would be injecting the wrong replica data?
In any case, I bet Ludwig and Thierry will follow up with your
thread, there is just delay caused by the various public holidays
and PTOs this week and we need to rest before digging into the fun
with RUVs - as you already know yourself :-)
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 24} 554d53d300010018
554d54a400020018
unable to decode {replica 25} 554d78bf00020019
555af30200040019
unable to decode {replica 9}
Now, if I delete these from a server using the ldapmodify method -
they go away briefly, but then if I restart the server, they come
back.
Let me try to explain -- given a number of servers, say 8, if I
user ldapmodify to delete from 1 of those, they seem to
[Freeipa-users] question about password migration from ldap
Hi, I am try to migrate from openldap to freeipa. Everything seems to be working except the password. I understand that when migrating from openldap, the hashed form the the passwords are migrated, but a Kerberos hash is not generated until the user logs in using sssd or through the ipa/migration web ui. However, the users are not able to login in either form using their existing password, from the directory server log, the only weird thing I see is [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND dn="uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted]" method=128 version=3 [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 What does err=48 mean? I do have ipa config-mod --enable-migration=TRUE Thanks, David -- 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] question about password migration from ldap
On 05/28/2015 11:47 AM, David Lin wrote: > Hi, > I am try to migrate from openldap to freeipa. Everything seems to be working > except the password. I understand that when migrating from openldap, the > hashed > form the the passwords are migrated, but a Kerberos hash is not generated > until > the user logs in using sssd or through the ipa/migration web ui. However, the > users are not able to login in either form using their existing password, from > the directory server log, the only weird thing I see is > > [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 > etime=0 > [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES > [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND > dn="uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted]" > method=128 version=3 > [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 > etime=0 > [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND > [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 > > What does err=48 mean? > > I do have > ipa config-mod --enable-migration=TRUE 48 is LDAP_INAPPROPRIATE_AUTH. I see more information for example here: http://www.zytrax.com/books/ldap/ch12/ Do the migrated users have the userPassword attribute? You can check on the user with: # ldapsearch -D "cn=Directory Manager" -x -w Secret123 -b "uid=admin,cn=users,cn=accounts,dc=f21" uid userPassword # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: uid userPassword # # admin, users, accounts, f21 dn: uid=admin,cn=users,cn=accounts,dc=f21 uid: admin userPassword:: e1NTSEF9K2tZ...Ib3c9PQ== # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 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] question about password migration from ldap
hum, seems like the migrated users do not have userPassword attribute. Is there anyway to fix this? Thanks! David On 05/28/2015 03:13 AM, Martin Kosek wrote: On 05/28/2015 11:47 AM, David Lin wrote: Hi, I am try to migrate from openldap to freeipa. Everything seems to be working except the password. I understand that when migrating from openldap, the hashed form the the passwords are migrated, but a Kerberos hash is not generated until the user logs in using sssd or through the ipa/migration web ui. However, the users are not able to login in either form using their existing password, from the directory server log, the only weird thing I see is [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND dn="uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted]" method=128 version=3 [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 What does err=48 mean? I do have ipa config-mod --enable-migration=TRUE 48 is LDAP_INAPPROPRIATE_AUTH. I see more information for example here: http://www.zytrax.com/books/ldap/ch12/ Do the migrated users have the userPassword attribute? You can check on the user with: # ldapsearch -D "cn=Directory Manager" -x -w Secret123 -b "uid=admin,cn=users,cn=accounts,dc=f21" uid userPassword # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: uid userPassword # # admin, users, accounts, f21 dn: uid=admin,cn=users,cn=accounts,dc=f21 uid: admin userPassword:: e1NTSEF9K2tZ...Ib3c9PQ== # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 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] question about password migration from ldap
On Thu, 28 May 2015, David Lin wrote: hum, seems like the migrated users do not have userPassword attribute. Is there anyway to fix this? Did you actually have access to the userPasssword attribute in OpenLDAP when migrate-ds command was running? This all is described in the 'ipa migrate-ds --help' output. You cannot add userPassword attribute in hashed form after the object was created in IPA. It can only be set when new user record is created in the migration mode. Thanks! David On 05/28/2015 03:13 AM, Martin Kosek wrote: On 05/28/2015 11:47 AM, David Lin wrote: Hi, I am try to migrate from openldap to freeipa. Everything seems to be working except the password. I understand that when migrating from openldap, the hashed form the the passwords are migrated, but a Kerberos hash is not generated until the user logs in using sssd or through the ipa/migration web ui. However, the users are not able to login in either form using their existing password, from the directory server log, the only weird thing I see is [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND dn="uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted]" method=128 version=3 [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 What does err=48 mean? I do have ipa config-mod --enable-migration=TRUE 48 is LDAP_INAPPROPRIATE_AUTH. I see more information for example here: http://www.zytrax.com/books/ldap/ch12/ Do the migrated users have the userPassword attribute? You can check on the user with: # ldapsearch -D "cn=Directory Manager" -x -w Secret123 -b "uid=admin,cn=users,cn=accounts,dc=f21" uid userPassword # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: uid userPassword # # admin, users, accounts, f21 dn: uid=admin,cn=users,cn=accounts,dc=f21 uid: admin userPassword:: e1NTSEF9K2tZ...Ib3c9PQ== # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 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 -- / 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] Haunted servers?
Thank you again, Red Hat support directed me to do exactly the same.
This removed my
"unable to decode: {replica 16} 548a81260010 548a81260010"
from the rest of servers. I will check again tomorrow all our servers for this
:)
Well, I'm not the only person have privileges on our IPA servers, so I cannot
completely guarantee nobody run this command ('ipa-replica-manage del
--force --clean'. (with the option --force and --clean))
but after interrogation no one made a confession, including myself.
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:49 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
On 05/28/2015 09:33 AM, Alexander Frolushkin wrote:
> Hello!
> Thank you for this info.
>
> Things seems to be complicated for now...
> We have this:
> "unable to decode: {replica 16} 548a81260010 548a81260010"
> on all of our 17 servers.
> After launching cleanallruv we have it disappeared from 16 servers and
> one server hangs (any requests addressed ldap just freezes, including "ipactl
> status"). After dirsrv restart (via "systemctl restart ipa") I found "unable
> to decode: {replica 16} 548a81260010 548a81260010"
> on this server (and only on it), run cleanallruv and get it from this
> server, but right after that unable to decode: {replica 16}
> 548a81260010 548a81260010 reappeared on three other servers.
Hello,
Yes this is exactly why cleanallruv is the first tool to use, it does the job
on all replicas.
When you restarted the hanging server, some (3) of them established a
replication session with it and "learned" this old/invalid RUVelement.
Janelle, Alexander, do you remember if you ran the command :
'ipa-replica-manage del --force --clean'. (with the option --force and
--clean) ?
thanks
thierry
> Now I'm waiting response from support, they requested dirsrv logs form hanged
> server and from servers where error appeared again.
>
> WBR,
> Alexander Frolushkin
> Cell +79232508764
> Work +79232507764
>
>
> -Original Message-
> From: thierry bordaz [mailto:tbor...@redhat.com]
> Sent: Thursday, May 28, 2015 1:24 PM
> To: Alexander Frolushkin (SIB)
> Cc: freeipa-users@redhat.com; 'Janelle'
> Subject: Re: [Freeipa-users] Haunted servers?
>
> Hello Alexander,
>
> Cleanallruv can hang to do the cleanup (depending on task options and if
> replica are reachable).
> Did you try using CLEANRUV that is a more basic tool but that should not fail
> to do the cleanup.
>
> Before using cleanruv, you need to abort all cleanallruv pending tasks.
>
> Then for each RID that you want to clean, you have to log on each
> replica and run
> dn: cn=replica,cn=,cn=mapping tree,cn=config
> changetype: modify
> replace: nsds5task
> nsds5task:CLEANRUV
>
> This task should succeeds but there is possibility that a given RID resurects
> in case a replication session occurs before all cleanRUV are completed.
> So we may have to do cleanRUV a second time.
>
> thanks
> thierry
>
> On 05/27/2015 11:06 AM, Alexander Frolushkin wrote:
>> For common information - we also have a "ghost" replica id:
>> unable to decode: {replica 16} 548a81260010
>> 548a81260010 and trying to get it away with help of Red Hat support,
>> but at this point - no luck...
>>
>> WBR,
>> Alexander Frolushkin
>>
>> -Original Message-
>> From: freeipa-users-boun...@redhat.com
>> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
>> Sent: Tuesday, May 26, 2015 8:56 PM
>> To: thierry bordaz; Martin Kosek
>> Cc: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] Haunted servers?
>>
>> On 5/26/15 7:04 AM, thierry bordaz wrote:
>>> On 05/26/2015 08:47 AM, Martin Kosek wrote:
On 05/26/2015 12:20 AM, Janelle wrote:
> On 5/24/15 3:12 AM, Janelle wrote:
>> And just like that, my haunted servers have all returned.
>> I am going to just put a gun to my head and be done with it. :-(
>>
>> Why do things run perfectly and then suddenly ???
>> Logs show little to nothing, mostly because the servers are so
>> busy, they have already rotated out.
>>
>> unable to decode {replica 16} 5535647200030010
>> 5535647200030010
>> unable to decode {replica 22} 55371e9e0016
>> 553eec6400040016
>> unable to decode {replica 23} 5545d61f00020017
>> 555432430017
>> unable to decode {replica 24} 554d53d30018
>> 554d54a400020018
>> unable to decode {replica 25} 554d78bf0019
>> 555af30200040019
>> unable to decode {replica 9} 55402c3900030009
>> 55402c3900030009
>>
>> Don't know what to do anymore. At my wit's end..
>>
>> ~J
> So things are getting more interesting. Still trying to find the
> "leaking server(
Re: [Freeipa-users] question about password migration from ldap
Thanks, that seemed to fix it. David On 05/28/2015 03:31 AM, Alexander Bokovoy wrote: On Thu, 28 May 2015, David Lin wrote: hum, seems like the migrated users do not have userPassword attribute. Is there anyway to fix this? Did you actually have access to the userPasssword attribute in OpenLDAP when migrate-ds command was running? This all is described in the 'ipa migrate-ds --help' output. You cannot add userPassword attribute in hashed form after the object was created in IPA. It can only be set when new user record is created in the migration mode. Thanks! David On 05/28/2015 03:13 AM, Martin Kosek wrote: On 05/28/2015 11:47 AM, David Lin wrote: Hi, I am try to migrate from openldap to freeipa. Everything seems to be working except the password. I understand that when migrating from openldap, the hashed form the the passwords are migrated, but a Kerberos hash is not generated until the user logs in using sssd or through the ipa/migration web ui. However, the users are not able to login in either form using their existing password, from the directory server log, the only weird thing I see is [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND dn="uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted]" method=128 version=3 [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 What does err=48 mean? I do have ipa config-mod --enable-migration=TRUE 48 is LDAP_INAPPROPRIATE_AUTH. I see more information for example here: http://www.zytrax.com/books/ldap/ch12/ Do the migrated users have the userPassword attribute? You can check on the user with: # ldapsearch -D "cn=Directory Manager" -x -w Secret123 -b "uid=admin,cn=users,cn=accounts,dc=f21" uid userPassword # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: uid userPassword # # admin, users, accounts, f21 dn: uid=admin,cn=users,cn=accounts,dc=f21 uid: admin userPassword:: e1NTSEF9K2tZ...Ib3c9PQ== # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Haunted servers?
On 05/28/2015 12:36 PM, Alexander Frolushkin wrote:
Thank you again, Red Hat support directed me to do exactly the same.
This removed my
"unable to decode: {replica 16} 548a81260010 548a81260010"
from the rest of servers. I will check again tomorrow all our servers for this
:)
Alexander,
this is good news. Hoping it will not resurect from a forgotten replica
or changelog ;-)
The problem is that we are still fighting to reproduce it as certainly
there are some dynamics around that bug.
cleanruv is just a not perfect workaround.
thanks
thierry
Well, I'm not the only person have privileges on our IPA servers, so I cannot
completely guarantee nobody run this command ('ipa-replica-manage del
--force --clean'. (with the option --force and --clean))
but after interrogation no one made a confession, including myself.
Ok.
thanks
thierry
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:49 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
On 05/28/2015 09:33 AM, Alexander Frolushkin wrote:
Hello!
Thank you for this info.
Things seems to be complicated for now...
We have this:
"unable to decode: {replica 16} 548a81260010 548a81260010"
on all of our 17 servers.
After launching cleanallruv we have it disappeared from 16 servers and
one server hangs (any requests addressed ldap just freezes, including "ipactl status"). After
dirsrv restart (via "systemctl restart ipa") I found "unable to decode: {replica 16}
548a81260010 548a81260010"
on this server (and only on it), run cleanallruv and get it from this
server, but right after that unable to decode: {replica 16}
548a81260010 548a81260010 reappeared on three other servers.
Hello,
Yes this is exactly why cleanallruv is the first tool to use, it does the job
on all replicas.
When you restarted the hanging server, some (3) of them established a replication session
with it and "learned" this old/invalid RUVelement.
Janelle, Alexander, do you remember if you ran the command :
'ipa-replica-manage del --force --clean'. (with the option --force and
--clean) ?
thanks
thierry
Now I'm waiting response from support, they requested dirsrv logs form hanged
server and from servers where error appeared again.
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:24 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
Hello Alexander,
Cleanallruv can hang to do the cleanup (depending on task options and if
replica are reachable).
Did you try using CLEANRUV that is a more basic tool but that should not fail
to do the cleanup.
Before using cleanruv, you need to abort all cleanallruv pending tasks.
Then for each RID that you want to clean, you have to log on each
replica and run
dn: cn=replica,cn=,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUV
This task should succeeds but there is possibility that a given RID resurects
in case a replication session occurs before all cleanRUV are completed.
So we may have to do cleanRUV a second time.
thanks
thierry
On 05/27/2015 11:06 AM, Alexander Frolushkin wrote:
For common information - we also have a "ghost" replica id:
unable to decode: {replica 16} 548a81260010
548a81260010 and trying to get it away with help of Red Hat support,
but at this point - no luck...
WBR,
Alexander Frolushkin
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
Sent: Tuesday, May 26, 2015 8:56 PM
To: thierry bordaz; Martin Kosek
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Haunted servers?
On 5/26/15 7:04 AM, thierry bordaz wrote:
On 05/26/2015 08:47 AM, Martin Kosek wrote:
On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
And just like that, my haunted servers have all returned.
I am going to just put a gun to my head and be done with it. :-(
Why do things run perfectly and then suddenly ???
Logs show little to nothing, mostly because the servers are so
busy, they have already rotated out.
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 23} 5545d61f00020017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
unable to decode {replica 25} 554d78bf0019
555af30200040019
unable to decode {replica 9} 55402c3900030009
55402c3900030009
Don't know what to do anymore. At my wit's end..
~J
So things are getting more interesting. Still tr
Re: [Freeipa-users] Haunted servers?
Unfortunately, after a couple of minutes, on two of three servers error comes
back in little changed form:
# ipa-replica-manage list-ruv
unable to decode: {replica 16}
Before cleanruv it looked like:
# ipa-replica-manage list-ruv
unable to decode: {replica 16} 548a81260010 548a81260010
And one server seems to be fixed completely.
WBR,
Alexander Frolushkin
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 5:19 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
On 05/28/2015 12:36 PM, Alexander Frolushkin wrote:
> Thank you again, Red Hat support directed me to do exactly the same.
>
> This removed my
> "unable to decode: {replica 16} 548a81260010 548a81260010"
> from the rest of servers. I will check again tomorrow all our servers
> for this :)
Alexander,
this is good news. Hoping it will not resurect from a forgotten replica or
changelog ;-) The problem is that we are still fighting to reproduce it as
certainly there are some dynamics around that bug.
cleanruv is just a not perfect workaround.
thanks
thierry
>
> Well, I'm not the only person have privileges on our IPA servers, so I
> cannot completely guarantee nobody run this command ('ipa-replica-manage del
> --force --clean'. (with the option --force and --clean)) but after
> interrogation no one made a confession, including myself.
Ok.
thanks
thierry
>
>
> WBR,
> Alexander Frolushkin
> Cell +79232508764
> Work +79232507764
>
>
> -Original Message-
> From: thierry bordaz [mailto:tbor...@redhat.com]
> Sent: Thursday, May 28, 2015 1:49 PM
> To: Alexander Frolushkin (SIB)
> Cc: freeipa-users@redhat.com; 'Janelle'
> Subject: Re: [Freeipa-users] Haunted servers?
>
> On 05/28/2015 09:33 AM, Alexander Frolushkin wrote:
>> Hello!
>> Thank you for this info.
>>
>> Things seems to be complicated for now...
>> We have this:
>> "unable to decode: {replica 16} 548a81260010 548a81260010"
>> on all of our 17 servers.
>> After launching cleanallruv we have it disappeared from 16 servers
>> and one server hangs (any requests addressed ldap just freezes, including
>> "ipactl status"). After dirsrv restart (via "systemctl restart ipa") I found
>> "unable to decode: {replica 16} 548a81260010 548a81260010"
>> on this server (and only on it), run cleanallruv and get it from this
>> server, but right after that unable to decode: {replica 16}
>> 548a81260010 548a81260010 reappeared on three other servers.
> Hello,
>
> Yes this is exactly why cleanallruv is the first tool to use, it does the job
> on all replicas.
> When you restarted the hanging server, some (3) of them established a
> replication session with it and "learned" this old/invalid RUVelement.
>
> Janelle, Alexander, do you remember if you ran the command :
> 'ipa-replica-manage del --force --clean'. (with the option --force
> and --clean) ?
>
> thanks
> thierry
>> Now I'm waiting response from support, they requested dirsrv logs form
>> hanged server and from servers where error appeared again.
>>
>> WBR,
>> Alexander Frolushkin
>> Cell +79232508764
>> Work +79232507764
>>
>>
>> -Original Message-
>> From: thierry bordaz [mailto:tbor...@redhat.com]
>> Sent: Thursday, May 28, 2015 1:24 PM
>> To: Alexander Frolushkin (SIB)
>> Cc: freeipa-users@redhat.com; 'Janelle'
>> Subject: Re: [Freeipa-users] Haunted servers?
>>
>> Hello Alexander,
>>
>> Cleanallruv can hang to do the cleanup (depending on task options and if
>> replica are reachable).
>> Did you try using CLEANRUV that is a more basic tool but that should not
>> fail to do the cleanup.
>>
>> Before using cleanruv, you need to abort all cleanallruv pending tasks.
>>
>> Then for each RID that you want to clean, you have to log on each
>> replica and run
>> dn: cn=replica,cn=,cn=mapping tree,cn=config
>> changetype: modify
>> replace: nsds5task
>> nsds5task:CLEANRUV
>>
>> This task should succeeds but there is possibility that a given RID
>> resurects in case a replication session occurs before all cleanRUV are
>> completed.
>> So we may have to do cleanRUV a second time.
>>
>> thanks
>> thierry
>>
>> On 05/27/2015 11:06 AM, Alexander Frolushkin wrote:
>>> For common information - we also have a "ghost" replica id:
>>> unable to decode: {replica 16} 548a81260010
>>> 548a81260010 and trying to get it away with help of Red Hat
>>> support, but at this point - no luck...
>>>
>>> WBR,
>>> Alexander Frolushkin
>>>
>>> -Original Message-
>>> From: freeipa-users-boun...@redhat.com
>>> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
>>> Sent: Tuesday, May 26, 2015 8:56 PM
>>> To: thierry bordaz; Martin Kosek
>>> Cc: freeipa-users@redhat.com
>>> Subject: Re: [Freeipa-users] Haunted servers?
>>>
>>> On 5/26/15 7:04 AM, thierry bordaz wrote:
On 05/26/2015 08:47 AM, Martin Ko
[Freeipa-users] Sensible defaults for a new major SSSD release
Hello, as part of solution for https://fedorahosted.org/sssd/ticket/2583 ([RFE] Homedir is always overwritten with subdomain_homedir value in server mode) we came to the conclusion that it would be a good thing for SSSD in IPA server mode to change default value of subdomain_homedir from /home/%d/%u to /home/%o (where %o is original user home directory) and also set fallback_homedir to /home/%d/%u to handle cases when user doesn't have home directory attribute set. Do you have any opinions about this change? Thanks! -- 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] client fails to install from ipa-server-install or ipa-replica-install
Hello,
I'm using Puppet to try to install ipa masters and replicas. I can
generally get this to work on Vagrant VMs, but on the target VMs the
server part succeeds until it attempts to install the ipa client and
then this fails (please see extracts of logs below).
The /etc/ipa/nssdb directory is left empty. On a replica I can copy this
from the master along with /etc/openldap/ldap.conf and the client works
(apart from mkhomedir) when sssd is started. Should /etc/ipa/nssdb be
populated on the master at this stage of the installation and, if so,
then why isn't this happening? Selinux is enabled on the target VMs, but
presumably this isn't an issue.
Many thanks
Bob Hinton
trying https://ipa001.jackland.co.uk/ipa/json
Forwarding 'ping' to json server 'https://ipa001.jackland.co.uk/ipa/json'
Cannot connect to the server due to generic error: cannot connect to
'https://ipa001.jackland.co.uk/ipa/json': Internal Server Error
Installation failed. As this is IPA server, changes will not be rolled back.
2015-05-28T11:41:25Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 646, in run_script
return_value = main_function()
File "/usr/sbin/ipa-server-install", line 1292, in main
sys.exit("Configuration of client side components
failed!\nipa-client-install returned: " + str(e))
2015-05-28T11:41:25Z DEBUG The ipa-server-install command failed,
exception: SystemExit: Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install'
'--on-master' '--unattended' '--domain' 'jackland.co.uk' '--server'
'ipa001.jackland.co.uk' '--realm' 'JACKLAND.CO.UK' '--hostname'
'ipa001.jackland.co.uk' '--mkhomedir'' returned non-zero exit status 1
[root@ipa001 log]#
3d:a7:7b:d1:a6:45:b5:9d:d0:00:3e:34:de:b4:7f:0c:
37:0d:fa:1b:bb:32:2c:4b:13:35:b3:98:df:d9:62:8a:
97:3b:54:df:fb:46:f0:29:ea:c1:3d:9d:cf:f8:f8:2d:
c7:3d:c0:50:7d:6d:3f:71:ad:fb:0a:74:ef:e5:eb:c0:
12:7c:96:b3:b0:da:bb:65:f9:a6:33:9f:82:af:99:ee:
50:34:44:84:0f:0e:5f:2a:67:84:b3:cc:5f:95:8c:1a
Fingerprint (MD5):
c3:db:00:21:a0:57:a0:d3:a4:31:a8:80:e2:9b:cb:c1
Fingerprint (SHA1):
77:2f:9f:2a:74:3e:62:09:b9:37:70:a3:74:99:5a:a0:
d5:4a:37:ed
2015-05-28T11:41:25Z DEBUG approved_usage = SSL Server intended_usage =
SSL Server
2015-05-28T11:41:25Z DEBUG cert valid True for
"CN=ipa001.jackland.co.uk,O=JACKLAND.CO.UK"
2015-05-28T11:41:25Z DEBUG handshake complete, peer = 10.220.4.250:443
2015-05-28T11:41:25Z DEBUG Protocol: TLS1.1
2015-05-28T11:41:25Z DEBUG Cipher: TLS_RSA_WITH_AES_128_CBC_SHA
2015-05-28T11:41:25Z ERROR Cannot connect to the server due to generic
error: cannot connect to 'https://ipa001.jackland.co.uk/ipa/json':
Internal Server Error
2015-05-28T11:41:25Z WARNING Installation failed. As this is IPA server,
changes will not be rolled back.
[root@ipa001 ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa: INFO: The ipactl command was successful
[root@ipa001 ~]# cd /tmp
[root@ipa001 tmp]# wget https://ipa001.jackland.co.uk/ipa/json
--2015-05-28 13:45:04-- https://ipa001.jackland.co.uk/ipa/json
Resolving ipa001.jackland.co.uk (ipa001.jackland.co.uk)... 10.220.4.250
Connecting to ipa001.jackland.co.uk
(ipa001.jackland.co.uk)|10.220.4.250|:443... connected.
ERROR: cannot verify ipa001.jackland.co.uk's certificate, issued by
‘/O=JACKLAND.CO.UK/CN=Certificate Authority’:
Self-signed certificate encountered.
To connect to ipa001.jackland.co.uk insecurely, use
`--no-check-certificate'.
[root@ipa001 tmp]# wget --no-check-certificate
https://ipa001.jackland.co.uk/ipa/json
--2015-05-28 13:45:26-- https://ipa001.jackland.co.uk/ipa/json
Resolving ipa001.jackland.co.uk (ipa001.jackland.co.uk)... 10.220.4.250
Connecting to ipa001.jackland.co.uk
(ipa001.jackland.co.uk)|10.220.4.250|:443... connected.
WARNING: cannot verify ipa001.jackland.co.uk's certificate, issued by
‘/O=JACKLAND.CO.UK/CN=Certificate Authority’:
Self-signed certificate encountered.
HTTP request sent, awaiting response... 401 Unauthorized
Authorization failed.
[root@ipa001 tmp]# ls -l /etc/ipa/nssdb/
total 0
[root@ipa001 tmp]#
--
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] client fails to install from ipa-server-install or ipa-replica-install
Bob Hinton wrote:
Hello,
I'm using Puppet to try to install ipa masters and replicas. I can
generally get this to work on Vagrant VMs, but on the target VMs the
server part succeeds until it attempts to install the ipa client and
then this fails (please see extracts of logs below).
The /etc/ipa/nssdb directory is left empty. On a replica I can copy this
from the master along with /etc/openldap/ldap.conf and the client works
(apart from mkhomedir) when sssd is started. Should /etc/ipa/nssdb be
populated on the master at this stage of the installation and, if so,
then why isn't this happening? Selinux is enabled on the target VMs, but
presumably this isn't an issue.
Many thanks
Bob Hinton
trying https://ipa001.jackland.co.uk/ipa/json
Forwarding 'ping' to json server 'https://ipa001.jackland.co.uk/ipa/json'
Cannot connect to the server due to generic error: cannot connect to
'https://ipa001.jackland.co.uk/ipa/json': Internal Server Error
Installation failed. As this is IPA server, changes will not be rolled back.
2015-05-28T11:41:25Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 646, in run_script
return_value = main_function()
File "/usr/sbin/ipa-server-install", line 1292, in main
sys.exit("Configuration of client side components
failed!\nipa-client-install returned: " + str(e))
2015-05-28T11:41:25Z DEBUG The ipa-server-install command failed,
exception: SystemExit: Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install'
'--on-master' '--unattended' '--domain' 'jackland.co.uk' '--server'
'ipa001.jackland.co.uk' '--realm' 'JACKLAND.CO.UK' '--hostname'
'ipa001.jackland.co.uk' '--mkhomedir'' returned non-zero exit status 1
[root@ipa001 log]#
3d:a7:7b:d1:a6:45:b5:9d:d0:00:3e:34:de:b4:7f:0c:
37:0d:fa:1b:bb:32:2c:4b:13:35:b3:98:df:d9:62:8a:
97:3b:54:df:fb:46:f0:29:ea:c1:3d:9d:cf:f8:f8:2d:
c7:3d:c0:50:7d:6d:3f:71:ad:fb:0a:74:ef:e5:eb:c0:
12:7c:96:b3:b0:da:bb:65:f9:a6:33:9f:82:af:99:ee:
50:34:44:84:0f:0e:5f:2a:67:84:b3:cc:5f:95:8c:1a
Fingerprint (MD5):
c3:db:00:21:a0:57:a0:d3:a4:31:a8:80:e2:9b:cb:c1
Fingerprint (SHA1):
77:2f:9f:2a:74:3e:62:09:b9:37:70:a3:74:99:5a:a0:
d5:4a:37:ed
2015-05-28T11:41:25Z DEBUG approved_usage = SSL Server intended_usage =
SSL Server
2015-05-28T11:41:25Z DEBUG cert valid True for
"CN=ipa001.jackland.co.uk,O=JACKLAND.CO.UK"
2015-05-28T11:41:25Z DEBUG handshake complete, peer = 10.220.4.250:443
2015-05-28T11:41:25Z DEBUG Protocol: TLS1.1
2015-05-28T11:41:25Z DEBUG Cipher: TLS_RSA_WITH_AES_128_CBC_SHA
2015-05-28T11:41:25Z ERROR Cannot connect to the server due to generic
error: cannot connect to 'https://ipa001.jackland.co.uk/ipa/json':
Internal Server Error
2015-05-28T11:41:25Z WARNING Installation failed. As this is IPA server,
changes will not be rolled back.
You'd want to check httpd error logs on the server ipa001 to see what
the error is about.
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] Sensible defaults for a new major SSSD release
On Thu, May 28, 2015 at 01:52:30PM +0200, Pavel Reichl wrote: > Hello, > > as part of solution for https://fedorahosted.org/sssd/ticket/2583 ([RFE] > Homedir is always overwritten with subdomain_homedir value in server mode) > we came to the conclusion that it would be a good thing for SSSD in IPA > server mode to change default value of subdomain_homedir from /home/%d/%u to > /home/%o (where %o is original user home directory) and also set > fallback_homedir to /home/%d/%u to handle cases when user doesn't have home > directory attribute set. btw we were considering the change on new installs only, where upgrades would use the previous value. But then Sumit raised a good point that even a clean install doesn't equal a green-field environment -- it can be a new replica in an existing environment.. So right now we're leaning towards keeping the same defaults (/home/%d/%u) and only enabling the user to select the new behaviour (/home/%o) -- 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] OTP vs VPN
"There is no way to define per-service target 2FA yet in FreeIPA." Oh, man... there you go using the "yet" word! ;-) Thanks to you and Ben for the ideas. I'll hack around to see what makes sense. Thanks, Kurt On 5/27/15, 12:33 PM, "Alexander Bokovoy" wrote: >On Wed, 27 May 2015, Bendl, Kurt wrote: >>Hi, >> >>I want to know if I can configure FreeIPA's native OTP solution to >>require an account to use OTP when authenticating from a specific app >>(OpenVPN or StrongSwan) but not require 2FA when logging into a >>system/server or the IPA app. >> >>My (not completely baked) thought is to provision the VPN solution by >>setting up a role or group in IPA that I'd add accounts into. The VPN >>would allow users of that group to auth, using userid and password+OTP >>to successfully. >> >>I've been reading through docs on the freeipa and red hat sites, e.g., >>https://www.freeipa.org/page/V4/OTP/Detail and >>http://www.freeipa.org/page/V4/OTP#Enabling_OTP_and_RADIUS, to >>determine if or how that might be doable. >> >>>From what I read, an alternate approach from FreeIPA's built-in OTP >>>might be to set up a stand-alone OTP solution and use radius and/or a >>>PAM module to handle the VPN auth. >> >>I've DL'd the source, but there's so much there it'll take me some time >>to figure out what's happening. >> >>Any pointers on what approach I should take or where to find some notes >>and examples on how this might be accomplished would be greatly >>appreciated. >There is no way to define per-service target 2FA yet in FreeIPA. > >Setting up OpenVPN against IPA is easy. Use HBAC rules to confine who >can access there. > >As for forcing 2FA for such access, my only suggestion right now is to >have separate user accounts for this purpose. Let's say, they would be >prefixed with vpn- (vpn-userfoo, for example), and then tokens can be >assigned to them. >-- >/ 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] inserting users via java
> On Mar 26, 2015, at 3:08 PM, Dmitri Pal wrote: > > On 03/26/2015 03:19 PM, Timothy Worman wrote: >> On Mar 26, 2015, at 11:42 AM, Martin Kosek wrote: >>> On 03/26/2015 07:37 PM, Timothy Worman wrote: Thanks everyone for the input. I do agree that I don’t like the sound of option 1. I don’t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. 2 sounds like the most solid option available right now. I like the fact that there’s an existing/working API there. I’ll need to look into converting my objects into json. This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. >>> There may be some disconnect, the JSONRPC/XMLRPC API is the way we still >>> see as an easy way to manipulate the entries (besides CLI and Web UI). In >>> Python, adding new user is that easy: >>> >>> ~~~ >>> from ipalib import api >>> from ipalib import errors >>> >>> api.bootstrap(context='cli') >>> api.finalize() >>> api.Backend.rpcclient.connect() >>> api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') >>> ~~~ >>> >>> What way would you suggest to make it more conforming to your use case? Are >>> you suggesting REST interface doing the above or something else? >> Oh, I think the JSON option is the best one currently available. But I do >> think REST-ful service would be a good idea. >> >>> I would be willing to test option 4 if that is where the future is headed. >>> >>> Ok, just note that this still means LDAP interface a need to talk in LDAP >>> protocol. >> This may not be a bad thing if you’re using an ORM like Webobjects/EOF or >> Cayenne since you can model those ldap entities and simply set their >> attributes and insert. At a lower level JNDI will handle it. I personally >> prefer this over building strings, sending commands, etc. > > So this will be ready upstream within several weeks or so. Would you test it > once it it is available before the official upstream release? Hi Dmitri - following up on this to see how progress is going on this project. I am definitely still interested in testing this. In the meantime, I have been pursuing http client calls posting json. And I have some questions I need to pursue on that as well. Should I take this to freeipa-devel? Tim > >> Tim >> Tim > On Mar 24, 2015, at 12:58 AM, Martin Kosek wrote: > > On 03/24/2015 01:29 AM, Dmitri Pal wrote: >> On 03/23/2015 05:56 PM, Timothy Worman wrote: >>> I have an existing web app built with java/WebObjects that currently >>> handles >>> some user/groups tasks with our current directory server (Open >>> Directory). We >>> are investigating a move to FreeIPA for our directory services. >>> >>> Just in mucking around, I’ve found that if I try to insert a new user >>> (inetOrgPerson) into into IPA’s implementation, the new user does not >>> inherit >>> all the object classes it should. It only inherits the ones leading to >>> inetOrgPerson. This does result in a successful inetOrgPerson >>> insertion, but >>> that user record does not show up in the Web GUI management tools. >>> >>> Usually, I have focused on inetOrgPerson because that is where the bulk >>> of >>> the info about a user lives. >>> >>> We have a SQL database that contains people in our organization (used by >>> other services), so, we need to be able to leverage that and push users >>> into >>> IPA when appropriate and we have an existing app to do this. >>> >>> Tim W >>> >> You have several options: >> 1) Call ipa CLI from your application - this is possible right now (but >> not >> quite nice) >> 2) Call ipa JSON API from your application - this is not supported but >> possible. We use python API. You can do it in Java but it will be a lot >> of work. >> 3) Use more elaborate LDAP add commands (with all the object classes >> needed for >> users). Hard, but doable. >> 4) Help us with testing the upcoming feature >> http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would >> allow >> creating users via simple ldap command in a staging area and them moving >> them >> to normal users area with automatic creation of missing attributes by >> means of >> a cron job. >> >> I would vote for 1) as a temp solution and 4) as a longer term one. > I do not fully agree with preferring 1) over 2). Java has libraries for > JSON-RPC protocol, it should be pretty doable to write a call that calls > the > "user_add" command. > > We are lacking proper documentation for the API, but what you can look in > the > sources or in the Web UI with and see the JSONs sent to the server, if
Re: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario.
Thanks for the clarifications, one more question, does FreeIPA support partial or fractional replications? Regards 2015-05-28 0:25 GMT-04:00 Alexander Bokovoy : > On Wed, 27 May 2015, Carlos Raúl Laguna wrote: > >> Hello Martin, Alexander >> >> Seem that the time shift is large between us, If i understand correctly, >> compat tree will allow me to see all users, regardless they location >> Windows or FreeIPA, however the kolab-specific attribute must come from >> FreeIPA and Windows AD where the users entries lays. This means creating >> custom object classes and attributes for AD schema them update compat >> plugin to see the custom attribute. >> >> The second part where kolab needs to update some value in any of this >> attribute, for example mailQuota it would be rejected and therefor it must >> be done from Windows AD or FreeIPA, is this correct? Thanks both of you >> for >> your time and input in this matter. Regards >> > Just to make you absolutely clear: using compat tree will not help you > at all. Nothing else in FreeIPA could help you in getting Kolab to work > with both IPA and AD users at the same time. > > It would be nice if kolab could grow a capability to connect to multiple > LDAP servers at the same time, with non-overlapping user and group > trees. I don't think it is there now and I don't see other possibilities > here. > > > >> 2015-05-27 4:46 GMT-04:00 Alexander Bokovoy : >> >> On Wed, 27 May 2015, Martin Kosek wrote: >>> >>> On 05/27/2015 10:08 AM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Martin Kosek wrote: > > On 05/26/2015 07:36 PM, Carlos Raúl Laguna wrote: >> >> Hello Martin, >>> >>> The email deployment it is a groupware in this scenario Kolab, kolab >>> use >>> 389 ad as main backend and it require some kolab ldap specific >>> attribute to >>> work properly, this is not a problem in fact is quite easy to use >>> freeipa >>> as kolab backend, so far so good but the romance only get this far. >>> Since >>> we also use Windows Ad with forest-trust not all user are present in >>> the >>> FreeIPA directory and there it is where my problem lays. Since not >>> all >>> user >>> are in the same box it become difficult to implement one mail system >>> for >>> all users. Regards >>> >>> >> As I said, we have compat tree that allows LDAP BIND authentication >> and >> LDAP >> identity (not enumeration) for both IPA users and AD users when realm >> is in >> place. >> >> You can even update the configuration of the compat tree and add the >> kolab >> specific fields to be generated there too. There was very similar >> request on >> freeipa-users. It was for vSphere, but dealing with very similar use >> case and >> the final solution: >> >> http://www.freeipa.org/page/HowTo/vsphere5_integration >> >> Would that approach work for you? >> >> I don't think it will work. compat tree is run-time read-only view of > the data coming from somewhere else. You need to have Kolab-specific > data available somewhere to be able to inject it in the compat tree. > Where would that data be stored for Kolab for AD-specific entries? > > It would work as long as the attributes are in the "real" user entries in form of custom attributes and compat plugin can be updated to add those to compat view. What real user entries you are talking about for AD users? >>> >>> Additionally, Kolab wants to modify these custom attributes and compat >>> tree simply does not support modification, they all are refused. > > If Kolab requires modifications, then this approach would not work with current FreeIPA implementation, yes. No, we are not going into enabling modifications over compat tree, this >>> is simply impossible to achieve, sorry. >>> -- >>> / 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 >> > > > -- > / 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] inserting users via java
On 05/28/2015 07:10 PM, Timothy Worman wrote: On Mar 26, 2015, at 3:08 PM, Dmitri Pal wrote: On 03/26/2015 03:19 PM, Timothy Worman wrote: On Mar 26, 2015, at 11:42 AM, Martin Kosek wrote: On 03/26/2015 07:37 PM, Timothy Worman wrote: Thanks everyone for the input. I do agree that I don’t like the sound of option 1. I don’t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. 2 sounds like the most solid option available right now. I like the fact that there’s an existing/working API there. I’ll need to look into converting my objects into json. This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: ~~~ from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.rpcclient.connect() api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') ~~~ What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. I would be willing to test option 4 if that is where the future is headed. Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. This may not be a bad thing if you’re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? Hi Dmitri - following up on this to see how progress is going on this project. I am definitely still interested in testing this. In the meantime, I have been pursuing http client calls posting json. And I have some questions I need to pursue on that as well. Should I take this to freeipa-devel? Hello Timothy, I am sorry we did not update this thread, but in the end we decided not to invest in the REST interface ourselves at this moment (read - FreeIPA 4.2), but rather work on stabilizing and documenting current JSON-RPC API we have as we believe the API is easily usable from major languages even though it is not RESTy. To prove our point, we need good documentation of it and examples for the major languages. This is the proposal of what shall be done in FreeIPA 4.2 that I sent to freeipa-devel: http://www.redhat.com/archives/freeipa-devel/2015-April/msg00061.html I hope the way we go for the next release is acceptable for you. In the mean time, if you have specific questions on calling JSON from your programs, both freeipa-users and freeipa-devel may be suitable, depending on how deep you want to go in the code... 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
[Freeipa-users] ipa-replica-prepare error
We did a CAless install: ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat /etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= --idstart=8000 But now when we try to setup a replica: # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= Directory Manager (existing master) password: The full certificate chain is not present in nwra.com.p12 p12 file was created with: openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey /etc/pki/tls/private/nwra.com.key -certfile /etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12 ipa-server-4.1.0-18.sl7_1.3.x86_64 Any thoughts? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.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] inserting users via java
On Thu, 28 May 2015, Martin Kosek wrote: On 05/28/2015 07:10 PM, Timothy Worman wrote: On Mar 26, 2015, at 3:08 PM, Dmitri Pal wrote: On 03/26/2015 03:19 PM, Timothy Worman wrote: On Mar 26, 2015, at 11:42 AM, Martin Kosek wrote: On 03/26/2015 07:37 PM, Timothy Worman wrote: Thanks everyone for the input. I do agree that I don’t like the sound of option 1. I don’t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. 2 sounds like the most solid option available right now. I like the fact that there’s an existing/working API there. I’ll need to look into converting my objects into json. This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: ~~~ from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.rpcclient.connect() api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') ~~~ What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. I would be willing to test option 4 if that is where the future is headed. Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. This may not be a bad thing if you’re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? Hi Dmitri - following up on this to see how progress is going on this project. I am definitely still interested in testing this. In the meantime, I have been pursuing http client calls posting json. And I have some questions I need to pursue on that as well. Should I take this to freeipa-devel? Hello Timothy, I am sorry we did not update this thread, but in the end we decided not to invest in the REST interface ourselves at this moment (read - FreeIPA 4.2), but rather work on stabilizing and documenting current JSON-RPC API we have as we believe the API is easily usable from major languages even though it is not RESTy. To prove our point, we need good documentation of it and examples for the major languages. This is the proposal of what shall be done in FreeIPA 4.2 that I sent to freeipa-devel: http://www.redhat.com/archives/freeipa-devel/2015-April/msg00061.html I hope the way we go for the next release is acceptable for you. In the mean time, if you have specific questions on calling JSON from your programs, both freeipa-users and freeipa-devel may be suitable, depending on how deep you want to go in the code... I just published a blog post how to use JSON-RPC API in FreeIPA: https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ -- / 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] inserting users via java
On May 28, 2015, at 12:26 PM, Martin Kosek wrote: > > On 05/28/2015 07:10 PM, Timothy Worman wrote: >>> On Mar 26, 2015, at 3:08 PM, Dmitri Pal wrote: >>> >>> On 03/26/2015 03:19 PM, Timothy Worman wrote: On Mar 26, 2015, at 11:42 AM, Martin Kosek wrote: > On 03/26/2015 07:37 PM, Timothy Worman wrote: >> Thanks everyone for the input. >> >> I do agree that I don’t like the sound of option 1. I don’t want to be >> sending CLI commands from a remote host. And option 3 sounds sounds a >> bit brittle to me. >> >> 2 sounds like the most solid option available right now. I like the fact >> that there’s an existing/working API there. I’ll need to look into >> converting my objects into json. >> >> This area honestly seems like one of the weakest aspects of freeipa. >> There really needs to be a way to push known person entities into the >> directory easily. > There may be some disconnect, the JSONRPC/XMLRPC API is the way we still > see as an easy way to manipulate the entries (besides CLI and Web UI). In > Python, adding new user is that easy: > > ~~~ > from ipalib import api > from ipalib import errors > > api.bootstrap(context='cli') > api.finalize() > api.Backend.rpcclient.connect() > api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') > ~~~ > > What way would you suggest to make it more conforming to your use case? > Are you suggesting REST interface doing the above or something else? Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. > I would be willing to test option 4 if that is where the future is headed. > > Ok, just note that this still means LDAP interface a need to talk in LDAP > protocol. This may not be a bad thing if you’re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. >>> >>> So this will be ready upstream within several weeks or so. Would you test >>> it once it it is available before the official upstream release? >> >> Hi Dmitri - following up on this to see how progress is going on this >> project. I am definitely still interested in testing this. In the meantime, >> I have been pursuing http client calls posting json. And I have some >> questions I need to pursue on that as well. Should I take this to >> freeipa-devel? > > Hello Timothy, > > I am sorry we did not update this thread, but in the end we decided not to > invest in the REST interface ourselves at this moment (read - FreeIPA 4.2), > but rather work on stabilizing and documenting current JSON-RPC API we have > as we believe the API is easily usable from major languages even though it is > not RESTy. To prove our point, we need good documentation of it and examples > for the major languages. > > This is the proposal of what shall be done in FreeIPA 4.2 that I sent to > freeipa-devel: > http://www.redhat.com/archives/freeipa-devel/2015-April/msg00061.html > > I hope the way we go for the next release is acceptable for you. In the mean > time, if you have specific questions on calling JSON from your programs, both > freeipa-users and freeipa-devel may be suitable, depending on how deep you > want to go in the code... > > HTH, > Martin Thanks Martin: OK, just to verify - The staging approach (Dmitri spoke about) of inserting records into a staged user schema and having them inserted via a cron job is now off for near releases. I am anxious to see that happen. But, I am working on a java http client (apache httpclient + jaas/Krb5LoginModule) that posts json to the ipaserver. However, I am having some difficulty with kerberos negotiation and I should probably start a separate thread on that - either here or on freeipa-devel. Tim Worman UCLA GSE&IS -- 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] ipa-replica-prepare error
Orion Poplawski wrote: We did a CAless install: ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat /etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= --idstart=8000 But now when we try to setup a replica: # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= Directory Manager (existing master) password: The full certificate chain is not present in nwra.com.p12 p12 file was created with: openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey /etc/pki/tls/private/nwra.com.key -certfile /etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12 ipa-server-4.1.0-18.sl7_1.3.x86_64 Any thoughts? At a glance your creation steps look ok. Strangely, the same code that loads the PKCS#12 files are used both in the server install and replica prepare, the only difference it seems is that with the server install we get a copy of the CA separately too. Can you provide the output of: pk12util -l nwra.com.p12 Maybe we can work out what it thinks is missing. 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] ipa-replica-prepare error
On 05/28/2015 03:09 PM, Rob Crittenden wrote: > Orion Poplawski wrote: >> We did a CAless install: >> >> ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat >> /etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt >> --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 >> --http_pin= --idstart=8000 >> >> But now when we try to setup a replica: >> >> # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 >> --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= >> Directory Manager (existing master) password: >> >> The full certificate chain is not present in nwra.com.p12 >> >> >> p12 file was created with: >> >> openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey >> /etc/pki/tls/private/nwra.com.key -certfile >> /etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12 >> >> ipa-server-4.1.0-18.sl7_1.3.x86_64 >> >> Any thoughts? >> > > At a glance your creation steps look ok. Strangely, the same code that loads > the PKCS#12 files are used both in the server install and replica prepare, the > only difference it seems is that with the server install we get a copy of the > CA separately too. > > Can you provide the output of: pk12util -l nwra.com.p12 > > Maybe we can work out what it thinks is missing. > > rob I think I need to redo our install with an updated (SHA-2?) certificate, but I wouldn't think that would affect this issue either. # pk12util -l nwra.com.p12 Enter password for PKCS12 file: Certificate(has private key): Data: Version: 3 (0x2) Serial Number: 45:22:20:8d:d6:04:19:2a:b1:e7:e5:4f:5e:e0:30:0e Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: "CN=PositiveSSL CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB" Validity: Not Before: Thu Oct 11 00:00:00 2012 Not After : Tue Oct 10 23:59:59 2017 Subject: "CN=*.nwra.com,OU=PositiveSSL Wildcard,OU=Domain Control Val idated" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: d8:08:80:96:8f:f0:80:86:cd:f0:e7:6a:11:7f:8e:fb: 4b:95:6a:42:93:c7:cf:c3:76:80:bd:a6:cc:6c:fd:e2: 89:1a:3f:97:c1:3d:2d:fe:e4:4a:90:c5:aa:33:97:b3: 54:cc:67:73:57:2d:cb:9f:d0:27:ea:f0:d8:9b:5d:24: 94:2f:f5:84:06:d4:04:e8:83:c5:b2:40:b1:59:2c:f8: 4f:73:9c:41:fc:8d:46:3d:be:46:e7:9f:15:5d:8c:a5: 47:23:de:e2:cf:b3:be:97:ed:0c:82:3e:00:29:b7:8b: a0:86:92:ec:07:00:8b:35:77:1c:27:ba:c8:a0:80:dc: 9a:69:dd:99:89:df:b4:70:f6:f6:8c:23:8b:f9:1d:bf: ba:07:32:36:17:bc:25:e7:fb:7a:b0:11:86:de:88:59: 51:ed:e5:de:5e:14:e5:c0:28:ce:d3:5b:92:38:de:fa: 4b:15:9d:62:13:69:31:5a:0d:21:6e:2e:a6:c6:ae:30: 94:95:ce:e6:6c:dc:22:71:b4:1a:3a:f9:ec:4b:72:e4: 9d:82:ba:6b:a5:46:b0:b7:5a:23:22:d3:92:57:5b:bf: 55:fd:70:df:36:13:9c:a9:df:50:6e:62:43:23:13:eb: f5:ef:ee:c7:15:e0:46:37:21:9b:3d:86:ea:2c:c7:01 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 99:e4:40:5f:6b:14:5e:3e:05:d9:dd:d3:63:54:fc:62: b8:f7:00:ac Name: Certificate Subject Key ID Data: e9:88:f0:50:0f:f6:09:89:5c:3d:53:70:38:ca:82:22: 42:7e:21:e3 Name: Certificate Key Usage Critical: True Usages: Digital Signature Key Encipherment Name: Certificate Basic Constraints Critical: True Data: Is not a CA. Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: Certificate Policies Data: Policy Name: OID.1.3.6.1.4.1.6449.1.2.2.7 Policy Qualifier Name: PKIX CPS Pointer Qualifier Policy Qualifier Data: "http://www.positivessl.com/CPS"; Policy Name: OID.2.23.140.1.2.1 Name: CRL Distribution Points Distribution point: URI: "http://crl.comodoca.com/PositiveSSLCA2.crl"; Name: Authority Information Access Method: PKIX CA issuers access method Location: URI: "http://crt.comodoca.com/PositiveSSLCA2.crt"; Method: PKIX Online Certificate Status Protocol Location: URI: "http://ocsp.comodoca.com"; Name: Certificate Subject Alt Name DNS name: "*.nwra.com" DNS name: "nwra.com" Signature Algorithm: PKCS #1 S
[Freeipa-users] SEC_ERROR_LEGACY_DATABASE
Hi, When I try to add multiple hosts, on the web UI, when I go to the host tab, I get Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. What does this mean? On one of the hosts, I do notice that when i do ipa host-show there is no certificate listed. Thanks, David -- 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] dirsrv keytab revoked
Hi I have had a defect entries in ldap for a replica and deleted them. But now the dirsrv keytab (/etc/dirsrv/ds.keytab) doesnt work anymore (revoked). The replica starts but it cant connect other replicas (but other replicas can connect to it). I have tried: kinit -k -t /etc/dirsrv/ds.keytab ldap/ipa-1.mgmt.testsystem-homemonitoring.int and got: kinit: Clients credentials have been revoked while getting initial credentials It is possible to 'regenerate' this keytab? If yes how? Simple ipa-getkeytab (on this replica) doesnt work. Or it is better to destroy it and do a new install? MfG Christoph Kaminski -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Antwort: Re: Haunted servers?
freeipa-users-boun...@redhat.com schrieb am 28.05.2015 13:23:26:
> Von: Alexander Frolushkin
> An: "'thierry bordaz'"
> Kopie: "freeipa-users@redhat.com"
> Datum: 28.05.2015 13:24
> Betreff: Re: [Freeipa-users] Haunted servers?
> Gesendet von: freeipa-users-boun...@redhat.com
>
> Unfortunately, after a couple of minutes, on two of three servers
> error comes back in little changed form:
> # ipa-replica-manage list-ruv
> unable to decode: {replica 16}
>
>
> Before cleanruv it looked like:
> # ipa-replica-manage list-ruv
> unable to decode: {replica 16} 548a81260010 548a81260010
>
>
> And one server seems to be fixed completely.
>
> WBR,
> Alexander Frolushkin
>
>
we had the same problem (and some more) and yesterday we have successfully
cleaned the gohst rid's
our fix:
1. stop all cleanallruv Tasks, if it works with ipa-replica-manage
abort-clean-ruv. It hasnt worked here. We have done it manually on ALL
replicas with:
a) replica stop
b) delete all nsds5ReplicaClean from
/etc/dirsrv/slapd-HSO/dse.ldif
c) replica start
2. prepare on EACH ipa a cleanruv ldif file with ALL ghost rids inside
(really ALL from all ipa replicas, we has had some rids only on some
replicas...)
Example:
dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUV11
dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUV22
dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUV37
...
3. do a "ldapmodify -h 127.0.0.1 -D "cn=Directory Manager" -W -x -f
$your-cleanruv-file.ldif" on all replicas AT THE SAME TIME :) we used
terminator for it (https://launchpad.net/terminator). You can open
multiple shell windows inside one window and send to all at the same time
the same commands...
4. we have done a re-initialize of each IPA from our first master
5. restart of all replicas
we are not sure about the point 3 and 4. Maybe they are not necessary, but
we have done it.
If something fails look at defect LDAP entries in whole ldap, we have had
some entries with 'nsunique-$HASH' after the 'normal' name. We have
deleted them.
MfG
Christoph Kaminski
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
