How to change ipaUniqueId
by Antoine Gatineau
Hello all.
I am trying to migrate my users from one ipa to another one.
I was able to import the users and groups with 'ipa migrate-ds'. However the migration process generates new ipaUniqueIds.
IPA is my source of users for keycloak user federation and other applications that use ipaUniqueId to identify the user.
When syncing from ipa, they now report a conflict as they should.
So is it possible (and how) to manually set the ipaUniqueId to the value it had originally?
I have seen that ipa user-mod --setattr is now locked for this attribute : https://bugzilla.redhat.com/show_bug.cgi?id=634194
Thank you for any pointer to a solution.
Antoine
1 year, 8 months
Re: /run/ipa/ccaches filling
by Jochen Kellner
Charles Hedrick via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
writes:
> it's active, but it seems not to do anything:
>
> ● ipa-ccache-sweep.timer - Remove Expired Kerberos Credential Caches
> Loaded: loaded (/usr/lib/systemd/system/ipa-ccache-sweep.timer; enabled; vendor preset: disabled)
> ---------
>
> I believe the intent is that it should run every 12 hours. It doesn't
> seem to be doing so. From a web discussion:
That's the same on my system... I did enable and start the timer with my
local ansible plav - but that only worked for the current boot.
> OnUnitActiveSec does indeed refer to the time since the service
> referred to by the timer has run. But if you only use OnUnitActiveSec
> and no other trigger then issue the command to start or enable
> foo.timer, foo.service will never run. Why would it, no trigger would
> ever be activated in the first place: something needs to trigger the
> first run of foo.service in order to for you to ever have 3 seconds
> pass since it was last run.
>
> So in other words, OnUnitActiveSec can be used to define the interval
> between repetitions, but another trigger (like OnActiveSec or
> OnBootSec) would be needed to trigger the first run of foo.service to
> get the ball rolling.
In other words: you must also enable the
/usr/lib/systemd/system/ipa-ccache-sweep.service.
That way it will run once at system reboot and later every 12
hours. I've just changed my playbook and I'll see with the next reboot
how that works out.
Jochen
--
This space is intentionally left blank.
1 year, 8 months
Re: /run/ipa/ccaches filling
by Jochen Kellner
Charles Hedrick via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
writes:
> RHEL 9.0. /run/ipa/ccaches is filling with credential caches. Many are too old to be valid.
>
> I assume it's safe to have a cron job delete any more than a day old?
> (that's our maxmum lifetime.) I can't see the lifetime directly,
> because they are encrypted.
On my system I have a (disabled( systemd-timer named
ipa-ccache-sweep.timer. My guess would be that it get's enabled on new
installs, but somehow missed on updates. See the release notes of 4.9.9:
https://www.freeipa.org/page/Releases/4.9.9
Jochen
--
This space is intentionally left blank.
1 year, 8 months
Kerberos Auth (GSSAPI) with NATed IPs
by Carlos Mogas da Silva
Hi list!
I'm having a problem where a, in this case, IMAP server (dovecot), configured to do auth via GSSAPI,
doesn't authenticate clients coming from the NATed IP it has. Physically it only has a private IP
attached (10.1.0.0/8) but it also has a NATed public IP from the internet. The NAT is done on the
router/firewall before it get's to the server itself.
I've read about extra_addresses on the /etc/krb5.conf file but that doesn't look like it does the
trick of making the authentication work.
If I somehow force the clients to authenticate to the private IP (via hosts file for example), the
auth succeeds.
Is this fixable? Thanks!
1 year, 8 months
/run/ipa/ccaches filling
by Charles Hedrick
RHEL 9.0. /run/ipa/ccaches is filling with credential caches. Many are too old to be valid.
I assume it's safe to have a cron job delete any more than a day old? (that's our maxmum lifetime.) I can't see the lifetime directly, because they are encrypted.
1 year, 8 months
IPA Error 4301: Certificate operation cannot be completed: unable to communicate with CMS (503).
by lol lol
Hello,
I see the message in the title when I try to check certificates via web interface in authentication section.
Apparently I can still access them with getcert list which shows a bunch of certificates in monitoring mode.
However apparently it's the same api used both during replication and by the web client. So replication fails during CA set-up saying that it couldn't connect to the REST IPA of CA.
pki-server subsystem-show ca
shows that CA is enabled
pki ca-cert-show
ERROR: Missing Serial Number.
I have checked documentation and troubleshooting advice and they don't seem to cover my case.
Do you have any suggestions, please?
For the info, I upgraded from version 4.6.x I believe. I also created a replica to test replication with CA, which worked fine btw, but then removed it almost immediately.
Thank you.
1 year, 8 months
FreeIPA <- Keycloak
by Yavor Marinov
Hello all,
I have an issue configuring both systems Keycloak and FreeIPA to work with
User Federation. Configuration on Keycloak side for the ldap (FreeIPA
server) is as follows:
- LDAPs configuration
- Keytab from FreeIPA generated with admin user
The below screenshot is from the Keycloak User Federation:
[image: image.png]
[image: image.png]
Importing users works flawlessly but the problems comes when I try to
create user in Keycloak and expect it to be created on FreeIPA side -
WRITABLE is on, and keycloak machine is enrolled into FreeIPA as a client
(both OSes are Alma). There is no error, and Keycloak indicates that a new
user is created.
However, in FreeIPA's web interface the user is missing and the most
frustrating thing is if i try to create the very same username, FreeIPA
returns that it can't add the user, because it already *exists*. I guess
the issue would be somewhere either in Username/RDN LDAP attribute or UUID
or even Custom User LDAP filter, but i'm lost a bit.
In case someone wants to help here what i've tried to play with:
- Setting UUID Ldap attribute to ipaUniqueID, but using it, returns 0
user when trying to sync, and creating user from Keycloak returns error
- Setting custom ldap filter to match a group from the LDAP - no binding
with admin user could be achieved, thus no user could be synced
Anyhelp on this will be much appreciated :")
Thank you in advance
1 year, 9 months
DNS/DNSSEC via freeipa/bind9 supporting Unbound
by Harry G. Coin
Alexander Bokovoy asked for a note on the use of Unbound as a slave
resolver to freeipa's bind9+dnssec because of the issues discussed under
Re: [Freeipa-users] Re: Dnssec rejected by Cloudflair, Google, accepted
by Verizon, AT&T
Summarizing: Unbound is just a lot faster than bind9+dnssec,
additionally offering native support for DANE, DNS over tls and etc.
Older hardware running bind9 can't process DNS + DNSSec queries under
the timeout limits used by major public dns resolvers relied upon by
thousands, including mail providers. Unbound can and does.
Steps:
1. Work with existing freeipa tools and documentation to get dnssec
working properly under bind9, validate it using at least two of the
public dnssec diagnostic tools (verisign, etc.).
2. Use global dns performance testing tools to see whether all report
good results from several dozen of the world's public dns resolvers. If
they all report 'green' or 'ok', then your servers are 'fast enough' and
you don't need this further work (unless you want DANE, dns over tls and
the other things unbound offers).
3. For at least one, and preferably at least as many freeipa
master/slaves identify an ip4 (and ip6) address for use by the unbound
resolver service. It's best if they are in the same subnet as at least
one of the freeipa machine's interfaces and preferably secured for
physical reasons or, second best, encryption.
4. Load those addresses into the 'Allow Transfer' section of Freeipa's
dns domain manager settings window. Be sure reasonable values exist in
every section measured in (seconds). I also chose to edit
/etc/named/ipa-options-ext.conf to 'notify explicit; also-notify { all
freeipa and unbound addresses other than the current host } ;
allow-notify { only freeipa and not unbound addresses; } You might
take the chance to set up acls and make good decisions about rate
limiting and allow-* settings. I found only rebooting freeipa & bind9
caused bind9 to get the updated 'allow transfer' settings from freeipa.
Restarting bind9 alone was not enough.
5. Either in a new network name space on the same host as freeipa or in
a vm on that host, or, well, anywhere really except on the same set of
addresses as freeipa's named daemon: Load unbound and prove up it is
working under default settings using the addresses reserved above.
6. Create a file in unbound.conf.d for access control. I suggest
leading it off with
access-control: 0.0.0.0/0 refuse_non_local
access-control: ::0/0 refuse_non_local
access-control: 127.0.0.0/8 allow_snoop
access-control: ::1 allow_snoop
followed by whatever local address ranges you'd like for full dns
recursive services, such as your 'lan' or equivalent eg
access-control: 10.something.whatnot.0/24 allow
In an related 'options' file, include 'interface' lines for each host
address you want unbound to process incoming queries (your local lan
interface as well), and including at least one of the host addresses you
entered into freeipa above. Include 'outgoing-interface' lines the
interface on the unbound host that matches at least one of the addresses
entered into freeipa.
In another file, or one file per zone, add an 'auth-zone:' section using
'name:' as the zone to support, and 'primary:..." entries for each
freeipa server.
7. Restart unbound. use dig @unbound-serverip to validate proper operation.
8. Change NS records on all servers to be handled by unbound to point to
the unbound's interfaces named in the 'interface' lines above. I chose
to have public IPs point at the unbound supported slave resolvers, and
left all local lan resolution using freeipa, since there was no security
value added by dns over tls & etc owing to the physical site-wire
security. But YMMV.
9. Revalidate proper DNSSEC validation and worldwide resolver
performance/accuracy.
In my case, 'ancient' servers passed all tests using the unbound
frontend with and without dnssec. They also passed using freeipa's
setup without dnssec (nearly always, one in Australia and one in Brazil
would occasionally fail). Freeipa's servers with dnssec passed most of
them, but failed google and cloudflare always, occasionally one or two
others but passed most.
There are a fair few other options to do with performance and features
you can add and manage, well documented by the unbound support folks.
That's it! Hope that helps others.
Harry Coin
https://rockstablesystems.com
1 year, 9 months
IdM with trust relationship with Samba AD DC - User accounts with passwords expired
by Mateo Duffour
Hi,
We currently have an IdM installation with a trust relationship with a Samba AD DC. Our user accounts reside on Samba AD DC, we dont have user accounts on IdM.
We are having a problem with Samba user acounts that have its passwords expired.
When we try to login with an ubuntu IdM client with one of those accounts, it fails and asks again for password.
The behaviour we are expecting is that Ubuntu should ask for a password change.
Thanks, best regards.
Lic. Mateo Duffour
Unidad Informática
2901.40.91
[ http://maps.apple.com/?q=18%20de%20julio%20985%20-%20Piso%204,Montevideo,... | 18 de julio 985 - Piso 3, Montevideo, Uruguay ]
[ http://www.fnr.gub.uy/ | ]
No me imprimas si no es necesario. Protejamos el medio ambiente. Este mensaje y la información adjunta al mismo está dirigido exclusivamente a su destinatario. Puede contener información confidencial, privilegiada o de uso restringido, protegida por las normas. Si Ud. recibió este e-mail por error, por favor, sírvase notificarle a quien se lo envió y borrar el original. Cualquier otro uso del e-mail por Ud. está prohibido.
1 year, 9 months
Potential API change for FreeIPA plugin writers
by Alexander Bokovoy
Hi,
as you have probably noticed in a thread we had with Leo on
freeipa-users@ about FreeIPA plugin development, we hadn't had
consistency in handling boolean types between LDAP and IPA Python API
level. A change is coming that would make 'native' boolean types used in
both worlds. If your plugins rely on Bool() parameter handling in
FreeIPA, your code might be affected. If your scripts using output of
IPA API rely on case-sensitive output, you might need to adjust your
code.
If not, you can skip this email.
Pull request https://github.com/freeipa/freeipa/pull/6294 turns handling
of boolean types to be native to each side:
- in LDAP, TRUE and FALSE strings used to represent the values
- in Python, native True and False constants of bool type will be used
to represent an LDAP boolean.
Prior to PR#6294, when an LDAP attribute with a boolean syntax was read
from LDAP, its representation in IPA Python code was either 'TRUE'
or 'FALSE' string. This created a bit of inconvenience:
- Python code had to explicitly compare a value to 'TRUE' or 'FALSE',
- Web UI JavaScript code had to use a radio-box where a simple checkbox
would be enough
- JavaScript plugin code would need to handle all types of 'TRUE',
'FALSE', 1, 0, true, false, none in every place where a boolean type
would be enough
After PR#6294 is merged, IPA Python code will use Python bool type.
JSON-RPC response to an IPA API command request would produce a simple
'true' or 'false' instead of ["TRUE"] or ["FALSE"] elements. This means,
for example, that in the following command
ipa dnszone-show ipa.test
instead of
"idnsallowdynupdate": [
"TRUE"
],
one would get
"idnsallowdynupdate": [
true
],
and the output of 'ipa dnszone-show ipa.test' would have 'True' instead
of 'TRUE' (and False instead of 'FALSE'):
$ ipa dnszone-show ipa.test
Zone name: ipa.test.
Active zone: True
Authoritative nameserver: idm.ipa.test.
Administrator e-mail address: hostmaster.ipa.test.
SOA serial: 1654159048
SOA refresh: 3600
SOA retry: 900
SOA expire: 1209600
SOA minimum: 3600
BIND update policy: grant IPA.TEST krb5-self * A; grant IPA.TEST krb5-self * AAAA; grant IPA.TEST krb5-self * SSHFP;
Dynamic update: True
Allow query: any;
Allow transfer: none;
If your scripts rely on the case-sensitive output, you'd need to fix
them. IPA tools already able to handle the changes so they are
backward-compatible.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
1 year, 9 months