Everything getting lowercased migrating between FreeIPA instances
by Mitchell Smith
Hi List,
I am trying to migrate an old FreeIPA 4.3.1 server running on Ubuntu
16.04 to a new FreeIPA 4.5.4 server running on Centos 7.
I am doing the migration via the "ipa migrate-ds" command, the command
is running successfully and the users get migrated, even the custom
schema attributes come over which is nice, but everything is getting
converted to lowercase, even things like object classes, which is
causing some issues for things talking to LDAP and expecting specific
values.
A very simplistic example without going in to our custom schema is
ObjectClass: posixAccount
and after the migration
ObjectClass: posixaccount
I have tweaked /usr/lib/python2.7/site-packages/ipaserver/plugins/migration.py
as follows to try and work around this however the migration is still
lowercasing everything.
If anyone could please suggest where else in the code I should start
digging where the migration might be getting normalized into
lowercase, I would really appreciate any feedback.
--- migration.orig 2018-11-22 00:50:07.335290536 +0000
+++ migration.py 2018-11-22 00:51:40.938290536 +0000
@@ -284,7 +284,7 @@
continue
api.log.debug('converting DN value %s for %s in %s' %
(value, attr, dn))
- rdnval = remote_entry[primary_key][0].lower()
+ rdnval = remote_entry[primary_key][0]
entry_attrs[attr][ind] = DN((primary_key, rdnval),
container, api.env.basedn)
return dn
@@ -697,7 +697,7 @@
for name in names:
if options[name]:
options[name] = tuple(
- v.lower() for v in options[name]
+ v for v in options[name]
)
else:
options[name] = tuple()
@@ -801,9 +801,9 @@
# In case if pkey attribute is in the migrated object DN
# and the original LDAP is multivalued, make sure that
# we pick the correct value (the unique one stored in DN)
- pkey = ava.value.lower()
+ pkey = ava.value
else:
- pkey = entry_attrs[ldap_obj.primary_key.name][0].lower()
+ pkey = entry_attrs[ldap_obj.primary_key.name][0]
if pkey in exclude:
continue
@@ -813,10 +813,10 @@
set(
config.get(
ldap_obj.object_class_config, ldap_obj.object_class
- ) + [o.lower() for o in entry_attrs['objectclass']]
+ ) + [o for o in entry_attrs['objectclass']]
)
)
- entry_attrs[ldap_obj.primary_key.name][0] =
entry_attrs[ldap_obj.primary_key.name][0].lower()
+ entry_attrs[ldap_obj.primary_key.name][0] =
entry_attrs[ldap_obj.primary_key.name][0]
callback = self.migrate_objects[ldap_obj_name]['pre_callback']
if callable(callback):
Thanks for any suggestions.
Cheers
3 years, 5 months
How to find users who do not have a password set yet
by Ryan Slominski
I'm trying to find out which users do not have a password set yet. The "ipa user-find" command doesn't seem to allow filtering by "existence of password". Further, it doesn't show whether the password exists in output anyways. The user-show and user-add commands can show a "Password: False" output though. The web interface is also capable of indicating no password. Any ideas? Do I need to resort to LDAP "directory manager" queries? Can "admin" user configure Permissions/Privlidges to fix this? I couldn't find a "has_password" anywhere in the web console - just a userPassword field, which might work, but seems dangerous - I don't want to see the password (or hash of password) - I want to see if it exists or not, just like the GUI already reveals. Searching around the closest discussion found was:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
3 years, 5 months
OCSP responses for an external CA
by Andrew C Dingman
Hi, all
I'm not sure the following is feasible, but IHAC who may want to use
IPA in an air-gapped network while relying on smart card authentication
using certificates from a very large, external CA. Can anyone give me
an idea of whether the following scenario is feasible, and if so,
supportable?
External certificate authority E issues user certificates and
provisions smart card tokens. (It runs RHCS, if that matters.) Inside
the isolated network, users are separately maintained in IPA domain P.
When each user is created in P, a certificate issued by E is added to
the user's entry. That certificate is used for pkinit and ssl/tls
client authentication to services in P.
So far, my understanding is that this should be feasible provided that
E is added as a trusted authority in various places, but I'm a little
fuzzy on the pkinit piece. Where it gets really problematic is dealing
with CRLs.
Because P and its relying parties are isolated, they can't use OCSP to
check current validity of a certificate. To avoid the hassles of
distributing CRLs to all relying systems and services manually, would
it be possible to add those CRLs to the set served by the OCSP
responder in P? Obviously the responses would be signed by P rather
than E, but if P has verified the CRL on which they were based it seems
at least potentially viable.
As currently envisioned, E would be completely unaware of the existence
of P, but P would trust certificates issued by E. If that isn't
feasible, would it make any difference if P's CA were subordinate to E?
Thanks in advance for any guidance you can offer.
-Andrew
3 years, 5 months
OCSP responses for an external CA
by Andrew C Dingman
Hi, all
I'm not sure the following is feasible, but IHAC who may want to use
IPA in an air-gapped network while relying on smart card authentication
using certificates from a very large, external CA. Can anyone give me
an idea of whether the following scenario is feasible, and if so,
supportable?
External certificate authority E issues user certificates and
provisions smart card tokens. (It runs RHCS, if that matters.) Inside
the isolated network, users are separately maintained in IPA domain P.
When each user is created in P, a certificate issued by E is added to
the user's entry. That certificate is used for pkinit and ssl/tls
client authentication to services in P.
So far, my understanding is that this should be feasible provided that
E is added as a trusted authority in various places, but I'm a little
fuzzy on the pkinit piece. Where it gets really problematic is dealing
with CRLs.
Because P and its relying parties are isolated, they can't use OCSP to
check current validity of a certificate. To avoid the hassles of
distributing CRLs to all relying systems and services manually, would
it be possible to add those CRLs to the set served by the OCSP
responder in P? Obviously the responses would be signed by P rather
than E, but if P has verified the CRL on which they were based it seems
at least potentially viable.
As currently envisioned, E would be completely unaware of the existence
of P, but P would trust certificates issued by E. If that isn't
feasible, would it make any difference if P's CA were subordinate to E?
Thanks in advance for any guidance you can offer.
-Andrew
3 years, 5 months
replica unable to communicate
by Andrew Meyer
I need some help with this. I am working with FreeIPA runnning on CentOS 7.4 verssion 4.5.0-22. I have 2 servers in my AWS VPC and 2 servers at my local office.
For some reason I am not seeing replication happen (over ldaps?) from 1 server in my local office to the two servers up there.
AWS servers:
[centos@freeipa03 ~]$ sudo ipa-replica-manage list -v freeipa01.stl1.gatewayblend.netfreeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:25:31+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:25:31+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:30:31+00:00[centos@freeipa03 ~]$ sudo ipa-replica-manage list -v freeipa03.stl1.gatewayblend.netfreeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00freeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[centos@freeipa03 ~]$
[root@freeipa04 log]# ipa-replica-manage list -v freeipa03.stl1.gatewayblend.netfreeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00freeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[root@freeipa04 log]# ipa-replica-manage list -v freeipa01.stl1.gatewayblend.netfreeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:25:31+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:25:31+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:30:31+00:00[root@freeipa04 log]#
Local office:server 1
[gatewayblend@freeipa01 ~]$ sudo ipa-replica-manage list -v freeipa04.east.gatewayblend.netfreeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 13:24:41+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 13:24:32+00:00freeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[gatewayblend@freeipa01 ~]$ sudo ipa-replica-manage list -v freeipa03.east.gatewayblend.netfreeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 13:30:53+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 13:30:53+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[gatewayblend@freeipa01 ~]$
[gatewayblend@freeipa03 ~]$ sudo ipa-replica-manage list -v freeipa04.east.gatewayblend.netfreeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:08:00+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:07:54+00:00freeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[gatewayblend@freeipa03 ~]$ sudo vim /etc/resolv.conf[gatewayblend@freeipa03 ~]$ sudo ipa-replica-manage list -v freeipa03.east.gatewayblend.netfreeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:40:35+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:40:35+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[gatewayblend@freeipa03 ~]$
The topologysegment shows we have 2-way connectivity all the way around:[root@freeipa04 log]# ipa topologysegment-find --allSuffix name: domain------------------6 segments matched------------------ dn: cn=freeipa01.stl1.gatewayblend.net-to-freeipa03.stl1.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa01.stl1.gatewayblend.net-to-freeipa03.stl1.gatewayblend.net Left node: freeipa01.stl1.gatewayblend.net Right node: freeipa03.stl1.gatewayblend.net Connectivity: both iparepltoposegmentstatus: autogen objectclass: iparepltoposegment, top
dn: cn=freeipa01.stl1.gatewayblend.net-to-freeipa04.east.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa01.stl1.gatewayblend.net-to-freeipa04.east.gatewayblend.net Left node: freeipa01.stl1.gatewayblend.net Right node: freeipa04.east.gatewayblend.net Connectivity: both objectclass: iparepltoposegment, top
dn: cn=freeipa03.east.gatewayblend.net-to-freeipa01.stl1.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa03.east.gatewayblend.net-to-freeipa01.stl1.gatewayblend.net Left node: freeipa03.east.gatewayblend.net Right node: freeipa01.stl1.gatewayblend.net Connectivity: both objectclass: iparepltoposegment, top
dn: cn=freeipa03.east.gatewayblend.net-to-freeipa04.east.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa03.east.gatewayblend.net-to-freeipa04.east.gatewayblend.net Left node: freeipa03.east.gatewayblend.net Right node: freeipa04.east.gatewayblend.net Connectivity: both iparepltoposegmentstatus: autogen objectclass: iparepltoposegment, top
dn: cn=freeipa03.stl1.gatewayblend.net-to-freeipa03.east.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa03.stl1.gatewayblend.net-to-freeipa03.east.gatewayblend.net Left node: freeipa03.stl1.gatewayblend.net Right node: freeipa03.east.gatewayblend.net Connectivity: both objectclass: iparepltoposegment, top
dn: cn=freeipa03.stl1.gatewayblend.net-to-freeipa04.east.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa03.stl1.gatewayblend.net-to-freeipa04.east.gatewayblend.net Left node: freeipa03.stl1.gatewayblend.net Right node: freeipa04.east.gatewayblend.net Connectivity: both objectclass: iparepltoposegment, top----------------------------Number of entries returned 6----------------------------[root@freeipa04 log]#
When I add a user everything gets sync'ed. When I add a DNS entry its gets sync'ed all the way around.
Is the error i'm getting a false positive? It seems like it is.
This is the error I'm getting in /var/log/messages. However I think this pertains to DNSSEC and can be ignored, correct?
Mar 21 13:35:25 freeipa01 systemd: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILUREMar 21 13:35:25 freeipa01 systemd: Unit ipa-dnskeysyncd.service entered failed state.Mar 21 13:35:25 freeipa01 systemd: ipa-dnskeysyncd.service failed.Mar 21 13:36:25 freeipa01 systemd: ipa-dnskeysyncd.service holdoff time over, scheduling restart.Mar 21 13:36:25 freeipa01 systemd: Started IPA key daemon.Mar 21 13:36:25 freeipa01 systemd: Starting IPA key daemon...Mar 21 13:36:28 freeipa01 ipa-dnskeysyncd: ipa : INFO LDAP bind...Mar 21 13:36:28 freeipa01 ipa-dnskeysyncd: ipa : INFO Commencing sync processMar 21 13:36:29 freeipa01 ipa-dnskeysyncd: ipa.ipaserver.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump is done, sychronizing with ODS and BINDMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: Traceback (most recent call last):Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 114, in <module>Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in syncrepl_pollMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: self.syncrepl_refreshdone()Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 115, in syncrepl_refreshdoneMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: self.hsm_replica_sync()Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 181, in hsm_replica_syncMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA])Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 512, in runMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: raise CalledProcessError(p.returncode, arg_string, str(output))Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: subprocess.CalledProcessError: Command '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status 1Mar 21 13:36:33 freeipa01 systemd: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILUREMar 21 13:36:33 freeipa01 systemd: Unit ipa-dnskeysyncd.service entered failed state.Mar 21 13:36:33 freeipa01 systemd: ipa-dnskeysyncd.service failed.Mar 21 13:37:33 freeipa01 systemd: ipa-dnskeysyncd.service holdoff time over, scheduling restart.Mar 21 13:37:33 freeipa01 systemd: Started IPA key daemon.Mar 21 13:37:33 freeipa01 systemd: Starting IPA key daemon...Mar 21 13:37:36 freeipa01 ipa-dnskeysyncd: ipa : INFO LDAP bind...Mar 21 13:37:36 freeipa01 ipa-dnskeysyncd: ipa : INFO Commencing sync processMar 21 13:37:36 freeipa01 ipa-dnskeysyncd: ipa.ipaserver.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump is done, sychronizing with ODS and BINDMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: Traceback (most recent call last):Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 114, in <module>Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in syncrepl_pollMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: self.syncrepl_refreshdone()Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 115, in syncrepl_refreshdoneMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: self.hsm_replica_sync()Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 181, in hsm_replica_syncMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA])Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 512, in runMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: raise CalledProcessError(p.returncode, arg_string, str(output))Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: subprocess.CalledProcessError: Command '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status 1Mar 21 13:37:40 freeipa01 systemd: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILUREMar 21 13:37:40 freeipa01 systemd: Unit ipa-dnskeysyncd.service entered failed state.Mar 21 13:37:40 freeipa01 systemd: ipa-dnskeysyncd.service failed.[gatewayblend@freeipa01 ~]$
I'm not sure what the issue is.
Any help is appreciated.
Thank you,Andrew Meyer
3 years, 5 months
Force TLS connection
by Peter Tselios
Hello,
My understanding is that FreeIPA is configured to accept connections on port 389 and the StartTLS is configured.
I managed to connect to the IPA server by using ldapsearch -x and without -ZZ so, I suppose the TLS is not enforced.
Is there any option force TLS connections only? Obviously, I would prefer something that can be replicated and not to manually edit the configuration files, but I can live with that :)
3 years, 5 months
LDAP Group Membership puzzle
by Peter Tselios
Hello,
I have an non-IPA aware application to succssfuly login users from IPA's LDAP.
However, I cannot make it work with group membership. It seems that the LDAP filter is not working and using LDAP search proves that the app is not wrong.
So, what I have:
myself (ptselios) member of the group grafana-adms.
The group is stored as:
ldapsearch -x -W -D "uid=nonipaapps,cn=sysaccounts,cn=etc,dc=example,dc=com" -b "cn=groups,cn=accounts,dc=example,dc=com" "(&(objectClass=groupOfNames)(cn=grafana-adms))" -h localhost -p 389 -s sub
dn: cn=grafana-adms,cn=groups,cn=accounts,dc=example,dc=com
member: uid=ptselios,cn=users,cn=accounts,dc=example,dc=com
member: uid=anotheruser,cn=users,cn=accounts,dc=example,dc=com
ipaNTSecurityIdentifier: S-1-5-21-120251393-583861438-3385547448-1050
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
cn: grafana-adms
description:: blabla
ipaUniqueID: ccc54368-ce1d-11e8-b523-06db1b82a33a
gidNumber: 690200050
Now, when I search with the memberuid I get an empty response:
ldapsearch -x -W -D "uid=nonipaapps,cn=sysaccounts,cn=etc,dc=example,dc=com" -b "cn=groups,cn=accounts,dc=example,dc=com" "(&(objectClass=groupOfNames)(memberuid=ptselios))" -h localhost -p 389 -s sub
# search result
search: 2
result: 0 Success
# numResponses: 1
Obviously, the filter is wrong, but what is the correct one?
3 years, 5 months
Export service keytab as Active Directory user
by Michael Gusek
Hi,
we are running FreeIPA 4.5.4 on Centos 7 with a one way trust to an
Active Directory. We want to allow AD users to retrieve service keytab
on FreeIPA managed hosts. AD users are linked to a external group, and
these group to a FreeIPA group. We've created a service and allowed
FreeIPA group (for testing external group too) to retrieve keytab. Now
we logged in with AD credentials to a FreeIPA managed host, got an
ticket with kinit user@AD-domain and tried to retrieve keytab for
service, which runs in an error "Failed to parse result: Insufficient
access rights". With an FreeIPA user, added to FreeIPA group above, it
works.
So what we are missing here ? Is it possible to retrieve service keytabs
as a trusted AD user ?
Thanks.
3 years, 5 months
tomcatd - Could not connect to LDAP server host
by Jack Henschel
Hello,
we ran into an issue after an upgrade to FreeIPA 4.6.4, API_VERSION:
2.229 (using the current Docker Image Fedora 27)
The ipa-upgrade ran without issues, but pki-tomcatd is causing trouble
after the upgrade.
The tomcatd system log:
0.localhost-startStop-1 - [05/Nov/2018:08:44:41 UTC] [8] [3] In Ldap
(bound) connection pool to host ipa port 636, Cannot connect to LDAP
server. Error: netscape.ldap.LDAPException: Unable to create socket:
java.net.ConnectException: Connection refused (Connection refused) (-1)
Tomcat Debug log:
java.net.ConnectException: Connection refused (Connection refused)
at java.net.PlainSocketImpl.socketConnect(Native Method)
Could not connect to LDAP server host ipa port 636 Error
netscape.ldap.LDAPException: Unable to create socket:
java.net.ConnectException: Connection refused (Connection refused) (-1)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)
Internal Database Error encountered: Could not connect to LDAP
server host ipa port 636 Error netscape.ldap.LDAPException: Unable to
create socket: java.net.ConnectException: Connection refused (Connection
refused) (-1)
at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:689)
However, the dirsrv starts just seconds afterwards:
Nov 05 08:44:45 ipa ns-slapd[90]: [05/Nov/2018:08:44:45.159306972
+0000] - INFO - slapd_daemon - slapd started. Listening on All
Interfaces port 389 for LDAP requests
Nov 05 08:44:45 ipa ns-slapd[90]: [05/Nov/2018:08:44:45.162543716
+0000] - INFO - slapd_daemon - Listening on All Interfaces port 636 for
LDAPS requests
Nov 05 08:44:45 ipa systemd[1]: Started 389 Directory Server
Then, certmonger fails to start (probably trying to reach tomcatd, I
assume):
Nov 05 08:45:41 ipa systemd[1]: certmonger.service: Start-post
operation timed out. Stopping.
Nov 05 08:45:50 ipa server[231]: WARNING: Exception processing
realm com.netscape.cms.tomcat.ProxyRealm@3b86a3a1 background process
Nov 05 08:45:50 ipa server[231]:
javax.ws.rs.ServiceUnavailableException: Subsystem unavailable
Nov 05 08:45:50 ipa server[231]: at
com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:130)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1156)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5740)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:
1379)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:
1383)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1351)
Nov 05 08:45:50 ipa server[231]: at
java.lang.Thread.run(Thread.java:748)
Nov 05 08:45:56 ipa systemd[1]: Failed to start Certificate
monitoring and PKI enrollment.
Nov 05 08:45:56 ipa systemd[1]: certmonger.service: Unit entered
failed state.
Nov 05 08:45:56 ipa systemd[1]: certmonger.service: Failed with
result 'timeout'.
After that, IPA shuts down after 300 sec.
Nov 05 08:50:01 ipa systemd[1]: Stopping Kerberos 5 KDC...
Nov 05 08:50:01 ipa systemd[1]: Stopped Kerberos 5 KDC.
Nov 05 08:50:01 ipa systemd[1]: Stopping Kerberos 5
Password-changing and Administration...
Nov 05 08:50:01 ipa systemd[1]: kadmin.service: Main process
exited, code=exited, status=2/INVALIDARGUMENT
Nov 05 08:50:01 ipa systemd[1]: Stopped Kerberos 5
Password-changing and Administration.
Nov 05 08:50:01 ipa systemd[1]: kadmin.service: Unit entered failed
state.
Nov 05 08:50:01 ipa systemd[1]: kadmin.service: Failed with result
'exit-code'.
Nov 05 08:50:02 ipa systemd[1]: Stopping The Apache HTTP Server...
Nov 05 08:50:03 ipa systemd[1]: Stopped The Apache HTTP Server.
Nov 05 08:50:03 ipa systemd[1]: Stopping IPA Custodia Service...
Nov 05 08:50:03 ipa systemd[1]: Stopped IPA Custodia Service.
Nov 05 08:50:03 ipa ntpd[73]: ntpd exiting on signal 15 (Terminated)
Nov 05 08:50:03 ipa ntpd[73]: 127.127.1.0 local addr 127.0.0.1 ->
Nov 05 08:50:03 ipa systemd[1]: Stopping Network Time Service...
Nov 05 08:50:03 ipa systemd[1]: Stopped Network Time Service.
Nov 05 08:50:03 ipa systemd[1]: Stopped target PKI Tomcat Server.
Nov 05 08:50:03 ipa systemd[1]: Stopping PKI Tomcat Server
pki-tomcat...
The error is consistent enough, it seems LDAP only comes up seconds
after tomcat tries to reach it.
Nov 05 09:34:57 ipa server[231]: Internal Database Error
encountered: Could not connect to LDAP server host ipa port 636 E rror
netscape.ldap.LDAPException: Unable to create socket:
java.net.ConnectException: Connection refused (Connection refused) (-1)
Nov 05 09:34:59 ipa ns-slapd[83]: [05/Nov/2018:09:34:59.793590657
+0000] - INFO - slapd_daemon - slapd started. Listening on All
Interfaces port 389 for LDAP requests
Nov 05 09:34:59 ipa ns-slapd[83]: [05/Nov/2018:09:34:59.812565603
+0000] - INFO - slapd_daemon - Listening on All Interfaces port 636 for
LDAPS requests
Nov 05 09:34:59 ipa ns-slapd[83]: [05/Nov/2018:09:34:59.814451330
+0000] - INFO - slapd_daemon - Listening on
/var/run/slapd-VISION-FHG-DE.socket for LDAPI requests
Since it's not an Authentication Error, as described here:
https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tom...
I don't think this is an issue with the certificates. Nonetheless, I
checked them and it seems fine.
When starting FreeIPA via ipactl start, however, the system starts -
certmonger remains failed though. The system isn't fully functional though.
This is how we start the Container:
/usr/bin/docker run \
-h 'ipa' --net bridge -m 0b -e IPA_SERVER_IP=192.168.2.15 \
-e IPA_SERVER_HOSTNAME=ipa \
-p 80:80 \
-p 443:443 \
-p 88:88/tcp \
-p 88:88/udp \
-p 389:389 \
-p 636:636 \
-p 7389:7389 \
-p 464:464/tcp \
-p 464:464/udp \
-p 123:123 \
-p 9443:9443 \
-p 9444:9444 \
-p 9445:9445 \
-v /data/ipa:/data:Z \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
--tmpfs /tmp --tmpfs /run --sysctl net.ipv6.conf.all.disable_ipv6=0
--cap-add=SYS_ADMIN --cap-add SYS_TIME \
--name freeipa \
freeipa/freeipa-server:fedora-27 \
Any idea what might cause this, or how we can futher debug it?
3 years, 5 months
