Problem with dnskeysincd
by Aljaž Srebrnič
Hello everyone!
So, this probably originated with me experimenting with DNSSEC. Things didn’t really work out, so I disabled it following these instructions [1].
Now every couple of minutes I see in my logs ipa-dnskeysync-replica crash on both replicas:
replica1:
> ipa-dnskeysync-replica: DEBUG Got TGT
> ipa-dnskeysync-replica: DEBUG Connecting to LDAP
> ipa-dnskeysync-replica: DEBUG Connected
> ipapython.ipaldap: DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-HQ-MITTELAB-ORG.socket conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7fe957f6e8d0>
> ipa-dnskeysync-replica: DEBUG master keys in local HSM: {’<hex code 1>'}
> ipa-dnskeysync-replica: DEBUG master keys in LDAP HSM: {’<hex code 2>', '<hex code 1>'}
> ipa-dnskeysync-replica: DEBUG new master keys in LDAP HSM: {'<hex code 2>'}
> Traceback (most recent call last):
> File "/usr/libexec/ipa/ipa-dnskeysync-replica", line 181, in <module>
> ldap2replica_master_keys_sync(ldapkeydb, localhsm)
> File "/usr/libexec/ipa/ipa-dnskeysync-replica", line 90, in ldap2replica_master_keys_sync
> "for master key 0x%s" % str_hexlify(mkey_id)
> ValueError: Local HSM does not contain suitable unwrapping key for master key <hex code 1>
Replica2:
> ipa-dnskeysync-replica: DEBUG Got TGT
> ipa-dnskeysync-replica: DEBUG Connecting to LDAP
> ipa-dnskeysync-replica: DEBUG Connected
> ipapython.ipaldap: DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-HQ-MITTELAB-ORG.socket conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f7f3bc2f860>
> ipa-dnskeysync-replica: DEBUG master keys in local HSM: {’<hex code 2>'}
> ipa-dnskeysync-replica: DEBUG master keys in LDAP HSM: {'<hex code 1>', '<hex code 2>'}
> ipa-dnskeysync-replica: DEBUG new master keys in LDAP HSM: {'<hex code 1>'}
> Traceback (most recent call last):
> File "/usr/libexec/ipa/ipa-dnskeysync-replica", line 181, in <module>
> ldap2replica_master_keys_sync(ldapkeydb, localhsm)
> File "/usr/libexec/ipa/ipa-dnskeysync-replica", line 78, in ldap2replica_master_keys_sync
> str_hexlify(mkey_id)
> ValueError: Master key <hex code 1> in LDAP is missing key material referenced by ipaSecretKeyRefObject attribute
Is this a leftover from the DNSSEC configuration? Can I clean that out?
Thanks,
Aljaž
[1]: https://www.freeipa.org/page/Howto/DNSSEC#Disable_current_DNSSEC_key_master
--
Aljaž Srebrnič a.k.a g5pw
My public key: https://g5pw.me/key
Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677
5 years, 4 months
Changing allow-recursion in named.conf - issues / gotchas ?
by Jonathan Vaughn
We have a use case for letting the FreeIPA named instances handle public
DNS for some zones, but we don't want them to allow anyone to use it as a
recursive resolver (DOS attacks and such).
I tested simply changing 'any' to 'none' for the allow-recursion setting in
/etc/named.conf and that worked as expected - the next step being to
actually set it like we have our existing non-IPA servers configured to
allow only internal/known public subnets to perform recrusion, which I
expect will work as well (using a named ACL instead of none/any).
Is there a nice UI way (or command line) to change the allow-recursion
setting in way that is more in line with the usual management of settings
for FreeIPA, and would ensure it wouldn't get overwritten at some point by
FreeIPA? Is that even a concern, or should we expect that /etc/named.conf
is going to be safe from changes due to anything like adding/removing
replicas and so on (looks like that may all be in LDAP)?
5 years, 4 months
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
5 years, 4 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...
5 years, 4 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
5 years, 4 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
5 years, 4 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
5 years, 4 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 :)
5 years, 4 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?
5 years, 4 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.
5 years, 4 months