[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-02-15 Thread Stijn De Weirdt via FreeIPA-users

hi all,

thanks to all for this thread. this is not for the faint of heart. i had 
similar issue with upgrade on el88 
(ipa-server-4.9.11-7.module+el8.8.0+19639+24a8b95c.x86_64 -> 
ipa-server-4.9.11-9.module+el8.8.0+20825+52dd1628.x86_64; yes not even a 
subminor version change)


my experience:
0. all rest client access broken after update, incl ipa command
1. find this thread
2. /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid broken 
due to missing dnarange  -> but got ipa working back for admin user, 
this was a lifesaver. kudos to whoever implemented it that it started 
with the admin user. it was the only one who got the ipantsecurityidentifier
3. figure out why we need dnarange (we don't; we add all users with 
predefined uids), and what minimal range we can use (a range of size 1 
is not enough ;)
4. config-mod enable sid gives errors in the ldap errors file (and not 
the sid enable log file) due to users not in an idrange

5. add idrange without baserid, config mod reveals conflict in rids
6 so run ldapmodify to fix it. rerun config-mod to discover another set 
of users not in the idrange

7. add another idrange, this time with baserids
8. run config-mod again, some errors that appear harmless
9. run config-mod again, clean logs


hooray for trusting version numbers to estimate potential impact of an 
update!


stijn

On 2/12/24 12:19, Oliver Nixon via FreeIPA-users wrote:

Complete oversight by me sorry...

There was a GID of a group set to 200. After changing that and running sidgen 
again all the users now have SIDs
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-02-12 Thread Oliver Nixon via FreeIPA-users
Complete oversight by me sorry...

There was a GID of a group set to 200. After changing that and running sidgen 
again all the users now have SIDs
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-02-12 Thread Tomasz Torcz via FreeIPA-users
On Mon, Feb 12, 2024 at 10:53:33AM -, Oliver Nixon via FreeIPA-users wrote:
> Hi Rob,
> 
> Thanks for confirming. 
> 
> The strange thing is there aren't any users outside of the range that I can 
> find and there is definitely nothing with an ID of 200.

 It may be a GID of some group.

-- 
Tomasz Torcz Morality must always be based on practicality.
[email protected] — Baron Vladimir Harkonnen
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-02-12 Thread Marc Pearson | i-Neda Ltd via FreeIPA-users
Just to chime in on this.

I'm not 100% this isn't a bug, as I've also hit the same issue after an update. 
In the end, I've had to re-create the effected accounts with the same UID and 
GID after deletion, which is resolving the issue for me as I wasn't able to 
find a solution using the mail-list archives.

Marc.

-Original Message-
From: Oliver Nixon via FreeIPA-users  
Sent: Monday, February 12, 2024 10:54 AM
To: [email protected]
Cc: Oliver Nixon 
Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web 
UI login and ipa command to stop working

Hi Rob,

Thanks for confirming. 

The strange thing is there aren't any users outside of the range that I can 
find and there is definitely nothing with an ID of 200.
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-02-12 Thread Oliver Nixon via FreeIPA-users
Hi Rob,

Thanks for confirming. 

The strange thing is there aren't any users outside of the range that I can 
find and there is definitely nothing with an ID of 200.
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-02-08 Thread Rob Crittenden via FreeIPA-users
Oliver Nixon via FreeIPA-users wrote:
> Hi Rob,
> 
> Thanks for your reply.
> 
> All I can find in the log is the following:
> [08/Feb/2024:17:31:01.478681171 +] - ERR - sidgen_task_thread - [file 
> ipa_sidgen_task.c, line 194]: Sidgen task starts ...
> [08/Feb/2024:17:31:01.667472180 +] - ERR - find_sid_for_ldap_entry - 
> [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [200] into an 
> unused SID.
> [08/Feb/2024:17:31:01.689096330 +] - ERR - do_work - [file 
> ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry.
> [08/Feb/2024:17:31:01.716244190 +] - ERR - sidgen_task_thread - [file 
> ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
> --

It means you have a user outside an IPA range (and honestly anything <
1000 should be treated as reserved IMHO). There are a LOT of other
threads on this list regarding this type of issue which contains very
helpful advice. I'd suggest you check the archives.

rob
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-02-08 Thread Oliver Nixon via FreeIPA-users
Hi Rob,

Thanks for your reply.

All I can find in the log is the following:
[08/Feb/2024:17:31:01.478681171 +] - ERR - sidgen_task_thread - [file 
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[08/Feb/2024:17:31:01.667472180 +] - ERR - find_sid_for_ldap_entry - [file 
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [200] into an unused 
SID.
[08/Feb/2024:17:31:01.689096330 +] - ERR - do_work - [file 
ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry.
[08/Feb/2024:17:31:01.716244190 +] - ERR - sidgen_task_thread - [file 
ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-02-08 Thread Oliver Nixon via FreeIPA-users
Hi,

I'm encountering the same issue after upgrading to 4.9.12.
I had previously imported users from another FreeIPA deployment and their UIDs 
were outside of the defined ID ranges.
I've created a new ID range to encompass these and run the following but the 
SIDs still don't get generated:
]# /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid   
--netbios-name DOMAIN-NAME   --add-sids
Configuring SID generation
  [1/8]: creating samba domain object
Samba domain object already exists
  [2/8]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
  [3/8]: adding RID bases
RID bases already set, nothing to do
  [4/8]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [5/8]: activating sidgen task
Sidgen task plugin already configured, nothing to do
  [6/8]: restarting Directory Server to take MS PAC and LDAP plugins changes 
into account
  [7/8]: adding fallback group
Fallback group already set, nothing to do
  [8/8]: adding SIDs to existing users and groups
This step may take considerable amount of time, please wait..
Done.
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-02-08 Thread Rob Crittenden via FreeIPA-users
Oliver Nixon via FreeIPA-users wrote:
> Hi,
> 
> I'm encountering the same issue after upgrading to 4.9.12.
> I had previously imported users from another FreeIPA deployment and their 
> UIDs were outside of the defined ID ranges.
> I've created a new ID range to encompass these and run the following but the 
> SIDs still don't get generated:
> ]# /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid   
> --netbios-name DOMAIN-NAME   --add-sids
> Configuring SID generation
>   [1/8]: creating samba domain object
> Samba domain object already exists
>   [2/8]: adding admin(group) SIDs
> Admin SID already set, nothing to do
> Admin group SID already set, nothing to do
>   [3/8]: adding RID bases
> RID bases already set, nothing to do
>   [4/8]: updating Kerberos config
> 'dns_lookup_kdc' already set to 'true', nothing to do.
>   [5/8]: activating sidgen task
> Sidgen task plugin already configured, nothing to do
>   [6/8]: restarting Directory Server to take MS PAC and LDAP plugins changes 
> into account
>   [7/8]: adding fallback group
> Fallback group already set, nothing to do
>   [8/8]: adding SIDs to existing users and groups
> This step may take considerable amount of time, please wait..
> Done.

You need to look in /var/log/dirsrv/slapd-REALM/errors for the reason
for failure.

rob
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-02-08 Thread Oliver Nixon via FreeIPA-users
Hi,

I'm encountering the same issue after upgrading to 4.9.12.
I had previously imported users from another FreeIPA deployment and their UIDs 
were outside of the defined ID ranges.
I've created a new ID range to encompass these and run the following but the 
SIDs still don't get generated:
]# /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid   
--netbios-name DOMAIN-NAME   --add-sids
Configuring SID generation
  [1/8]: creating samba domain object
Samba domain object already exists
  [2/8]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
  [3/8]: adding RID bases
RID bases already set, nothing to do
  [4/8]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [5/8]: activating sidgen task
Sidgen task plugin already configured, nothing to do
  [6/8]: restarting Directory Server to take MS PAC and LDAP plugins changes 
into account
  [7/8]: adding fallback group
Fallback group already set, nothing to do
  [8/8]: adding SIDs to existing users and groups
This step may take considerable amount of time, please wait..
Done.
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-01-23 Thread Alexander Bokovoy via FreeIPA-users

On Аўт, 23 сту 2024, Dungan, Scott A. via FreeIPA-users wrote:

I found the answer in this thread:

https://lists.fedorahosted.org/archives/list/[email protected]/thread/5BUG3EVCRQKNF6BC74LA2CL3H2I2EV3P/

Following that, we used ldapmodify to apply the correct values for the
rid-base and secondary-rid-base in the new range. Afterwards, running

ipa config-mod --enable-sid --add-sids

completed, and all users have been assigned sids, although the logs
show a few errors about sids already being used:

Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.671583872 -0800] - ERR - rid_to_sid_with_check - [file 
ipa_sidgen_common.c, line 384]: SID 
[S-1-5-21-437482216-426791213-2761072236-101000116] is already used.
Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.672837572 -0800] - ERR - rid_to_sid_with_check - [file 
ipa_sidgen_common.c, line 384]: SID 
[S-1-5-21-437482216-426791213-2761072236-101000115] is already used.
Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.683585571 -0800] - ERR - rid_to_sid_with_check - [file 
ipa_sidgen_common.c, line 384]: SID 
[S-1-5-21-437482216-426791213-2761072236-101029028] is already used.
Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.703869107 -0800] - ERR - rid_to_sid_with_check - [file 
ipa_sidgen_common.c, line 384]: SID 
[S-1-5-21-437482216-426791213-2761072236-101029021] is already used.
Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.743343711 -0800] - ERR - sidgen_task_thread - [file 
ipa_sidgen_task.c, line 199]: Sidgen task finished [0]

Not sure if we should be concerned about that or not.


Since it doesn't say 'Secondary SID is used as well.', this means a
first choice for that SID was not successful and sidgen plugin switched
to a RID from the secondary RID base. It should be fine in the end -- a
user/group got a unique SID assigned.




-Scott

From: Dungan, Scott A. via FreeIPA-users 
Sent: Tuesday, January 23, 2024 8:05 AM
To: Florence Blanc-Renaud ; FreeIPA users list 

Cc: Dungan, Scott A. 
Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web 
UI login and ipa command to stop working

Thanks, Flo.

I believe we now know what the correct values should be for the rid-base and 
secondary-rid-base, however, we can’t seem to modify the ID range with the 
missing values we created to cover the legacy NIS users:

$ ipa idrange-mod ID.EXAMPLE.COM_legacy_range
ipa: ERROR: This command can not be used to change ID allocation for local IPA 
domain. Run `ipa help idrange` for more information

Nor can we simply delete the range and try again:

ipa idrange-del ID.EXAMPLE.COM_legacy_range
ipa: ERROR: invalid 'ipabaseid,ipaidrangesize': range modification leaving 
objects with ID out of the defined range is not allowed

It seems that we are in a chicken or the egg bind here. Below is the output of 
iprange-find for reference.


3 ranges matched

 Range name: ID.EXAMPLE.COM _id_range
 First Posix ID of the range: 86680
 Number of IDs in the range: 20
 First RID of the corresponding RID range: 1000
 First RID of the secondary RID range: 1
 Range type: local domain range

 Range name: ID.EXAMPLE.COM _legacy_range
 First Posix ID of the range: 1000
 Number of IDs in the range: 98899
 Range type: local domain range

 Range name: ID.EXAMPLE.COM _subid_range
 First Posix ID of the range: 2147483648
 Number of IDs in the range: 2147352576
 First RID of the corresponding RID range: 2147283648
 Domain SID of the trusted domain: S-1-5-21-538032-778436-45698521293
 Range type: Active Directory domain range

Number of entries returned 3


From: Florence Blanc-Renaud mailto:[email protected]>>
Sent: Monday, January 22, 2024 11:50 PM
To: FreeIPA users list 
mailto:[email protected]>>
Cc: Dungan, Scott A. mailto:[email protected]>>
Subject: Re: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused 
web UI login and ipa command to stop working

Hi,

On Tue, Jan 23, 2024 at 1:05 AM Dungan, Scott A. via FreeIPA-users 
mailto:[email protected]>>
 wrote:
Thanks to Paul for all the leg work on this issue. Based on that, I can confirm 
that we have the same problem after updating to 4.9.12-11 from 4.9.11-7. 
Running the oddjob command to add SIDs to the user accounts fails after 
encountering UIDs outside of the default IPA range. It was able to get the 
admin account working though. We have 294 users with UIDs in the range of 1001 
to 99657. These were migrated from an ancient NIS domain when the IPA domain 
was provisioned. We tried adding a secondary IPA range that covers that scope:

ipa idrange-add ID.EXAMPLE.COM_legacy_range --base-id=1000 --range-size=98899

And then running the oddjob command again, but we get the sidgen 

[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-01-23 Thread Dungan, Scott A. via FreeIPA-users
I found the answer in this thread:

https://lists.fedorahosted.org/archives/list/[email protected]/thread/5BUG3EVCRQKNF6BC74LA2CL3H2I2EV3P/

Following that, we used ldapmodify to apply the correct values for the rid-base 
and secondary-rid-base in the new range. Afterwards, running

ipa config-mod --enable-sid --add-sids

completed, and all users have been assigned sids, although the logs show a few 
errors about sids already being used:

Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.671583872 -0800] - ERR - rid_to_sid_with_check - [file 
ipa_sidgen_common.c, line 384]: SID 
[S-1-5-21-437482216-426791213-2761072236-101000116] is already used.
Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.672837572 -0800] - ERR - rid_to_sid_with_check - [file 
ipa_sidgen_common.c, line 384]: SID 
[S-1-5-21-437482216-426791213-2761072236-101000115] is already used.
Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.683585571 -0800] - ERR - rid_to_sid_with_check - [file 
ipa_sidgen_common.c, line 384]: SID 
[S-1-5-21-437482216-426791213-2761072236-101029028] is already used.
Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.703869107 -0800] - ERR - rid_to_sid_with_check - [file 
ipa_sidgen_common.c, line 384]: SID 
[S-1-5-21-437482216-426791213-2761072236-101029021] is already used.
Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.743343711 -0800] - ERR - sidgen_task_thread - [file 
ipa_sidgen_task.c, line 199]: Sidgen task finished [0]

Not sure if we should be concerned about that or not.

-Scott

From: Dungan, Scott A. via FreeIPA-users 
Sent: Tuesday, January 23, 2024 8:05 AM
To: Florence Blanc-Renaud ; FreeIPA users list 

Cc: Dungan, Scott A. 
Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web 
UI login and ipa command to stop working

Thanks, Flo.

I believe we now know what the correct values should be for the rid-base and 
secondary-rid-base, however, we can’t seem to modify the ID range with the 
missing values we created to cover the legacy NIS users:

$ ipa idrange-mod ID.EXAMPLE.COM_legacy_range
ipa: ERROR: This command can not be used to change ID allocation for local IPA 
domain. Run `ipa help idrange` for more information

Nor can we simply delete the range and try again:

ipa idrange-del ID.EXAMPLE.COM_legacy_range
ipa: ERROR: invalid 'ipabaseid,ipaidrangesize': range modification leaving 
objects with ID out of the defined range is not allowed

It seems that we are in a chicken or the egg bind here. Below is the output of 
iprange-find for reference.


3 ranges matched

  Range name: ID.EXAMPLE.COM _id_range
  First Posix ID of the range: 86680
  Number of IDs in the range: 20
  First RID of the corresponding RID range: 1000
  First RID of the secondary RID range: 1
  Range type: local domain range

  Range name: ID.EXAMPLE.COM _legacy_range
  First Posix ID of the range: 1000
  Number of IDs in the range: 98899
  Range type: local domain range

  Range name: ID.EXAMPLE.COM _subid_range
  First Posix ID of the range: 2147483648
  Number of IDs in the range: 2147352576
  First RID of the corresponding RID range: 2147283648
  Domain SID of the trusted domain: S-1-5-21-538032-778436-45698521293
  Range type: Active Directory domain range

Number of entries returned 3


From: Florence Blanc-Renaud mailto:[email protected]>>
Sent: Monday, January 22, 2024 11:50 PM
To: FreeIPA users list 
mailto:[email protected]>>
Cc: Dungan, Scott A. mailto:[email protected]>>
Subject: Re: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused 
web UI login and ipa command to stop working

Hi,

On Tue, Jan 23, 2024 at 1:05 AM Dungan, Scott A. via FreeIPA-users 
mailto:[email protected]>>
 wrote:
Thanks to Paul for all the leg work on this issue. Based on that, I can confirm 
that we have the same problem after updating to 4.9.12-11 from 4.9.11-7. 
Running the oddjob command to add SIDs to the user accounts fails after 
encountering UIDs outside of the default IPA range. It was able to get the 
admin account working though. We have 294 users with UIDs in the range of 1001 
to 99657. These were migrated from an ancient NIS domain when the IPA domain 
was provisioned. We tried adding a secondary IPA range that covers that scope:

ipa idrange-add ID.EXAMPLE.COM_legacy_range --base-id=1000 --range-size=98899

And then running the oddjob command again, but we get the sidgen errors still, 
plus a error about overlapping rid ranges:

[22/Jan/2024:15:09:50.398460268 -0800] - ERR - sidgen_task_thread - [file 
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[22/Jan/2024:15:09:50.499604871 -0800] - ERR - find_sid_for_ldap_entry - [file 
ipa_sidgen_common.c, line 522]: Cannot convert Po

[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-01-23 Thread Dungan, Scott A. via FreeIPA-users
Thanks, Flo.

I believe we now know what the correct values should be for the rid-base and 
secondary-rid-base, however, we can’t seem to modify the ID range with the 
missing values we created to cover the legacy NIS users:

$ ipa idrange-mod ID.EXAMPLE.COM_legacy_range
ipa: ERROR: This command can not be used to change ID allocation for local IPA 
domain. Run `ipa help idrange` for more information

Nor can we simply delete the range and try again:

ipa idrange-del ID.EXAMPLE.COM_legacy_range
ipa: ERROR: invalid 'ipabaseid,ipaidrangesize': range modification leaving 
objects with ID out of the defined range is not allowed

It seems that we are in a chicken or the egg bind here. Below is the output of 
iprange-find for reference.


3 ranges matched

  Range name: ID.EXAMPLE.COM _id_range
  First Posix ID of the range: 86680
  Number of IDs in the range: 20
  First RID of the corresponding RID range: 1000
  First RID of the secondary RID range: 1
  Range type: local domain range

  Range name: ID.EXAMPLE.COM _legacy_range
  First Posix ID of the range: 1000
  Number of IDs in the range: 98899
  Range type: local domain range

  Range name: ID.EXAMPLE.COM _subid_range
  First Posix ID of the range: 2147483648
  Number of IDs in the range: 2147352576
  First RID of the corresponding RID range: 2147283648
  Domain SID of the trusted domain: S-1-5-21-538032-778436-45698521293
  Range type: Active Directory domain range

Number of entries returned 3


From: Florence Blanc-Renaud 
Sent: Monday, January 22, 2024 11:50 PM
To: FreeIPA users list 
Cc: Dungan, Scott A. 
Subject: Re: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused 
web UI login and ipa command to stop working

Hi,

On Tue, Jan 23, 2024 at 1:05 AM Dungan, Scott A. via FreeIPA-users 
mailto:[email protected]>>
 wrote:
Thanks to Paul for all the leg work on this issue. Based on that, I can confirm 
that we have the same problem after updating to 4.9.12-11 from 4.9.11-7. 
Running the oddjob command to add SIDs to the user accounts fails after 
encountering UIDs outside of the default IPA range. It was able to get the 
admin account working though. We have 294 users with UIDs in the range of 1001 
to 99657. These were migrated from an ancient NIS domain when the IPA domain 
was provisioned. We tried adding a secondary IPA range that covers that scope:

ipa idrange-add ID.EXAMPLE.COM_legacy_range --base-id=1000 --range-size=98899

And then running the oddjob command again, but we get the sidgen errors still, 
plus a error about overlapping rid ranges:

[22/Jan/2024:15:09:50.398460268 -0800] - ERR - sidgen_task_thread - [file 
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[22/Jan/2024:15:09:50.499604871 -0800] - ERR - find_sid_for_ldap_entry - [file 
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [29034] into an unused 
SID.
[22/Jan/2024:15:09:50.499960197 -0800] - ERR - do_work - [file 
ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry.
[22/Jan/2024:15:09:50.503257753 -0800] - ERR - sidgen_task_thread - [file 
ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
[22/Jan/2024:15:09:55.035779436 -0800] - ERR - schema-compat-plugin - warning: 
no entries set up under cn=computers, cn=compat,dc=id,dc=example,dc=com
[22/Jan/2024:15:09:55.036238563 -0800] - ERR - schema-compat-plugin - Finished 
plugin initialization.
[22/Jan/2024:15:47:04.969286883 -0800] - ERR - ipa_range_check_pre_op - [file 
ipa_range_check.c, line 670]: New primary rid range overlaps with existing 
primary rid range.

I suspect that we may not have added the range correctly. We didn't pass the 
--rid-base= or --secondary-rid-base= flags/values as we were not sure what 
these values should be.

These values are important in order to generate the SIDs. Please read The role 
of security and relative identifiers in IdM ID 
ranges<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_idm_users_groups_hosts_and_access_control_rules/index#con_the-role-of-security-and-relative-identifiers-in-idm-id-ranges_adjusting-id-ranges-manually>
 and Security 
Identifiers<https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html#security-identifiers>
 to understand how they are used. You need to pick values that do not conflict 
with the ones for your initial range.

flo

Any help would be much appreciated.

Scott

-Original Message-
From: Rob Crittenden via FreeIPA-users 
mailto:[email protected]>>
Sent: Thursday, January 18, 2024 11:25 AM
To: FreeIPA users list 
mailto:[email protected]>>
Cc: Paul Nickerson mailto:[email protected]>>; Rob Crittenden 
mailto:[email protected]>>
Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web 
UI login and ipa command to 

[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-01-22 Thread Florence Blanc-Renaud via FreeIPA-users
Hi,

On Tue, Jan 23, 2024 at 1:05 AM Dungan, Scott A. via FreeIPA-users <
[email protected]> wrote:

> Thanks to Paul for all the leg work on this issue. Based on that, I can
> confirm that we have the same problem after updating to 4.9.12-11 from
> 4.9.11-7. Running the oddjob command to add SIDs to the user accounts fails
> after encountering UIDs outside of the default IPA range. It was able to
> get the admin account working though. We have 294 users with UIDs in the
> range of 1001 to 99657. These were migrated from an ancient NIS domain when
> the IPA domain was provisioned. We tried adding a secondary IPA range that
> covers that scope:
>
> ipa idrange-add ID.EXAMPLE.COM_legacy_range --base-id=1000
> --range-size=98899
>
> And then running the oddjob command again, but we get the sidgen errors
> still, plus a error about overlapping rid ranges:
>
> [22/Jan/2024:15:09:50.398460268 -0800] - ERR - sidgen_task_thread - [file
> ipa_sidgen_task.c, line 194]: Sidgen task starts ...
> [22/Jan/2024:15:09:50.499604871 -0800] - ERR - find_sid_for_ldap_entry -
> [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [29034] into
> an unused SID.
> [22/Jan/2024:15:09:50.499960197 -0800] - ERR - do_work - [file
> ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry.
> [22/Jan/2024:15:09:50.503257753 -0800] - ERR - sidgen_task_thread - [file
> ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
> [22/Jan/2024:15:09:55.035779436 -0800] - ERR - schema-compat-plugin -
> warning: no entries set up under cn=computers,
> cn=compat,dc=id,dc=example,dc=com
> [22/Jan/2024:15:09:55.036238563 -0800] - ERR - schema-compat-plugin -
> Finished plugin initialization.
> [22/Jan/2024:15:47:04.969286883 -0800] - ERR - ipa_range_check_pre_op -
> [file ipa_range_check.c, line 670]: New primary rid range overlaps with
> existing primary rid range.
>
> I suspect that we may not have added the range correctly. We didn't pass
> the --rid-base= or --secondary-rid-base= flags/values as we were not sure
> what these values should be.
>

These values are important in order to generate the SIDs. Please read The
role of security and relative identifiers in IdM ID ranges
<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_idm_users_groups_hosts_and_access_control_rules/index#con_the-role-of-security-and-relative-identifiers-in-idm-id-ranges_adjusting-id-ranges-manually>
and Security Identifiers
<https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html#security-identifiers>
to
understand how they are used. You need to pick values that do not conflict
with the ones for your initial range.

flo

>
> Any help would be much appreciated.
>
> Scott
>
> -Original Message-
> From: Rob Crittenden via FreeIPA-users <
> [email protected]>
> Sent: Thursday, January 18, 2024 11:25 AM
> To: FreeIPA users list 
> Cc: Paul Nickerson ; Rob Crittenden  >
> Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused
> web UI login and ipa command to stop working
>
> Paul Nickerson via FreeIPA-users wrote:
> > I confirmed that users who had an ipaNTSecurityIdentifier attribute
> could log in to the web UI, and those that did not have the
> ipaNTSecurityIdentifier attribute could not.
> >
> > I found the error in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors like
> you said:
> > [17/Jan/2024:20:28:09.571195828 +] - ERR - sidgen_task_thread -
> [file ipa_sidgen_task.c, line 194]: Sidgen task starts ...
> > [17/Jan/2024:20:28:09.637675948 +] - ERR - find_sid_for_ldap_entry -
> [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [156623]
> into an unused SID.
> > [17/Jan/2024:20:28:09.658369523 +] - ERR - do_work - [file
> ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry.
> > [17/Jan/2024:20:28:09.666726494 +] - ERR - sidgen_task_thread -
> [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
> >
> > I found some nice documentation at
> > https://access.redhat.com/solutions/394763
> >
> > I used this command to see the ranges that I have configured:
> > ipa idrange-find
> >
> > And these two commands to see the UIDs of the users who had not yet been
> given SIDs (some were inside the existing range; I think you're correct
> that the process stops at the first error):
> > ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory
> > Manager" -W -b "cn=users,cn=accounts,dc=semi,dc=example,dc=net"
> > "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v
> > "# requesting: " | sed 's/

[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-01-22 Thread Dungan, Scott A. via FreeIPA-users
Thanks to Paul for all the leg work on this issue. Based on that, I can confirm 
that we have the same problem after updating to 4.9.12-11 from 4.9.11-7. 
Running the oddjob command to add SIDs to the user accounts fails after 
encountering UIDs outside of the default IPA range. It was able to get the 
admin account working though. We have 294 users with UIDs in the range of 1001 
to 99657. These were migrated from an ancient NIS domain when the IPA domain 
was provisioned. We tried adding a secondary IPA range that covers that scope:

ipa idrange-add ID.EXAMPLE.COM_legacy_range --base-id=1000 --range-size=98899 

And then running the oddjob command again, but we get the sidgen errors still, 
plus a error about overlapping rid ranges:

[22/Jan/2024:15:09:50.398460268 -0800] - ERR - sidgen_task_thread - [file 
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[22/Jan/2024:15:09:50.499604871 -0800] - ERR - find_sid_for_ldap_entry - [file 
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [29034] into an unused 
SID.
[22/Jan/2024:15:09:50.499960197 -0800] - ERR - do_work - [file 
ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry.
[22/Jan/2024:15:09:50.503257753 -0800] - ERR - sidgen_task_thread - [file 
ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
[22/Jan/2024:15:09:55.035779436 -0800] - ERR - schema-compat-plugin - warning: 
no entries set up under cn=computers, cn=compat,dc=id,dc=example,dc=com
[22/Jan/2024:15:09:55.036238563 -0800] - ERR - schema-compat-plugin - Finished 
plugin initialization.
[22/Jan/2024:15:47:04.969286883 -0800] - ERR - ipa_range_check_pre_op - [file 
ipa_range_check.c, line 670]: New primary rid range overlaps with existing 
primary rid range.

I suspect that we may not have added the range correctly. We didn't pass the 
--rid-base= or --secondary-rid-base= flags/values as we were not sure what 
these values should be. 

Any help would be much appreciated. 

Scott

-Original Message-
From: Rob Crittenden via FreeIPA-users  
Sent: Thursday, January 18, 2024 11:25 AM
To: FreeIPA users list 
Cc: Paul Nickerson ; Rob Crittenden 
Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web 
UI login and ipa command to stop working

Paul Nickerson via FreeIPA-users wrote:
> I confirmed that users who had an ipaNTSecurityIdentifier attribute could log 
> in to the web UI, and those that did not have the ipaNTSecurityIdentifier 
> attribute could not.
> 
> I found the error in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors like you 
> said:
> [17/Jan/2024:20:28:09.571195828 +] - ERR - sidgen_task_thread - [file 
> ipa_sidgen_task.c, line 194]: Sidgen task starts ...
> [17/Jan/2024:20:28:09.637675948 +] - ERR - find_sid_for_ldap_entry - 
> [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [156623] 
> into an unused SID.
> [17/Jan/2024:20:28:09.658369523 +] - ERR - do_work - [file 
> ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry.
> [17/Jan/2024:20:28:09.666726494 +] - ERR - sidgen_task_thread - [file 
> ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
> 
> I found some nice documentation at 
> https://access.redhat.com/solutions/394763
> 
> I used this command to see the ranges that I have configured:
> ipa idrange-find
> 
> And these two commands to see the UIDs of the users who had not yet been 
> given SIDs (some were inside the existing range; I think you're correct that 
> the process stops at the first error): 
> ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory 
> Manager" -W -b "cn=users,cn=accounts,dc=semi,dc=example,dc=net" 
> "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v 
> "# requesting: " | sed 's/uidNumber: //' | sort -n ldapsearch -H 
> ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b 
> "cn=deleted 
> users,cn=accounts,cn=provisioning,dc=semi,dc=example,dc=net" 
> "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v 
> "# requesting: " | sed 's/uidNumber: //' | sort -n
> 
> Here's some documentation on what ID and RID ranges are for: 
> https://www.freeipa.org/page/V3/ID_Ranges
> 
> After doing a bunch of math and guess and check, I ran this:
> ipa idrange-add SEMI.EXAMPLE.NET_US150777_range --base-id=144140 
> --range-size=531251000 --rid-base=10100 
> --secondary-rid-base=63300
> 
> That gave me an additional range (confirmed with ipa idrange-find). I ran ipa 
> config-mod --enable-sid --add-sids again, saw no significant errors in 
> /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors, and confirmed that there were 
> 0 users left with no ipaNTSecurityIdentifier.
> 
> All users are all set now. Thank you again.

Glad t

[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-01-18 Thread Rob Crittenden via FreeIPA-users
Paul Nickerson via FreeIPA-users wrote:
> I confirmed that users who had an ipaNTSecurityIdentifier attribute could log 
> in to the web UI, and those that did not have the ipaNTSecurityIdentifier 
> attribute could not.
> 
> I found the error in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors like you 
> said:
> [17/Jan/2024:20:28:09.571195828 +] - ERR - sidgen_task_thread - [file 
> ipa_sidgen_task.c, line 194]: Sidgen task starts ...
> [17/Jan/2024:20:28:09.637675948 +] - ERR - find_sid_for_ldap_entry - 
> [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [156623] 
> into an unused SID.
> [17/Jan/2024:20:28:09.658369523 +] - ERR - do_work - [file 
> ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry.
> [17/Jan/2024:20:28:09.666726494 +] - ERR - sidgen_task_thread - [file 
> ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
> 
> I found some nice documentation at https://access.redhat.com/solutions/394763
> 
> I used this command to see the ranges that I have configured:
> ipa idrange-find
> 
> And these two commands to see the UIDs of the users who had not yet been 
> given SIDs (some were inside the existing range; I think you're correct that 
> the process stops at the first error): 
> ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
> -W -b "cn=users,cn=accounts,dc=semi,dc=example,dc=net" 
> "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v "# 
> requesting: " | sed 's/uidNumber: //' | sort -n
> ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
> -W -b "cn=deleted 
> users,cn=accounts,cn=provisioning,dc=semi,dc=example,dc=net" 
> "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v "# 
> requesting: " | sed 's/uidNumber: //' | sort -n
> 
> Here's some documentation on what ID and RID ranges are for: 
> https://www.freeipa.org/page/V3/ID_Ranges
> 
> After doing a bunch of math and guess and check, I ran this:
> ipa idrange-add SEMI.EXAMPLE.NET_US150777_range --base-id=144140 
> --range-size=531251000 --rid-base=10100 --secondary-rid-base=63300
> 
> That gave me an additional range (confirmed with ipa idrange-find). I ran ipa 
> config-mod --enable-sid --add-sids again, saw no significant errors in 
> /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors, and confirmed that there were 
> 0 users left with no ipaNTSecurityIdentifier.
> 
> All users are all set now. Thank you again.

Glad to hear it and thank you for your detailed analysis. I think this
will be useful to other users that may run into this.

rob
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-01-17 Thread Paul Nickerson via FreeIPA-users
I confirmed that users who had an ipaNTSecurityIdentifier attribute could log 
in to the web UI, and those that did not have the ipaNTSecurityIdentifier 
attribute could not.

I found the error in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors like you 
said:
[17/Jan/2024:20:28:09.571195828 +] - ERR - sidgen_task_thread - [file 
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[17/Jan/2024:20:28:09.637675948 +] - ERR - find_sid_for_ldap_entry - [file 
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [156623] into an 
unused SID.
[17/Jan/2024:20:28:09.658369523 +] - ERR - do_work - [file 
ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry.
[17/Jan/2024:20:28:09.666726494 +] - ERR - sidgen_task_thread - [file 
ipa_sidgen_task.c, line 199]: Sidgen task finished [32].

I found some nice documentation at https://access.redhat.com/solutions/394763

I used this command to see the ranges that I have configured:
ipa idrange-find

And these two commands to see the UIDs of the users who had not yet been given 
SIDs (some were inside the existing range; I think you're correct that the 
process stops at the first error): 
ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
-W -b "cn=users,cn=accounts,dc=semi,dc=example,dc=net" 
"(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v "# 
requesting: " | sed 's/uidNumber: //' | sort -n
ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
-W -b "cn=deleted users,cn=accounts,cn=provisioning,dc=semi,dc=example,dc=net" 
"(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v "# 
requesting: " | sed 's/uidNumber: //' | sort -n

Here's some documentation on what ID and RID ranges are for: 
https://www.freeipa.org/page/V3/ID_Ranges

After doing a bunch of math and guess and check, I ran this:
ipa idrange-add SEMI.EXAMPLE.NET_US150777_range --base-id=144140 
--range-size=531251000 --rid-base=10100 --secondary-rid-base=63300

That gave me an additional range (confirmed with ipa idrange-find). I ran ipa 
config-mod --enable-sid --add-sids again, saw no significant errors in 
/var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors, and confirmed that there were 0 
users left with no ipaNTSecurityIdentifier.

All users are all set now. Thank you again.
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-01-17 Thread Rob Crittenden via FreeIPA-users
Paul Nickerson via FreeIPA-users wrote:
> Thank you for the assistance. I tried running the oddjob without specifying a 
> NetBIOS name, and it gave a return code of 1, no output, and didn't seem to 
> do anything. Then I saw your NetBIOS comment.
> 
> First I checked to see if we already had a NetBIOS name configured, and I 
> didn't find anything (I used ldapsearch because the ipa command was still not 
> working):
> ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
> -W '(ipaNTFlatName=*)'
> ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
> -W '(objectClass=ipaNTTrustedDomain)'
> ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
> -W '(objectclass=ipaNTDomainAttrs)'
> 
> So I tried the oddjob with the NetBIOS name option, formatted as you 
> recommended:
> /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid --netbios-name 
> SEMI --add-sids
> 
> This still had no output, but it did do good things. I can now find the 
> NetBIOS name using ldapsearch. Many users and groups now have the 
> ipaNTSecurityIdentifier attribute:
> ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
> -W '(ipaNTSecurityIdentifier=*)'
> 
> However, some users were skipped, like mine. The admin user got the 
> ipaNTSecurityIdentifier attribute, so I tried running the ipa command as that 
> user, hoping to modify the skipped users:
> 
> [[email protected] ~]
>  # kinit admin
> Password for [email protected]:
> [[email protected] ~]
>  # ipa config-mod --enable-sid --add-sids
>   Maximum username length: 32
>   Maximum hostname length: 64
>   Home directory base: /home
>   Default shell: /bin/bash
>   Default users group: ipausers
>   Default e-mail domain: semi.example.net
>   Search time limit: 2
>   Search size limit: 500
>   User search fields: uid,givenname,sn,telephonenumber,ou,title
>   Group search fields: cn,description
>   Enable migration mode: False
>   Certificate Subject base: O=SEMI.EXAMPLE.NET
>   Password Expiration Notification (days): 4
>   Password plugin features: AllowNThash, KDC:Disable Last Success
>   SELinux user map order: 
> guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
>   Default SELinux user: unconfined_u:s0-s0:c0.c1023
>   Default PAC types: MS-PAC, nfs:NONE
>   IPA masters: ipa01.semi.example.net, ipa02.semi.example.net
>   IPA master capable of PKINIT: ipa01.semi.example.net, ipa02.semi.example.net
>   IPA CA servers: ipa01.semi.example.net, ipa02.semi.example.net
>   IPA CA renewal master: ipa02.semi.example.net
> 
> The skipped users still have no ipaNTSecurityIdentifier. But at least I can 
> run ipa commands now.
> 
> I've tried looking for patterns in which users were skipped. It's not all 
> users in the admins group. Maybe it's older users, who I think were migrated 
> from a previous FreeIPA version 3 cluster which crashed and burned years ago? 
> I'm going to keep looking for some pattern in which users did not get the 
> ipaNTSecurityIdentifier, but if you have any ideas, please let me know.

The users have to be inside an IPA range in order to have a SID
assigned. If you look in /var/log/dirsrv/slapd-REALM/errors you should
find an error message about where it failed. IIRC it stops on the first
failure.

rob
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-01-17 Thread Paul Nickerson via FreeIPA-users
Thank you for the assistance. I tried running the oddjob without specifying a 
NetBIOS name, and it gave a return code of 1, no output, and didn't seem to do 
anything. Then I saw your NetBIOS comment.

First I checked to see if we already had a NetBIOS name configured, and I 
didn't find anything (I used ldapsearch because the ipa command was still not 
working):
ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
-W '(ipaNTFlatName=*)'
ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
-W '(objectClass=ipaNTTrustedDomain)'
ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
-W '(objectclass=ipaNTDomainAttrs)'

So I tried the oddjob with the NetBIOS name option, formatted as you 
recommended:
/usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid --netbios-name 
SEMI --add-sids

This still had no output, but it did do good things. I can now find the NetBIOS 
name using ldapsearch. Many users and groups now have the 
ipaNTSecurityIdentifier attribute:
ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
-W '(ipaNTSecurityIdentifier=*)'

However, some users were skipped, like mine. The admin user got the 
ipaNTSecurityIdentifier attribute, so I tried running the ipa command as that 
user, hoping to modify the skipped users:

[[email protected] ~]
 # kinit admin
Password for [email protected]:
[[email protected] ~]
 # ipa config-mod --enable-sid --add-sids
  Maximum username length: 32
  Maximum hostname length: 64
  Home directory base: /home
  Default shell: /bin/bash
  Default users group: ipausers
  Default e-mail domain: semi.example.net
  Search time limit: 2
  Search size limit: 500
  User search fields: uid,givenname,sn,telephonenumber,ou,title
  Group search fields: cn,description
  Enable migration mode: False
  Certificate Subject base: O=SEMI.EXAMPLE.NET
  Password Expiration Notification (days): 4
  Password plugin features: AllowNThash, KDC:Disable Last Success
  SELinux user map order: 
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
  Default SELinux user: unconfined_u:s0-s0:c0.c1023
  Default PAC types: MS-PAC, nfs:NONE
  IPA masters: ipa01.semi.example.net, ipa02.semi.example.net
  IPA master capable of PKINIT: ipa01.semi.example.net, ipa02.semi.example.net
  IPA CA servers: ipa01.semi.example.net, ipa02.semi.example.net
  IPA CA renewal master: ipa02.semi.example.net

The skipped users still have no ipaNTSecurityIdentifier. But at least I can run 
ipa commands now.

I've tried looking for patterns in which users were skipped. It's not all users 
in the admins group. Maybe it's older users, who I think were migrated from a 
previous FreeIPA version 3 cluster which crashed and burned years ago? I'm 
going to keep looking for some pattern in which users did not get the 
ipaNTSecurityIdentifier, but if you have any ideas, please let me know.
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-01-17 Thread Alexander Bokovoy via FreeIPA-users

On Срд, 17 сту 2024, Alexander Bokovoy via FreeIPA-users wrote:

On Срд, 17 сту 2024, Paul Nickerson via FreeIPA-users wrote:

I have two FreeIPA servers in a cluster, both running on RHEL 8.9. They
started on RHEL 8.0 I believe, and have been upgrading in-place since
then. I recently restarted the FreeIPA services, which triggered an
ipa-server-upgrade to upgrade from 4.9.11 to 4.9.12. When that ran, it
errored out on some expired certificates, which I fixed with
ipa-cert-fix, and then the ipa-server-upgrade's finished successfully.

Now, when I or any of my users try to log on to the web UI, we get the error "Your 
session has expired. Please log in again."
Also, when I try to run any ipa command on the command line, I get the error:
ipa: ERROR: cannot connect to 'any of the configured servers': 
https://ipa01.semi.example.net/ipa/session/json, 
https://ipa02.semi.example.net/ipa/session/json

I've traced down lots of errors, and I think this one is the most relevant:
401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (Credential 
cache is empty)
I see it in /var/log/httpd/error_log, in the body of the HTTP response from 
https://ipa01.semi.example.net/ipa/session/json in my web browser, and in the 
output from the command ipa --debug

Also, in /var/log/krb5kdc.log, I see:
Jan 17 01:14:47 ipa01.semi.example.net krb5kdc[55855](info): TGS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.16.121.5: 
S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1705454084, etypes 
{rep=UNSUPPORTED:(0)} HTTP/[email protected] for 
ldap/[email protected], KDC policy rejects request

I have krb5 1.18.2 installed. disable_pac is not present in
/var/kerberos/krb5kdc/kdc.conf.

I think I'm experiencing the same issue seen in the recent thread at
https://lists.fedorahosted.org/archives/list/[email protected]/thread/DLYLL54LBTT4FVJLIFFWVAPQOEU4GWW7/
(subject line "api authorization stopped working after upgrade to
4.9.12-11 on RHEL8").

I don't think any of my users or groups have an SID
(ipantsecurityidentifier). This FreeIPA cluster was installed on RHEL
8.0 (or thereabouts), and the servers have been upgraded in-place since
then. We've never integrated with any Active Directory or Microsoft
product.


FreeIPA generates SIDs by default since FreeIPA 4.9.8. It is configured
to do so on new installations even when integration with AD is not
considered, due to tightened requirements to process constrained
delegation in Kerberos.



This command has no output, showing that even the admin user does not have an 
SID:
ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
-W -b cn=users,cn=accounts,dc=semi,dc=example,dc=net uid=admin '*' + | grep -i 
ipantsecurityidentifier

The solution from the other thread, and from
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts#proc_enabling-security-identifiers-sids-in-idm_assembly_strengthening-kerberos-security-with-pac-information,
does not work for me, since the ipa command doesn't work, not even for
the admin user:

[[email protected] ~]
# kinit admin
Password for [email protected]:
[[email protected] ~]
# ipa config-mod --enable-sid --add-sids
ipa: ERROR: cannot connect to 'any of the configured servers': 
https://ipa01.semi.example.net/ipa/json, https://ipa02.semi.example.net/ipa/json

I found an alternative method at 
https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#troubleshooting-and-debugging,
 but this also does not work for me:

[[email protected] ~]
# ldapmodify -H ldapi://%2Frun%2Fslapd-SEMI-EXAMPLE-NET.socket -f 
/tmp/ipa-sidgen-task-run.ldif
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL SSF: 256
SASL data security layer installed.
adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
ldap_add: No such object (32)

I think ipa-sidgen-task does not exist in my LDAP directory, but I'm
not sure if I understand how this is supposed to work. I don't see
ipa-sidgen-task or anything like it from this search: ldapsearch -H
ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b
cn=config | grep cn=tasks

Can anyone help me here? I think if I could get a
ipantsecurityidentifier attribute properly set up on my user or on the
admin user, then I would be able to use the ipa command to get SID's
enabled and created everywhere.


You'd need to enable SID generation first, then run those tasks. Without
sidgen plugins enabled, one cannot initiate SID generation.

Please follow the comm

[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-01-16 Thread Alexander Bokovoy via FreeIPA-users

On Срд, 17 сту 2024, Paul Nickerson via FreeIPA-users wrote:

I have two FreeIPA servers in a cluster, both running on RHEL 8.9. They
started on RHEL 8.0 I believe, and have been upgrading in-place since
then. I recently restarted the FreeIPA services, which triggered an
ipa-server-upgrade to upgrade from 4.9.11 to 4.9.12. When that ran, it
errored out on some expired certificates, which I fixed with
ipa-cert-fix, and then the ipa-server-upgrade's finished successfully.

Now, when I or any of my users try to log on to the web UI, we get the error "Your 
session has expired. Please log in again."
Also, when I try to run any ipa command on the command line, I get the error:
ipa: ERROR: cannot connect to 'any of the configured servers': 
https://ipa01.semi.example.net/ipa/session/json, 
https://ipa02.semi.example.net/ipa/session/json

I've traced down lots of errors, and I think this one is the most relevant:
401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (Credential 
cache is empty)
I see it in /var/log/httpd/error_log, in the body of the HTTP response from 
https://ipa01.semi.example.net/ipa/session/json in my web browser, and in the 
output from the command ipa --debug

Also, in /var/log/krb5kdc.log, I see:
Jan 17 01:14:47 ipa01.semi.example.net krb5kdc[55855](info): TGS_REQ (6 etypes 
{aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.16.121.5: 
S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1705454084, etypes 
{rep=UNSUPPORTED:(0)} HTTP/[email protected] for 
ldap/[email protected], KDC policy rejects request

I have krb5 1.18.2 installed. disable_pac is not present in
/var/kerberos/krb5kdc/kdc.conf.

I think I'm experiencing the same issue seen in the recent thread at
https://lists.fedorahosted.org/archives/list/[email protected]/thread/DLYLL54LBTT4FVJLIFFWVAPQOEU4GWW7/
(subject line "api authorization stopped working after upgrade to
4.9.12-11 on RHEL8").

I don't think any of my users or groups have an SID
(ipantsecurityidentifier). This FreeIPA cluster was installed on RHEL
8.0 (or thereabouts), and the servers have been upgraded in-place since
then. We've never integrated with any Active Directory or Microsoft
product.


FreeIPA generates SIDs by default since FreeIPA 4.9.8. It is configured
to do so on new installations even when integration with AD is not
considered, due to tightened requirements to process constrained
delegation in Kerberos.



This command has no output, showing that even the admin user does not have an 
SID:
ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
-W -b cn=users,cn=accounts,dc=semi,dc=example,dc=net uid=admin '*' + | grep -i 
ipantsecurityidentifier

The solution from the other thread, and from
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts#proc_enabling-security-identifiers-sids-in-idm_assembly_strengthening-kerberos-security-with-pac-information,
does not work for me, since the ipa command doesn't work, not even for
the admin user:

[[email protected] ~]
# kinit admin
Password for [email protected]:
[[email protected] ~]
# ipa config-mod --enable-sid --add-sids
ipa: ERROR: cannot connect to 'any of the configured servers': 
https://ipa01.semi.example.net/ipa/json, https://ipa02.semi.example.net/ipa/json

I found an alternative method at 
https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#troubleshooting-and-debugging,
 but this also does not work for me:

[[email protected] ~]
# ldapmodify -H ldapi://%2Frun%2Fslapd-SEMI-EXAMPLE-NET.socket -f 
/tmp/ipa-sidgen-task-run.ldif
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL SSF: 256
SASL data security layer installed.
adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
ldap_add: No such object (32)

I think ipa-sidgen-task does not exist in my LDAP directory, but I'm
not sure if I understand how this is supposed to work. I don't see
ipa-sidgen-task or anything like it from this search: ldapsearch -H
ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b
cn=config | grep cn=tasks

Can anyone help me here? I think if I could get a
ipantsecurityidentifier attribute properly set up on my user or on the
admin user, then I would be able to use the ipa command to get SID's
enabled and created everywhere.


You'd need to enable SID generation first, then run those tasks. Without
sidgen plugins enabled, one cannot initiate SID generation.

Please follow the command Rob pointed you to. If that one fails, please provide
more de

[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

2024-01-16 Thread Rob Crittenden via FreeIPA-users
Paul Nickerson via FreeIPA-users wrote:
> I have two FreeIPA servers in a cluster, both running on RHEL 8.9. They 
> started on RHEL 8.0 I believe, and have been upgrading in-place since then. I 
> recently restarted the FreeIPA services, which triggered an 
> ipa-server-upgrade to upgrade from 4.9.11 to 4.9.12. When that ran, it 
> errored out on some expired certificates, which I fixed with ipa-cert-fix, 
> and then the ipa-server-upgrade's finished successfully.
> 
> Now, when I or any of my users try to log on to the web UI, we get the error 
> "Your session has expired. Please log in again."
> Also, when I try to run any ipa command on the command line, I get the error:
> ipa: ERROR: cannot connect to 'any of the configured servers': 
> https://ipa01.semi.example.net/ipa/session/json, 
> https://ipa02.semi.example.net/ipa/session/json
> 
> I've traced down lots of errors, and I think this one is the most relevant:
> 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI 
> Error: Unspecified GSS failure.  Minor code may provide more information 
> (Credential cache is empty)
> I see it in /var/log/httpd/error_log, in the body of the HTTP response from 
> https://ipa01.semi.example.net/ipa/session/json in my web browser, and in the 
> output from the command ipa --debug
> 
> Also, in /var/log/krb5kdc.log, I see:
> Jan 17 01:14:47 ipa01.semi.example.net krb5kdc[55855](info): TGS_REQ (6 
> etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
> aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
> camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.16.121.5: 
> S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1705454084, etypes 
> {rep=UNSUPPORTED:(0)} HTTP/[email protected] for 
> ldap/[email protected], KDC policy rejects request
> 
> I have krb5 1.18.2 installed. disable_pac is not present in 
> /var/kerberos/krb5kdc/kdc.conf.
> 
> I think I'm experiencing the same issue seen in the recent thread at 
> https://lists.fedorahosted.org/archives/list/[email protected]/thread/DLYLL54LBTT4FVJLIFFWVAPQOEU4GWW7/
>  (subject line "api authorization stopped working after upgrade to 4.9.12-11 
> on RHEL8").
> 
> I don't think any of my users or groups have an SID 
> (ipantsecurityidentifier). This FreeIPA cluster was installed on RHEL 8.0 (or 
> thereabouts), and the servers have been upgraded in-place since then. We've 
> never integrated with any Active Directory or Microsoft product.
> 
> This command has no output, showing that even the admin user does not have an 
> SID:
> ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
> -W -b cn=users,cn=accounts,dc=semi,dc=example,dc=net uid=admin '*' + | grep 
> -i ipantsecurityidentifier
> 
> The solution from the other thread, and from 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts#proc_enabling-security-identifiers-sids-in-idm_assembly_strengthening-kerberos-security-with-pac-information,
>  does not work for me, since the ipa command doesn't work, not even for the 
> admin user:
> 
> [[email protected] ~]
>  # kinit admin
> Password for [email protected]: 
> [[email protected] ~]
>  # ipa config-mod --enable-sid --add-sids
> ipa: ERROR: cannot connect to 'any of the configured servers': 
> https://ipa01.semi.example.net/ipa/json, 
> https://ipa02.semi.example.net/ipa/json
> 
> I found an alternative method at 
> https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#troubleshooting-and-debugging,
>  but this also does not work for me:
> 
> [[email protected] ~]
>  # ldapmodify -H ldapi://%2Frun%2Fslapd-SEMI-EXAMPLE-NET.socket -f 
> /tmp/ipa-sidgen-task-run.ldif
> SASL/GSSAPI authentication started
> SASL username: [email protected]
> SASL SSF: 256
> SASL data security layer installed.
> adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
> ldap_add: No such object (32)
> 
> I think ipa-sidgen-task does not exist in my LDAP directory, but I'm not sure 
> if I understand how this is supposed to work. I don't see ipa-sidgen-task or 
> anything like it from this search:
> ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
> -W -b cn=config | grep cn=tasks
> 
> Can anyone help me here? I think if I could get a ipantsecurityidentifier 
> attribute properly set up on my user or on the admin user, then I would be 
> able to use the ipa command to get SID's enabled and created everywhere.

Try, as root:

# /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid --add-sids

rob
--
___
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]