The installation of IPA server and replica does not produce desired result. Even though the mkhomedir is set to true the feature is not enabled in the authselect. Also the replica server does not replicate SUDO and HBAC rules from the IPA master. Is the only solution to re-install the whole IPA server/replicas stuff? Kinda stupid.
Example of the IPA server role: - role: freeipa.ansible_freeipa.ipaserver vars: ipaserver: "{{ ansible_hostname }}.example" ipaserver_hostname: "{{ ansible_hostname }}.example" ipaadmin_password: "test123" ipadm_password: "test321" ipaserver_domain: "example.com" ipaserver_realm: "EXAMPLE.COM" ipaserver_no_host_dns: true ipaserver_mem_check: true ipaserver_install_packages: true ipaserver_setup_dns: false ipaserver_no_pkinit: true ipaserver_no_hbac_allow: true ipaserver_no_ui_redirect: false ipaclient_no_ntp: true ipaclient_mkhomedir: true ipaclient_no_sudo: false
Hello,
On 6/22/23 16:08, Finn Fysj via FreeIPA-users wrote:
The installation of IPA server and replica does not produce desired result. Even though the mkhomedir is set to true the feature is not enabled in the authselect. Also the replica server does not replicate SUDO and HBAC rules from the IPA master. Is the only solution to re-install the whole IPA server/replicas stuff? Kinda stupid.
Example of the IPA server role: - role: freeipa.ansible_freeipa.ipaserver vars: ipaserver: "{{ ansible_hostname }}.example" ipaserver_hostname: "{{ ansible_hostname }}.example" ipaadmin_password: "test123" ipadm_password: "test321" ipaserver_domain: "example.com" ipaserver_realm: "EXAMPLE.COM" ipaserver_no_host_dns: true ipaserver_mem_check: true ipaserver_install_packages: true ipaserver_setup_dns: false ipaserver_no_pkinit: true ipaserver_no_hbac_allow: true ipaserver_no_ui_redirect: false ipaclient_no_ntp: true ipaclient_mkhomedir: true ipaclient_no_sudo: false
which IPA and ansible-freeipa versions are you using?
Please provide more information about your inventory and setup.
Are you trying to use the ipaserver role to deploy also replicas? The ipaserver role is only useful to deploy the initial master only. The replicas need to be deployed using the ipareplica role.
Regards, Thomas
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hello,
On 6/22/23 16:08, Finn Fysj via FreeIPA-users wrote:
which IPA and ansible-freeipa versions are you using?
Please provide more information about your inventory and setup.
Are you trying to use the ipaserver role to deploy also replicas? The ipaserver role is only useful to deploy the initial master only. The replicas need to be deployed using the ipareplica role.
Regards, Thomas
Thank you for answer Thomas.
The ansible-freeipa collection version is: 1.11.0 I've experienced a lot of "unconsistency" when installing IPAserver and IPA replica on my EL9 servers.
I do indeed use separated roles for the two server roles ipaserver for the master server and ipareplica role for the replica.
Even tho arguments such as: ipaclient_mkhomedir: true, is set this is one the case for my server.
$ authselect current Profile ID: sssd Enabled featu
Finn Fysj via FreeIPA-users wrote:
Hello,
On 6/22/23 16:08, Finn Fysj via FreeIPA-users wrote:
which IPA and ansible-freeipa versions are you using?
Please provide more information about your inventory and setup.
Are you trying to use the ipaserver role to deploy also replicas? The ipaserver role is only useful to deploy the initial master only. The replicas need to be deployed using the ipareplica role.
Regards, Thomas
Thank you for answer Thomas.
The ansible-freeipa collection version is: 1.11.0 I've experienced a lot of "unconsistency" when installing IPAserver and IPA replica on my EL9 servers.
I do indeed use separated roles for the two server roles ipaserver for the master server and ipareplica role for the replica.
Even tho arguments such as: ipaclient_mkhomedir: true, is set this is one the case for my server.
$ authselect current Profile ID: sssd Enabled featu
Looks like this got cut-off.
It would probably be helpful for Thomas to see your configuration.
rob
On Thu, Sep 14, 2023 at 8:10 AM Finn Fysj via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hello,
On 6/22/23 16:08, Finn Fysj via FreeIPA-users wrote:
which IPA and ansible-freeipa versions are you using?
Please provide more information about your inventory and setup.
Are you trying to use the ipaserver role to deploy also replicas? The
ipaserver
role is only useful to deploy the initial master only. The replicas need
to be
deployed using the ipareplica role.
Regards, Thomas
Thank you for answer Thomas.
The ansible-freeipa collection version is: 1.11.0 I've experienced a lot of "unconsistency" when installing IPAserver and IPA replica on my EL9 servers.
I do indeed use separated roles for the two server roles ipaserver for the master server and ipareplica role for the replica.
Even tho arguments such as: ipaclient_mkhomedir: true, is set this is one the case for my server.
Most of the role variables are not replicated.
In the example you show the vars as set in the role call, not in an inventory file. The same variables (ipaclient_*) should be replicated in the ipareplica role (and on ipaclient) for the settings to be the same on all hosts.
How are you executing the ipareplica code?
Rafael
$ authselect current Profile ID: sssd Enabled featu _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, Sep 14, 2023 at 8:10 AM Finn Fysj via FreeIPA-users < freeipa-users(a)lists.fedorahosted.org> wrote:
Most of the role variables are not replicated.
In the example you show the vars as set in the role call, not in an inventory file. The same variables (ipaclient_*) should be replicated in the ipareplica role (and on ipaclient) for the settings to be the same on all hosts.
How are you executing the ipareplica code?
Rafael
Thank you for taking your time.
It's important to note a "Cloud" dynamic-inventory is being used to reach all of the servers involved.
server.yml - hosts: - server become: true pre_tasks: - name: Replace default UID/GID_MAX ansible.builtin.replace: dest: /etc/login.defs regexp: "^{{ item }}.*" replace: "{{ item }} 6999" loop: - "UID_MAX" - "GID_MAX" - role: freeipa.ansible_freeipa.ipaserver vars: ipaserver: "{{ ansible_hostname }}.example" ipaserver_hostname: "{{ ansible_hostname }}.example" ipaadmin_password: "test123" ipadm_password: "test321" ipaserver_domain: "example.com" ipaserver_realm: "EXAMPLE.COM" ipaserver_no_host_dns: true ipaserver_mem_check: true ipaserver_install_packages: true ipaserver_setup_dns: false ipaserver_no_pkinit: true ipaserver_no_hbac_allow: true ipaserver_no_ui_redirect: false ipaclient_no_ntp: true ipaclient_mkhomedir: true ipaclient_no_sudo: false
replica.yml --- - hosts: - replica become: true roles: - role: freeipa.ansible_freeipa.ipareplica vars: # IPA Replica ipareplica_servers: ["server01.example.com"] ipareplicas: ["{{ ansible_play_hosts_all | join(', ') }}"] ipareplica_domain: "example" ipaadmin_principal: "admin" ipaadmin_password: "test123" ipadm_password: "test321" ipareplica_install_packages: true ipareplica_setup_firewalld: false ipareplica_setup_dns: false ipaclient_no_ntp: true ipaclient_mkhomedir: true ipaclient_no_sudo: false
site.yml --- - import_playbook: server.yml - import_playbook: replica.yml
ansible-playbook --ask-become-pass -i dynamic-inventory site.yml
Authselect output: $ authselect current Profile ID: sssd Enabled features: - with-mkhomedir - with-sudo
Turns out now it works great.
I also then apply SUDO and HBAC rules to my MASTER server using playbooks. The sync of rules takes a lot of time. Could a SSSD restart trigger this?
After this is migrate existing USERS and GROUPS from an old IPA server (RHEL 7) which is going to be destroyed. DS migration: ipa migrate-ds --with-compat --user-container='cn=users,cn=accounts' --group-container='cn=groups,cn=accounts' ldap://old.ipa.example
I've later realized private groups are not being migrated. Any way of "regenerate" these?
Having a closer look at https://www.freeipa.org/page/Howto/Migration A ipa migrate-ds command is provided:
$ echo Secret123 | ipa migrate-ds --bind-dn="cn=Directory Manager" --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts --group-objectclass=posixgroup --user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference,mepManagedEntry} --user-ignore-objectclass=mepOriginEntry --with-compat ldap://migrated.freeipa.server.test
I look at this site as a recommendation of how to use ipa migrate-ds, however following error arises for multiple users: test_user: attribute "mepManagedEntry" not allowed"
I have not been having any issues with "mine" ipa migrate-ds command, but I look at the provided ipa migrate-ds command as "best practice" or at least recommendation.
Finn Fysj via FreeIPA-users wrote:
Having a closer look at https://www.freeipa.org/page/Howto/Migration A ipa migrate-ds command is provided:
$ echo Secret123 | ipa migrate-ds --bind-dn="cn=Directory Manager" --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts --group-objectclass=posixgroup --user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference,mepManagedEntry} --user-ignore-objectclass=mepOriginEntry --with-compat ldap://migrated.freeipa.server.test
I look at this site as a recommendation of how to use ipa migrate-ds, however following error arises for multiple users: test_user: attribute "mepManagedEntry" not allowed"
I have not been having any issues with "mine" ipa migrate-ds command, but I look at the provided ipa migrate-ds command as "best practice" or at least recommendation.
mepOriginEntry is how private groups are implemented.
For more information on migrated private groups see https://rcritten.wordpress.com/2018/09/05/migration-and-user-private-groups/
rob
Finn Fysj via FreeIPA-users wrote:
mepOriginEntry is how private groups are implemented.
For more information on migrated private groups see https://rcritten.wordpress.com/2018/09/05/migration-and-user-private-groups/
rob
Thank you for answering, Rob.
I've preivously looked at the source you reference to. I might need an explaination to: You just need to make sure that FreeIPA Kerberos related attributes are not migrated as they need to be generated again by the new FreeIPA server and it’s new Kerberos settings or keys.
Why? What can be the challenges we face? This hasn't been any problems with the test servers I've configured.
I also need to understand the use of private groups in FreeIPA. We're planning to solely use FreeIPA as LDAP for LDAP connections only. Where the IPA servers is the only servers a KINIT would make sense. Could we face issues NOT migrating private groups when using FreeIPA as an LDAP server (w/gui)?
Finn Fysj via FreeIPA-users wrote:
Finn Fysj via FreeIPA-users wrote:
mepOriginEntry is how private groups are implemented.
For more information on migrated private groups see https://rcritten.wordpress.com/2018/09/05/migration-and-user-private-groups/
rob
Thank you for answering, Rob.
I've preivously looked at the source you reference to. I might need an explaination to: You just need to make sure that FreeIPA Kerberos related attributes are not migrated as they need to be generated again by the new FreeIPA server and it’s new Kerberos settings or keys.
Why? What can be the challenges we face?
If you migrate the Kerberos keys and principals they will be for the original realm and will not work.
LDAP passwords are migrated by allowing password migration in ipa-config. When this mode is enabled, if an LDAP bind occurs and there are no Kerberos keys then they are generated automatically if they don't already exist.
This hasn't been any problems with the test servers I've configured.
Because it sounds like you aren't using Kerberos at all.
I also need to understand the use of private groups in FreeIPA. We're planning to solely use FreeIPA as LDAP for LDAP connections only. Where the IPA servers is the only servers a KINIT would make sense. Could we face issues NOT migrating private groups when using FreeIPA as an LDAP server (w/gui)?
RHEL and Fedora have used private user groups for decades now. The definition being that when a user is created they get a group with the same id and no members.
An IPA user-private group is similar in nature in that it has the same uid/gid. It also lacks the objectclasses to allow members.
A migrated group will retain the same GID but is a regular group.
This is most noticeable when you have a lot of users, so therefore a lot of private groups. Private groups are filtered out by default when looking at the list of groups. That will not happen after migration.
I'm really not sure what your use-case is here. Do you have an existing broken IPA server? I have the impression you are starting out new.
rob
After running suggested command: https://www.freeipa.org/page/Howto/Migration Only the "private groups" are being migrated. Users are not, because of the --user-ignore-attribute={mepManagedEntry}
test_user: attribute "mepManagedEntry" not allowed".
Finn Fysj via FreeIPA-users wrote:
After running suggested command: https://www.freeipa.org/page/Howto/Migration Only the "private groups" are being migrated. Users are not, because of the --user-ignore-attribute={mepManagedEntry}
test_user: attribute "mepManagedEntry" not allowed".
It's not possible to say without seeing the whole command you used.
rob
Finn Fysj via FreeIPA-users wrote:
If you migrate the Kerberos keys and principals they will be for the original realm and will not work.
LDAP passwords are migrated by allowing password migration in ipa-config. When this mode is enabled, if an LDAP bind occurs and there are no Kerberos keys then they are generated automatically if they don't already exist.
Because it sounds like you aren't using Kerberos at all.
RHEL and Fedora have used private user groups for decades now. The definition being that when a user is created they get a group with the same id and no members.
An IPA user-private group is similar in nature in that it has the same uid/gid. It also lacks the objectclasses to allow members.
A migrated group will retain the same GID but is a regular group.
This is most noticeable when you have a lot of users, so therefore a lot of private groups. Private groups are filtered out by default when looking at the list of groups. That will not happen after migration.
I'm really not sure what your use-case is here. Do you have an existing broken IPA server? I have the impression you are starting out new.
rob
FIrstly thank you for taking your time, Rob.
We have an existing IPA server running on RHEL7 and our goal is to create two new IPA server on RHEL9 (master & replica). We therefore want to migrate USERS & GROUPS only from the existing IPA server using ipa migrate-ds. The end goal look something like: Only to use the IPA servers as LDAP server and load balance the these two. It basically gives us LDAP servers w/ GUI. Replacing FreeIPA is not an option.
I'm therefore curious what the risks may be if we're leaving out migrating UPGs, and secondly your thoughts on this approach.
Finn Fysj via FreeIPA-users wrote:
It's not possible to say without seeing the whole command you used.
rob
Works without problems. Does not migrate UPGs nor ignore kerberos data: ipa migrate-ds --with-compat --user-container='cn=users,cn=accounts' --group-container='cn=groups,cn=accounts' ldap://ipa.example.com
Migrates UPGs and other groups, but no users because of "mepOriginEntry": ipa migrate-ds --bind-dn="cn=Directory Manager" --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts \ --group-objectclass=posixgroup \ --user-ignore-objectclass=mepOriginEntry \ --user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference,mepManagedEntry} \ --with-compat \ ldaps://ipa.example.com
Could we experience any inconsistency by not ignoring kerberos data?
On Срд, 27 вер 2023, Finn Fysj via FreeIPA-users wrote:
Finn Fysj via FreeIPA-users wrote:
If you migrate the Kerberos keys and principals they will be for the original realm and will not work.
LDAP passwords are migrated by allowing password migration in ipa-config. When this mode is enabled, if an LDAP bind occurs and there are no Kerberos keys then they are generated automatically if they don't already exist.
Because it sounds like you aren't using Kerberos at all.
RHEL and Fedora have used private user groups for decades now. The definition being that when a user is created they get a group with the same id and no members.
An IPA user-private group is similar in nature in that it has the same uid/gid. It also lacks the objectclasses to allow members.
A migrated group will retain the same GID but is a regular group.
This is most noticeable when you have a lot of users, so therefore a lot of private groups. Private groups are filtered out by default when looking at the list of groups. That will not happen after migration.
I'm really not sure what your use-case is here. Do you have an existing broken IPA server? I have the impression you are starting out new.
rob
FIrstly thank you for taking your time, Rob.
We have an existing IPA server running on RHEL7 and our goal is to create two new IPA server on RHEL9 (master & replica). We therefore want to migrate USERS & GROUPS only from the existing IPA server using ipa migrate-ds. The end goal look something like: Only to use the IPA servers as LDAP server and load balance the these two. It basically gives us LDAP servers w/ GUI. Replacing FreeIPA is not an option.
I'm therefore curious what the risks may be if we're leaving out migrating UPGs, and secondly your thoughts on this approach.
I would question rather why you want migration of IPA deployment instead of just adding those two RHEL 9 servers into existing deployment and then retiring the old (RHEL 7) server.
Sure, this is not possible directly, only through a temporary RHEL 8 replica first, but that would keep all your data intact.
Please see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm... and https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
On Срд, 27 вер 2023, Finn Fysj via FreeIPA-users wrote:
I would question rather why you want migration of IPA deployment instead of just adding those two RHEL 9 servers into existing deployment and then retiring the old (RHEL 7) server.
Sure, this is not possible directly, only through a temporary RHEL 8 replica first, but that would keep all your data intact.
Please see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/... and https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/...
The short answer is: We consider the old IPA to be unstable and we don't want the new server to be based on some existing mess or misconfiguration.
Finn Fysj via FreeIPA-users wrote:
Finn Fysj via FreeIPA-users wrote:
If you migrate the Kerberos keys and principals they will be for the original realm and will not work.
LDAP passwords are migrated by allowing password migration in ipa-config. When this mode is enabled, if an LDAP bind occurs and there are no Kerberos keys then they are generated automatically if they don't already exist.
Because it sounds like you aren't using Kerberos at all.
RHEL and Fedora have used private user groups for decades now. The definition being that when a user is created they get a group with the same id and no members.
An IPA user-private group is similar in nature in that it has the same uid/gid. It also lacks the objectclasses to allow members.
A migrated group will retain the same GID but is a regular group.
This is most noticeable when you have a lot of users, so therefore a lot of private groups. Private groups are filtered out by default when looking at the list of groups. That will not happen after migration.
I'm really not sure what your use-case is here. Do you have an existing broken IPA server? I have the impression you are starting out new.
rob
FIrstly thank you for taking your time, Rob.
We have an existing IPA server running on RHEL7 and our goal is to create two new IPA server on RHEL9 (master & replica). We therefore want to migrate USERS & GROUPS only from the existing IPA server using ipa migrate-ds. The end goal look something like: Only to use the IPA servers as LDAP server and load balance the these two. It basically gives us LDAP servers w/ GUI. Replacing FreeIPA is not an option.
I'm therefore curious what the risks may be if we're leaving out migrating UPGs, and secondly your thoughts on this approach.
UPGs cannot be migrated at all. There is no risk. Some find it annoying to see a bunch of single-user groups in the interface, that's all.
rob
Finn Fysj via FreeIPA-users wrote:
UPGs cannot be migrated at all. There is no risk. Some find it annoying to see a bunch of single-user groups in the interface, that's all.
rob
Thank you, Rob.
I've seen that the UPGs that get migrated have received following attributes:
ipaNTSecurityIdentifier ipantgroupattrs groupofnames nestedgroup ipausergroup
If I really want to keep UPGs I can use ipa group-mod --delattr=...
I'll do some more checking, but you're correct: I don't think we'll have the need for Kerberos unless on the IPA servers themselves, but if it's considered good practice too ignore krb attributes I'll do.
I'll try to do some more testing.
Works without problems. Does not migrate UPGs nor ignore kerberos data: ipa migrate-ds --with-compat --user-container='cn=users,cn=accounts' --group-container='cn=groups,cn=accounts' ldap://ipa.example.com
Migrates UPGs and other groups, but no users because of "mepOriginEntry": ipa migrate-ds --bind-dn="cn=Directory Manager" --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts \ --group-objectclass=posixgroup \ --user-ignore-objectclass=mepOriginEntry \
--user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference,mepManagedEntry} \ --with-compat \ ldaps://ipa.example.com
Could we experience any inconsistency by not ignoring kerberos data?
I'm experiencing inconsistency using ipa-migrate. If a user is e.g deleted, and then I try to re-run the ipa-migrate command: The user will be successfully migrated, however, the user will no longer be part of any user groups.
Command:
ipa migrate-ds --bind-dn="cn=Directory Manager" --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts --group-objectclass=posixgroup --group-objectclass=ipausergroup --user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference} --with-compat ldaps://ipa.example.com
Finn Fysj via FreeIPA-users wrote:
Works without problems. Does not migrate UPGs nor ignore kerberos data: ipa migrate-ds --with-compat --user-container='cn=users,cn=accounts' --group-container='cn=groups,cn=accounts' ldap://ipa.example.com
Migrates UPGs and other groups, but no users because of "mepOriginEntry": ipa migrate-ds --bind-dn="cn=Directory Manager" --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts \ --group-objectclass=posixgroup \ --user-ignore-objectclass=mepOriginEntry \
--user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference,mepManagedEntry} \ --with-compat \ ldaps://ipa.example.com
Could we experience any inconsistency by not ignoring kerberos data?
I'm experiencing inconsistency using ipa-migrate. If a user is e.g deleted, and then I try to re-run the ipa-migrate command: The user will be successfully migrated, however, the user will no longer be part of any user groups.
Command:
ipa migrate-ds --bind-dn="cn=Directory Manager" --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts --group-objectclass=posixgroup --group-objectclass=ipausergroup --user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference} --with-compat ldaps://ipa.example.com
What's the use-case for this?
I think this is likely because migration currently doesn't support user-private groups and a default IPA user doesn't have a memberof their private groups.
migrate-ds was designed to migrate users who used only LDAP to use IPA. IPA to IPA migration is possible for users and groups but its full of pitfalls. This may be another one.
rob
Finn Fysj via FreeIPA-users wrote:
What's the use-case for this?
I think this is likely because migration currently doesn't support user-private groups and a default IPA user doesn't have a memberof their private groups.
migrate-ds was designed to migrate users who used only LDAP to use IPA. IPA to IPA migration is possible for users and groups but its full of pitfalls. This may be another one.
rob
Understood.
When I try to delete the User Groups itself and try a new migration, the user will be member of these groups again...
I'm experiencing a lot of inconsistency with my server + replica setup: - I'm not able to ssh into my IPA servers, even tho I have created an allow_all HBAC. I don't find anything relevant in the logs after settings debug_level = 9, other than: [ipa_pam_access_handler_done] (0x0020): [RID#16] Unable to fetch HBAC rules [22]: Invalid argument. - In the log file I get the service: sshd, but shouldn't the log file also include testing of HBAC rules? Now it suddenly doens't do this.
- Whenever I create a HBAC rule on my server, it takes a long time for it to be synced to the replica, however, if something is created on the replica server this is synced immediately.
Finn Fysj via FreeIPA-users wrote:
Finn Fysj via FreeIPA-users wrote:
What's the use-case for this?
I think this is likely because migration currently doesn't support user-private groups and a default IPA user doesn't have a memberof their private groups.
migrate-ds was designed to migrate users who used only LDAP to use IPA. IPA to IPA migration is possible for users and groups but its full of pitfalls. This may be another one.
rob
Understood.
When I try to delete the User Groups itself and try a new migration, the user will be member of these groups again...
I'm experiencing a lot of inconsistency with my server + replica setup:
- I'm not able to ssh into my IPA servers, even tho I have created an allow_all HBAC. I don't find anything relevant in the logs after settings debug_level = 9, other than: [ipa_pam_access_handler_done] (0x0020): [RID#16] Unable to fetch HBAC rules [22]: Invalid argument.
- In the log file I get the service: sshd, but shouldn't the log file also include testing of HBAC rules? Now it suddenly doens't do this.
If SSSD doesn't have the rules it can't grant access.
- Whenever I create a HBAC rule on my server, it takes a long time for it to be synced to the replica, however, if something is created on the replica server this is synced immediately.
You might try enabling replication debugging on your misbehaving server. It could tell you what is wrong.
rob
Finn Fysj via FreeIPA-users wrote:
If SSSD doesn't have the rules it can't grant access.
You might try enabling replication debugging on your misbehaving server. It could tell you what is wrong.
rob
I tried to setup a another test IPA server just to verify. Here I created a dummy user "test_alice" I added a public key to this user, added a hbac rule: Rule name: allow_alice Host category: all Service category: all Enabled: True Users: test_alice accessruletype: allow
systemctl status sssd Oct 25 15:18:10 ipa-test.example.com sssd_be[34484]: dereference processing failed : Invalid argument
systemctl status sshd Oct 25 15:18:10 ipa-test.example.com sshd[34496]: pam_sss(sshd:account): Access denied for user test_alice: 4 (System error) Oct 25 15:18:10 ipa-test.example.com sshd[34496]: fatal: Access denied for user test_alice by PAM account configuration [preauth]
/var/log/sssd/sssd_example.com.log (2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#4] commit ldb transaction (nesting: 0) (2023-10-25 15:18:10): [be[example.com]] [sysdb_set_entry_attr] (0x0200): [RID#4] Entry [name=test_alice@example.com,cn=users,cn=example.com,cn=sysdb] has set [ts_cache] attrs. (2023-10-25 15:18:10): [be[example.com]] [dp_get_account_info_initgroups_resolv_done] (0x0400): [RID#4] Ordering NSS responder to update memory cache (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: sh[0x5632f31d8560], connected[1], ops[(nil)], ldap[0x5632f31da1c0] (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [sbus_method_handler] (0x2000): Received D-Bus method org.freedesktop.DBus.GetConnectionUnixUser on /org/freedesktop/DBus (2023-10-25 15:18:10): [be[example.com]] [sbus_issue_request_done] (0x0400): org.freedesktop.DBus.GetConnectionUnixUser: Success (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [dp_req_reply_std] (0x1000): [RID#4] DP Request [Initgroups #4]: Returning [Success]: 0,0,Success (2023-10-25 15:18:10): [be[example.com]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.getAccountInfo: Success (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [sbus_method_handler] (0x2000): Received D-Bus method sssd.dataprovider.pamHandler on /sssd (2023-10-25 15:18:10): [be[example.com]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.pam] (2023-10-25 15:18:10): [be[example.com]] [dp_pam_handler_send] (0x0100): Got request with the following data (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): domain: example.com (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): user: test_alice@example.com (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): service: sshd (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): tty: ssh (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): ruser: (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): rhost: 192.168.10.66 (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): authtok type: 0 (No authentication token available) (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available) (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): priv: 1 (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): cli_pid: 34496 (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): child_pid: 0 (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): logon name: not set (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): flags: 0 (2023-10-25 15:18:10): [be[example.com]] [dp_attach_req] (0x0400): [RID#5] DP Request [PAM Account #5]: REQ_TRACE: New request. [sssd.pam CID #1] Flags [0000]. (2023-10-25 15:18:10): [be[example.com]] [dp_attach_req] (0x0400): [RID#5] Number of active DP request: 1 (2023-10-25 15:18:10): [be[example.com]] [sss_domain_get_state] (0x1000): [RID#5] Domain example.com is Active (2023-10-25 15:18:10): [be[example.com]] [sdap_access_send] (0x0400): [RID#5] Performing access check for user [test_alice@example.com] (2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Added timed event "ldb_kv_callback": 0x5632f31b7100
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Added timed event "ldb_kv_timeout": 0x5632f3202bf0
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Running timer event 0x5632f31b7100 "ldb_kv_callback"
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Destroying timer event 0x5632f3202bf0 "ldb_kv_timeout"
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Destroying timer event 0x5632f31b7100 "ldb_kv_callback"
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Added timed event "ldb_kv_callback": 0x5632f32579f0
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Added timed event "ldb_kv_timeout": 0x5632f3202bf0
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Running timer event 0x5632f32579f0 "ldb_kv_callback"
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Destroying timer event 0x5632f3202bf0 "ldb_kv_timeout"
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Destroying timer event 0x5632f32579f0 "ldb_kv_callback"
(2023-10-25 15:18:10): [be[example.com]] [sdap_account_expired_rhds] (0x0400): [RID#5] Performing RHDS access check for user [test_alice@example.com] (2023-10-25 15:18:10): [be[example.com]] [sdap_account_expired_rhds] (0x4000): [RID#5] Account for user [test_alice@example.com] is not locked. (2023-10-25 15:18:10): [be[example.com]] [sdap_account_expired] (0x0400): [RID#5] IPA access control succeeded, checking AD access control (2023-10-25 15:18:10): [be[example.com]] [sdap_account_expired_ad] (0x0400): [RID#5] Performing AD access check for user [test_alice@example.com] (2023-10-25 15:18:10): [be[example.com]] [sdap_account_expired_ad] (0x4000): [RID#5] User account control for user [test_alice@example.com] is [0]. (2023-10-25 15:18:10): [be[example.com]] [sdap_account_expired_ad] (0x4000): [RID#5] Expiration time for user [test_alice@example.com] is [0]. (2023-10-25 15:18:10): [be[example.com]] [ipa_fetch_hbac_send] (0x4000): [RID#5] Connection status is [online]. (2023-10-25 15:18:10): [be[example.com]] [sdap_id_op_connect_step] (0x4000): [RID#5] reusing cached connection (2023-10-25 15:18:10): [be[example.com]] [sdap_id_conn_data_not_idle] (0x4000): [RID#5] Marking connection as not idle (2023-10-25 15:18:10): [be[example.com]] [sdap_print_server] (0x2000): [RID#5] Searching 10.141.4.21:389 (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x0400): [RID#5] calling ldap_search_ext with [(&(objectClass=ipaHost)(fqdn=ipa-test.example.com))][cn=accounts,dc=example,dc=com]. (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [objectClass] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [cn] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [fqdn] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [serverHostname] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [memberOf] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [ipaSshPubKey] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [ipaUniqueID] (2023-10-25 15:18:10): [be[example.com]] [sdap_op_add] (0x2000): [RID#5] New operation 18 timeout 60 (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: sh[0x5632f31d8560], connected[1], ops[0x5632f312ec50], ldap[0x5632f31da1c0] (2023-10-25 15:18:10): [be[example.com]] [sdap_process_message] (0x4000): [RID#5] Message type: [LDAP_RES_SEARCH_ENTRY] (2023-10-25 15:18:10): [be[example.com]] [sdap_call_op_callback] (0x20000): [RID#5] Handling LDAP operation [18][server: [10.141.4.21:389] filter: [(&(objectClass=ipaHost)(fqdn=ipa-test.example.com))] base: [cn=accounts,dc=example,dc=com]] took [0.412] milliseconds. (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_entry] (0x1000): [RID#5] OriginalDN: [fqdn=ipa-test.example.com,cn=computers,cn=accounts,dc=example,dc=com]. (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [objectClass] (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [cn] (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [fqdn] (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [serverHostname] (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [memberOf] (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [ipaSshPubKey] (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [ipaUniqueID] (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: sh[0x5632f31d8560], connected[1], ops[0x5632f312ec50], ldap[0x5632f31da1c0] (2023-10-25 15:18:10): [be[example.com]] [sdap_process_message] (0x4000): [RID#5] Message type: [LDAP_RES_SEARCH_RESULT] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_op_finished] (0x0400): [RID#5] Search result: Success(0), no errmsg set (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_op_finished] (0x2000): [RID#5] Total count [0] (2023-10-25 15:18:10): [be[example.com]] [sdap_op_destructor] (0x2000): [RID#5] Operation 18 finished (2023-10-25 15:18:10): [be[example.com]] [sdap_has_deref_support_ex] (0x0400): [RID#5] The server supports deref method OpenLDAP (2023-10-25 15:18:10): [be[example.com]] [sdap_deref_search_send] (0x2000): [RID#5] Server supports OpenLDAP deref (2023-10-25 15:18:10): [be[example.com]] [sdap_x_deref_search_send] (0x0400): [RID#5] Dereferencing entry [fqdn=ipa-test.example.com,cn=computers,cn=accounts,dc=example,dc=com] using OpenLDAP deref (2023-10-25 15:18:10): [be[example.com]] [sdap_print_server] (0x2000): [RID#5] Searching 10.141.4.21:389 (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_send] (0x0400): [RID#5] WARNING: Disabling paging because scope is set to base. (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x0400): [RID#5] calling ldap_search_ext with [no filter][fqdn=ipa-test.example.com,cn=computers,cn=accounts,dc=example,dc=com]. (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [objectClass] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [cn] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [memberOf] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [ipaUniqueID] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x2000): [RID#5] ldap_search_ext called, msgid = 19 (2023-10-25 15:18:10): [be[example.com]] [sdap_op_add] (0x2000): [RID#5] New operation 19 timeout 60 (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: sh[0x5632f31d8560], connected[1], ops[0x5632f312ec50], ldap[0x5632f31da1c0] (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: sh[0x5632f31d8560], connected[1], ops[0x5632f312ec50], ldap[0x5632f31da1c0] (2023-10-25 15:18:10): [be[example.com]] [sdap_process_message] (0x4000): [RID#5] Message type: [LDAP_RES_SEARCH_ENTRY] (2023-10-25 15:18:10): [be[example.com]] [sdap_call_op_callback] (0x20000): [RID#5] Handling LDAP operation [19][server: [10.141.4.21:389] filter: [(null)] base: [fqdn=ipa-test.example.com,cn=computers,cn=accounts,dc=example,dc=com]] took [1.636] milliseconds. (2023-10-25 15:18:10): [be[example.com]] [sdap_x_deref_parse_entry] (0x0400): [RID#5] Got deref control (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x1000): [RID#5] Dereferenced DN: cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced objectClass value: top (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced objectClass value: groupOfNames (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced objectClass value: nestedGroup (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced objectClass value: ipaobject (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced objectClass value: ipahostgroup (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Found map for objectclass 'ipahostgroup' (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x2000): [RID#5] Dereferenced attribute: objectClass (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x2000): [RID#5] Dereferenced attribute: cn (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: ipaservers (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x2000): [RID#5] Dereferenced attribute: memberOf (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Replication Administrators,cn=privileges,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Read Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Modify DNA Range,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Read PassSync Managers Configuration,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Read Replication Changelog Configuration,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Write Replication Changelog Configuration,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Modify PassSync Managers Configuration,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Read LDBM Database Configuration,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Read DNA Range,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x2000): [RID#5] Dereferenced attribute: ipaUniqueID (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: d2694b3c-7347-11ee-bd25-000017024d7a (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x1000): [RID#5] Dereferenced DN: cn=Replication Administrators,cn=privileges,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x0020): [RID#5] Unknown entry type, no objectClasses found! (2023-10-25 15:18:10): [be[example.com]] [sdap_x_deref_parse_entry] (0x0040): [RID#5] sdap_parse_deref failed [22]: Invalid argument
Is it considered a practice to always restart sssd when a HBAC rule is added and to empty the cache?
Whenever I've been working with FreeIPA and sssd I've able to see something like: No HBAC rules find, denying access
This is not the case here.
Finn Fysj via FreeIPA-users wrote:
Finn Fysj via FreeIPA-users wrote:
If SSSD doesn't have the rules it can't grant access.
You might try enabling replication debugging on your misbehaving server. It could tell you what is wrong.
rob
I tried to setup a another test IPA server just to verify. Here I created a dummy user "test_alice" I added a public key to this user, added a hbac rule: Rule name: allow_alice Host category: all Service category: all Enabled: True Users: test_alice accessruletype: allow
systemctl status sssd Oct 25 15:18:10 ipa-test.example.com sssd_be[34484]: dereference processing failed : Invalid argument
systemctl status sshd Oct 25 15:18:10 ipa-test.example.com sshd[34496]: pam_sss(sshd:account): Access denied for user test_alice: 4 (System error) Oct 25 15:18:10 ipa-test.example.com sshd[34496]: fatal: Access denied for user test_alice by PAM account configuration [preauth]
/var/log/sssd/sssd_example.com.log (2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#4] commit ldb transaction (nesting: 0) (2023-10-25 15:18:10): [be[example.com]] [sysdb_set_entry_attr] (0x0200): [RID#4] Entry [name=test_alice@example.com,cn=users,cn=example.com,cn=sysdb] has set [ts_cache] attrs. (2023-10-25 15:18:10): [be[example.com]] [dp_get_account_info_initgroups_resolv_done] (0x0400): [RID#4] Ordering NSS responder to update memory cache (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: sh[0x5632f31d8560], connected[1], ops[(nil)], ldap[0x5632f31da1c0] (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [sbus_method_handler] (0x2000): Received D-Bus method org.freedesktop.DBus.GetConnectionUnixUser on /org/freedesktop/DBus (2023-10-25 15:18:10): [be[example.com]] [sbus_issue_request_done] (0x0400): org.freedesktop.DBus.GetConnectionUnixUser: Success (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [dp_req_reply_std] (0x1000): [RID#4] DP Request [Initgroups #4]: Returning [Success]: 0,0,Success (2023-10-25 15:18:10): [be[example.com]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.getAccountInfo: Success (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [sbus_dispatch] (0x4000): Dispatching. (2023-10-25 15:18:10): [be[example.com]] [sbus_method_handler] (0x2000): Received D-Bus method sssd.dataprovider.pamHandler on /sssd (2023-10-25 15:18:10): [be[example.com]] [sbus_senders_lookup] (0x2000): Looking for identity of sender [sssd.pam] (2023-10-25 15:18:10): [be[example.com]] [dp_pam_handler_send] (0x0100): Got request with the following data (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): domain: example.com (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): user: test_alice@example.com (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): service: sshd (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): tty: ssh (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): ruser: (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): rhost: 192.168.10.66 (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): authtok type: 0 (No authentication token available) (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available) (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): priv: 1 (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): cli_pid: 34496 (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): child_pid: 0 (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): logon name: not set (2023-10-25 15:18:10): [be[example.com]] [pam_print_data] (0x0100): flags: 0 (2023-10-25 15:18:10): [be[example.com]] [dp_attach_req] (0x0400): [RID#5] DP Request [PAM Account #5]: REQ_TRACE: New request. [sssd.pam CID #1] Flags [0000]. (2023-10-25 15:18:10): [be[example.com]] [dp_attach_req] (0x0400): [RID#5] Number of active DP request: 1 (2023-10-25 15:18:10): [be[example.com]] [sss_domain_get_state] (0x1000): [RID#5] Domain example.com is Active (2023-10-25 15:18:10): [be[example.com]] [sdap_access_send] (0x0400): [RID#5] Performing access check for user [test_alice@example.com] (2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Added timed event "ldb_kv_callback": 0x5632f31b7100
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Added timed event "ldb_kv_timeout": 0x5632f3202bf0
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Running timer event 0x5632f31b7100 "ldb_kv_callback"
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Destroying timer event 0x5632f3202bf0 "ldb_kv_timeout"
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Destroying timer event 0x5632f31b7100 "ldb_kv_callback"
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Added timed event "ldb_kv_callback": 0x5632f32579f0
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Added timed event "ldb_kv_timeout": 0x5632f3202bf0
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Running timer event 0x5632f32579f0 "ldb_kv_callback"
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Destroying timer event 0x5632f3202bf0 "ldb_kv_timeout"
(2023-10-25 15:18:10): [be[example.com]] [ldb] (0x10000): [RID#5] Destroying timer event 0x5632f32579f0 "ldb_kv_callback"
(2023-10-25 15:18:10): [be[example.com]] [sdap_account_expired_rhds] (0x0400): [RID#5] Performing RHDS access check for user [test_alice@example.com] (2023-10-25 15:18:10): [be[example.com]] [sdap_account_expired_rhds] (0x4000): [RID#5] Account for user [test_alice@example.com] is not locked. (2023-10-25 15:18:10): [be[example.com]] [sdap_account_expired] (0x0400): [RID#5] IPA access control succeeded, checking AD access control (2023-10-25 15:18:10): [be[example.com]] [sdap_account_expired_ad] (0x0400): [RID#5] Performing AD access check for user [test_alice@example.com] (2023-10-25 15:18:10): [be[example.com]] [sdap_account_expired_ad] (0x4000): [RID#5] User account control for user [test_alice@example.com] is [0]. (2023-10-25 15:18:10): [be[example.com]] [sdap_account_expired_ad] (0x4000): [RID#5] Expiration time for user [test_alice@example.com] is [0]. (2023-10-25 15:18:10): [be[example.com]] [ipa_fetch_hbac_send] (0x4000): [RID#5] Connection status is [online]. (2023-10-25 15:18:10): [be[example.com]] [sdap_id_op_connect_step] (0x4000): [RID#5] reusing cached connection (2023-10-25 15:18:10): [be[example.com]] [sdap_id_conn_data_not_idle] (0x4000): [RID#5] Marking connection as not idle (2023-10-25 15:18:10): [be[example.com]] [sdap_print_server] (0x2000): [RID#5] Searching 10.141.4.21:389 (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x0400): [RID#5] calling ldap_search_ext with [(&(objectClass=ipaHost)(fqdn=ipa-test.example.com))][cn=accounts,dc=example,dc=com]. (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [objectClass] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [cn] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [fqdn] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [serverHostname] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [memberOf] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [ipaSshPubKey] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [ipaUniqueID] (2023-10-25 15:18:10): [be[example.com]] [sdap_op_add] (0x2000): [RID#5] New operation 18 timeout 60 (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: sh[0x5632f31d8560], connected[1], ops[0x5632f312ec50], ldap[0x5632f31da1c0] (2023-10-25 15:18:10): [be[example.com]] [sdap_process_message] (0x4000): [RID#5] Message type: [LDAP_RES_SEARCH_ENTRY] (2023-10-25 15:18:10): [be[example.com]] [sdap_call_op_callback] (0x20000): [RID#5] Handling LDAP operation [18][server: [10.141.4.21:389] filter: [(&(objectClass=ipaHost)(fqdn=ipa-test.example.com))] base: [cn=accounts,dc=example,dc=com]] took [0.412] milliseconds. (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_entry] (0x1000): [RID#5] OriginalDN: [fqdn=ipa-test.example.com,cn=computers,cn=accounts,dc=example,dc=com]. (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [objectClass] (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [cn] (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [fqdn] (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [serverHostname] (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [memberOf] (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [ipaSshPubKey] (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_range] (0x2000): [RID#5] No sub-attributes for [ipaUniqueID] (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: sh[0x5632f31d8560], connected[1], ops[0x5632f312ec50], ldap[0x5632f31da1c0] (2023-10-25 15:18:10): [be[example.com]] [sdap_process_message] (0x4000): [RID#5] Message type: [LDAP_RES_SEARCH_RESULT] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_op_finished] (0x0400): [RID#5] Search result: Success(0), no errmsg set (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_op_finished] (0x2000): [RID#5] Total count [0] (2023-10-25 15:18:10): [be[example.com]] [sdap_op_destructor] (0x2000): [RID#5] Operation 18 finished (2023-10-25 15:18:10): [be[example.com]] [sdap_has_deref_support_ex] (0x0400): [RID#5] The server supports deref method OpenLDAP (2023-10-25 15:18:10): [be[example.com]] [sdap_deref_search_send] (0x2000): [RID#5] Server supports OpenLDAP deref (2023-10-25 15:18:10): [be[example.com]] [sdap_x_deref_search_send] (0x0400): [RID#5] Dereferencing entry [fqdn=ipa-test.example.com,cn=computers,cn=accounts,dc=example,dc=com] using OpenLDAP deref (2023-10-25 15:18:10): [be[example.com]] [sdap_print_server] (0x2000): [RID#5] Searching 10.141.4.21:389 (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_send] (0x0400): [RID#5] WARNING: Disabling paging because scope is set to base. (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x0400): [RID#5] calling ldap_search_ext with [no filter][fqdn=ipa-test.example.com,cn=computers,cn=accounts,dc=example,dc=com]. (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [objectClass] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [cn] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [memberOf] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x1000): [RID#5] Requesting attrs: [ipaUniqueID] (2023-10-25 15:18:10): [be[example.com]] [sdap_get_generic_ext_step] (0x2000): [RID#5] ldap_search_ext called, msgid = 19 (2023-10-25 15:18:10): [be[example.com]] [sdap_op_add] (0x2000): [RID#5] New operation 19 timeout 60 (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: sh[0x5632f31d8560], connected[1], ops[0x5632f312ec50], ldap[0x5632f31da1c0] (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (2023-10-25 15:18:10): [be[example.com]] [sdap_process_result] (0x2000): Trace: sh[0x5632f31d8560], connected[1], ops[0x5632f312ec50], ldap[0x5632f31da1c0] (2023-10-25 15:18:10): [be[example.com]] [sdap_process_message] (0x4000): [RID#5] Message type: [LDAP_RES_SEARCH_ENTRY] (2023-10-25 15:18:10): [be[example.com]] [sdap_call_op_callback] (0x20000): [RID#5] Handling LDAP operation [19][server: [10.141.4.21:389] filter: [(null)] base: [fqdn=ipa-test.example.com,cn=computers,cn=accounts,dc=example,dc=com]] took [1.636] milliseconds. (2023-10-25 15:18:10): [be[example.com]] [sdap_x_deref_parse_entry] (0x0400): [RID#5] Got deref control (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x1000): [RID#5] Dereferenced DN: cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced objectClass value: top (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced objectClass value: groupOfNames (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced objectClass value: nestedGroup (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced objectClass value: ipaobject (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced objectClass value: ipahostgroup (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Found map for objectclass 'ipahostgroup' (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x2000): [RID#5] Dereferenced attribute: objectClass (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x2000): [RID#5] Dereferenced attribute: cn (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: ipaservers (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x2000): [RID#5] Dereferenced attribute: memberOf (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Replication Administrators,cn=privileges,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Read Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Modify DNA Range,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Read PassSync Managers Configuration,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Read Replication Changelog Configuration,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Write Replication Changelog Configuration,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Modify PassSync Managers Configuration,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Read LDBM Database Configuration,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Add Configuration Sub-Entries,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: cn=Read DNA Range,cn=permissions,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x2000): [RID#5] Dereferenced attribute: ipaUniqueID (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x4000): [RID#5] Dereferenced attribute value: d2694b3c-7347-11ee-bd25-000017024d7a (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x1000): [RID#5] Dereferenced DN: cn=Replication Administrators,cn=privileges,cn=pbac,dc=example,dc=com (2023-10-25 15:18:10): [be[example.com]] [sdap_parse_deref] (0x0020): [RID#5] Unknown entry type, no objectClasses found! (2023-10-25 15:18:10): [be[example.com]] [sdap_x_deref_parse_entry] (0x0040): [RID#5] sdap_parse_deref failed [22]: Invalid argument
Is it considered a practice to always restart sssd when a HBAC rule is added and to empty the cache?
SSSD caches HBAC and sudo rules and checks them on a schedule. It doesn't get notified when they are added, deleted or modified.
rob
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Finn Fysj -
Rafael Jeffman -
Rob Crittenden -
twoerner＠redhat.com