Thanks a lot and I will Go through it.
On Tue, Nov 28, 2023 at 4:56 PM Alexander Bokovoy <abokovoy(a)redhat.com>
wrote:
On Аўт, 28 ліс 2023, Pradeep KNS wrote:
>ok but in my case i don't use AD,Windows authentication or replica etc,
>just the centralised authentication system all are redhat os installed
>servers.
>In this case also i need to create a base RID?
Yes. You keep ignoring my references to previous discussions.
You will not get it working without proper SIDs because we require PAC
presence to protect against Kerberos impersonation. This is not a
theoretical probability anymore since November 2022 Microsoft security
updates. The same attacks apply to all Kerberos environments and current
way of protecting against them is to utilize MS-PAC buffers with
appropriate signatures and checksums. PAC buffers require use of SIDs to
address objects and that is what we enforce now.
If you still want to know details, I'd suggest to watch at least the two
talks we gave at SambaXP past few years:
- "Kerberos" by Andrew Bartlett
https://sambaxp.org/fileadmin/user_upload/sambaxp2022-Slides/Bartlett-Ker...
- Samba AD / MIT Kerberos: path out of experimental by me and Andreas
https://sambaxp.org/fileadmin/user_upload/sambaxp2023-Slides/Bokovoy_Schn...
https://youtu.be/0_cdYuIYw0o
While these talk about Samba AD, the changes went to both Samba and
FreeIPA, as well as MIT Kerberos (and Microsoft's Active Directory too).
So, look at the KCS I gave, understand how to add RID bases to your new
ID range and fix your problem through that.
>
>On Tue, Nov 28, 2023 at 4:30 PM Alexander Bokovoy <abokovoy(a)redhat.com>
>wrote:
>
>> On Аўт, 28 ліс 2023, Pradeep KNS wrote:
>> >Alexander,
>> >
>> >Thanks for that document.Bit of that i did it but it dint worked looks
>> like
>> >i might followed some wrong steps.
>> >
>> >My default id range mentioned below
>> >ipa idrange-find --all --raw
>> >----------------
>> >2 ranges matched
>> >----------------
>> > dn: cn=REALM_id_range,cn=ranges,cn=etc,dc=$SUFFIX
>> > cn: REALM_id_range
>> > ipabaseid: 771000000
>> > ipaidrangesize: 200000
>> > ipabaserid: 1000
>> > ipasecondarybaserid: 100000000
>> > iparangetype: ipa-local
>> > objectclass: top
>> > objectclass: ipaIDrange
>> > objectclass: ipaDomainIDRange
>> >
>> > dn: cn=REALM_subid_range,cn=ranges,cn=etc,dc=SUFFIX
>> > cn: REALM_subid_range
>> > ipabaseid: 2147483648
>> > ipaidrangesize: 2147352576
>> > ipabaserid: 2147283648
>> > ipanttrusteddomainsid: S-1-5-21-738065-838566-1448868364
>> > iparangetype: ipa-ad-trust
>> > objectclass: top
>> > objectclass: ipaIDrange
>> > objectclass: ipaTrustedADDomainRange
>> >
>> >##################################
>> >Manually created ID range
>> >
>> >[root@ipa-mum1 ~]# ipa idrange-find --all --raw
>> >----------------
>> >3 ranges matched
>> >----------------
>> > dn: cn=REALM_id_new_range,cn=ranges,cn=etc,dc=SUFFIX
>> > cn: REALM_id_new_range
>> > ipabaseid: 1000
>> > ipaidrangesize: 200000
>> > iparangetype: ipa-local
>> > objectclass: ipaIDrange
>> > objectclass: ipadomainidrange
>>
>> You created a new ID range but this range has no RID bases. Therefore,
>> the range cannot be used for SID assignment.
>>
>> The KCS article has a section about RID bases and how to choose them,
>> please follow that.
>>
>> >
>> >Then i created the user name called test user post it dint created
>> expected
>> >user attribute
>> >
>> >root@ipa~]#ipa user-add testuser --first=Test --last=User -uid=5189
>> >--gidnumber=4141 --password
>> >root@ipa ~]# ipa user-show testuser --all
>> > dn: uid=testuser,cn=users,cn=accounts,dc=real
>> > User login: testuser
>> > First name: Test
>> > Last name: User
>> > Full name: Test User
>> > Display name: Testuser
>> > Initials: TU
>> > Home directory: /home/testuser
>> > GECOS: Test User
>> > Login shell: /bin/bash
>> > Principal name: testuser(a)REALM.COM
>> > Principal alias: testuser(a)REALM.COM
>> > User password expiration: 20231124144147Z
>> > UID: 5189
>> > GID: 4141
>> > Account disabled: False
>> > Preserved user: False
>> > Password: True
>> > Member of groups: ipausers
>> > Kerberos keys available: True
>> > ipauniqueid: 88e7da44-8ad7-11ee-b06e-a68c8b95f346
>> > krbextradata: AAIrtmBlcm9vdC9hZG1pbkBBTFBIQS1HUkVQLkNPTQA=
>> > krblastadminunlock: 20231124144147Z
>> > krblastpwdchange: 20231124144147Z
>> > krbloginfailedcount: 0
>> > mepmanagedentry: cn=testuser,cn=groups,cn=accounts,dc=example,dc=com
>> > objectclass: top, person, organizationalperson, inetorgperson,
inetuser,
>> >posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject,
ipasshuser,
>> >ipaSshGroupOfPubKeys, mepOriginEntry
>> >
>> >The above method followed but after creating another id range
manually, I
>> >don't know where I missed post creation of ranges, for somehow it
didn't
>> >work. That's why I followed that generic method creating users and
>> >modifying it manually.
>> >PLease suggest me.
>> >
>> >On Tue, Nov 28, 2023 at 2:56 PM Pradeep KNS <
kns.pradeep(a)alpha-grep.com>
>> >wrote:
>> >
>> >> Thanks will go through it.
>> >>
>> >> On Tue, Nov 28, 2023 at 2:54 PM Alexander Bokovoy <
abokovoy(a)redhat.com>
>> >> wrote:
>> >>
>> >>> On Аўт, 28 ліс 2023, Pradeep KNS wrote:
>> >>> >Could you please help me with those threads here to regenerate
sid’s.
>> >>>
>> >>>
https://access.redhat.com/articles/7027037
>> >>>
>> >>> >
>> >>> >
>> >>> >On Tue, 28 Nov 2023 at 2:27 PM, Alexander Bokovoy <
>> abokovoy(a)redhat.com>
>> >>> >wrote:
>> >>> >
>> >>> >> On Аўт, 28 ліс 2023, Pradeep KNS wrote:
>> >>> >> >Yeah,
>> >>> >> >But my default id range starts with 770000 but all my
existing
>> >>> >> >infrastructure uid's are within 4 digits like
4147,8921,9756
like
>> >>> this.
>> >>> >> >Here I am facing an issue.
>> >>> >> >
>> >>> >> >That's why I am creating users with default id
range and then
>> later I
>> >>> am
>> >>> >> >modifying it via uid's as per my infrastructure
then
ipantuserattrs
>> >>> >> created
>> >>> >> >and I am able to authenticate with password.
>> >>> >>
>> >>> >> This is wrong.
>> >>> >>
>> >>> >> >
>> >>> >> >Can you suggest to me that with this setup i can
easily handle
>> >>> 350Users
>> >>> >> for
>> >>> >> >around 400 servers across different different
locations with
cache
>> of
>> >>> >> >storing on ipa clients.
>> >>> >>
>> >>> >> As I already said in other threads, create additional ID
range
that
>> >>> >> covers your 4-digit IDs, then re-run SID generation to
make sure
>> those
>> >>> >> users get proper SIDs.
>> >>> >>
>> >>> >> This is covered in the KCS.
>> >>> >>
>> >>> >> >
>> >>> >> >On Tue, Nov 28, 2023 at 2:00 PM Alexander Bokovoy
<
>> >>> abokovoy(a)redhat.com>
>> >>> >> >wrote:
>> >>> >> >
>> >>> >> >> Please don't drop mailing list.
>> >>> >> >>
>> >>> >> >> On Аўт, 28 ліс 2023, Pradeep KNS wrote:
>> >>> >> >> >Hey Alexander,
>> >>> >> >> >
>> >>> >> >> >Thanks For the Reply.
>> >>> >> >> >
>> >>> >> >> >But in my case i have fixed it by recreating
the user on Ipa
web
>> >>> UI and
>> >>> >> >> >observing ipantuserattrs created password
logins are working
>> fine.
>> >>> >> >> >
>> >>> >> >> >But do I face any issues if I try to modify
the base id range
>> >>> >> manually? as
>> >>> >> >> >per redhat docs which is not recommended to
modify.
>> >>> >> >>
>> >>> >> >> If you have re-created your user and that new one
works, it
means
>> >>> >> >> underlying infrastructure works properly. Older
user entries
need
>> >>> to be
>> >>> >> >> fixed. Preferrably through a new ID range, if
those entries
use
>> IDs
>> >>> >> >> which are outside of the main ID range.
>> >>> >> >>
>> >>> >> >> >
>> >>> >> >> >Also on ipa 4.11 they support dedicated ssh
key based
>> >>> >> >> >authentication.Ofcourse now also its
working.
>> >>> >> >> >
>> >>> >> >> >My setup is that I have internal dns which is
handled by a
>> puppet
>> >>> and
>> >>> >> >> >slowly will move it to a dedicated internal
dns server so
that's
>> >>> why i
>> >>> >> >> >opted for ipa installation without dns.
>> >>> >> >> >
>> >>> >> >> >On Tue, Nov 28, 2023 at 1:06 PM Alexander
Bokovoy <
>> >>> abokovoy(a)redhat.com
>> >>> >> >
>> >>> >> >> >wrote:
>> >>> >> >> >
>> >>> >> >> >> On Пан, 27 ліс 2023, Pradeep KNS via
FreeIPA-users wrote:
>> >>> >> >> >> >Hi Rob,
>> >>> >> >> >> >Thank you for your email. I've
identified the issue.
>> >>> >> >> >> >When attempting to create a user
using the 'ipa user-add'
>> >>> command
>> >>> >> and
>> >>> >> >> >> >defining the UID and GID according
to my specifications,
the
>> UID
>> >>> >> falls
>> >>> >> >> >> >within the 4-digit range, for
instance, 4141. The
>> >>> >> >> >> >IPA IDs range during installation
was set to 770000. Users
>> >>> created
>> >>> >> >> within
>> >>> >> >> >> >this range are accepted with their
passwords. However,
users
>> >>> created
>> >>> >> >> with
>> >>> >> >> >> >UIDs like 4141 or 4142 encounter
issues.
>> >>> >> >> >> >
>> >>> >> >> >> >Looks like attributes, were not
creating
>> >>> >> >> >> >
>> >>> >> >> >> >objectclass: top, person,
organizationalperson,
>> inetorgperson,
>> >>> >> >> inetuser,
>> >>> >> >> >> >posixaccount, krbprincipalaux,
krbticketpolicyaux,
ipaobject,
>> >>> >> >> ipasshuser,
>> >>> >> >> >> >ipaSshGroupOfPubKeys,
mepOriginEntry, ipantuserattrs
>> >>> >> >> >> >
>> >>> >> >> >> >If i mention uid and gid using ipa
user-add command
>> >>> >> >> >> >ipantuserattrs is not getting
create.
>> >>> >> >> >> >
>> >>> >> >> >> >I tried to modify default range but
it dint happened.
>> >>> >> >> >>
>> >>> >> >> >> See my answers in a parallel thread
'kinit fails on freeipa
>> >>> master:
>> >>> >> File
>> >>> >> >> >> or directory not found'.
>> >>> >> >> >>
>> >>> >> >> >> >
>> >>> >> >> >> >
>> >>> >> >> >> >
>> >>> >> >> >> >On Mon, 27 Nov 2023 at 9:41 PM, Rob
Crittenden <
>> >>> rcritten(a)redhat.com
>> >>> >> >
>> >>> >> >> >> wrote:
>> >>> >> >> >> >
>> >>> >> >> >> >> Pradeep KNS wrote:
>> >>> >> >> >> >> > Hi,
>> >>> >> >> >> >> > I have installed an ipa
with internal dns.After
>> installing
>> >>> >> updated
>> >>> >> >> >> >> > entries on dns as well.
>> >>> >> >> >> >> >
>> >>> >> >> >> >> > My main criteria is to
communicate with ipa clients
with
>> ssh
>> >>> >> >> keybased
>> >>> >> >> >> >> > authentication which is
working fine.
>> >>> >> >> >> >> >
>> >>> >> >> >> >> > Today i tot of i want to
test with password based
>> >>> authentication
>> >>> >> >> which
>> >>> >> >> >> >> > is not happening.I dont
know where i am missing
>> >>> >> >> >> >> >
>> >>> >> >> >> >> >
>> >>> >> >> >> >> > [root(a)example.com
<mailto:root@example.com>]# ipa
>> --version
>> >>> >> >> >> >> > VERSION: 4.10.1,
API_VERSION: 2.251
>> >>> >> >> >> >> > [root(a)example.com
<mailto:root@example.com>]#
>> >>> >> >> >> >> >
>> >>> >> >> >> >> > **********************
PREVIOUS MESSAGE WAS TRIGGERED
BY
>> THE
>> >>> >> >> FOLLOWING
>> >>> >> >> >> >> > BACKTRACE:
>> >>> >> >> >> >> > * (2023-11-23
19:33:16): [krb5_child[11588]]
>> >>> [tgt_req_child]
>> >>> >> >> >> >> > (0x1000): [RID#15]
Password was expired
>> >>> >> >> >> >>
>> >>> >> >> >> >> The user's password is
expired.
>> >>> >> >> >> >>
>> >>> >> >> >> >> IPA intends that only the
end-user knows their
password. So
>> >>> if it
>> >>> >> is
>> >>> >> >> set
>> >>> >> >> >> >> or reset by an administrator
the user will need to
change
>> it.
>> >>> >> >> >> >>
>> >>> >> >> >> >> Is the user not prompted to
reset it?
>> >>> >> >> >> >>
>> >>> >> >> >> >> rob
>> >>> >> >> >> >>
>> >>> >> >> >> >> > * (2023-11-23
19:33:16): [krb5_child[11588]]
>> >>> >> >> [sss_krb5_responder]
>> >>> >> >> >> >> > (0x4000): [RID#15] Got
question [password].
>> >>> >> >> >> >> > * (2023-11-23
19:33:16): [krb5_child[11588]]
>> >>> >> [map_krb5_error]
>> >>> >> >> >> >> > (0x0020): [RID#15] 2138:
[-1765328324][Generic error
(see
>> >>> >> e-text)]
>> >>> >> >> >> >> > **********************
BACKTRACE DUMP ENDS HERE
>> >>> >> >> >> >> >
*********************************
>> >>> >> >> >> >> >
>> >>> >> >> >> >> > ssh log
>> >>> >> >> >> >> >
>> >>> >> >> >> >> > Nov 23 19:33:16
test-example.com <
>>
http://test-example.com>
>> >>> >> >> >> sshd[11586]:
>> >>> >> >> >> >> > pam_sss(sshd:auth):
authentication failure; logname=
>> uid=0
>> >>> >> euid=0
>> >>> >> >> >> >> > tty=ssh ruser=
rhost=10.10.1.1 user=harsh
>> >>> >> >> >> >> > Nov 23 19:33:16
test-example.com <
>>
http://test-example.com>
>> >>> >> >> >> sshd[11586]:
>> >>> >> >> >> >> > pam_sss(sshd:auth):
received for user harsh: 4 (System
>> >>> error)
>> >>> >> >> >> >> > Nov 23
19:33:18test-example.com <
>>
http://18test-example.com>
>> >>> >> >> >> sshd[11584]:
>> >>> >> >> >> >> > error: PAM: Authentication
failure for harsh from
>> 10.10.1.1
>> >>> >> >> >> >> > Nov 23 19:33:20
test-example.com <
>>
http://test-example.com>
>> >>> >> >> >> sshd[11584]:
>> >>> >> >> >> >> > Connection closed by
authenticating user harsh
10.10.1.1
>> >>> port
>> >>> >> 47724
>> >>> >> >> >> >> > [preauth]
>> >>> >> >> >> >>
>> >>> >> >> >> >>
>> >>> >> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >> --
>> >>> >> >> >> / Alexander Bokovoy
>> >>> >> >> >> Sr. Principal Software Engineer
>> >>> >> >> >> Security / Identity Management
Engineering
>> >>> >> >> >> Red Hat Limited, Finland
>> >>> >> >> >>
>> >>> >> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> --
>> >>> >> >> / Alexander Bokovoy
>> >>> >> >> Sr. Principal Software Engineer
>> >>> >> >> Security / Identity Management Engineering
>> >>> >> >> Red Hat Limited, Finland
>> >>> >> >>
>> >>> >> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> / Alexander Bokovoy
>> >>> >> Sr. Principal Software Engineer
>> >>> >> Security / Identity Management Engineering
>> >>> >> Red Hat Limited, Finland
>> >>> >>
>> >>> >>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> / Alexander Bokovoy
>> >>> Sr. Principal Software Engineer
>> >>> Security / Identity Management Engineering
>> >>> Red Hat Limited, Finland
>> >>>
>> >>>
>>
>>
>>
>>
>> --
>> / Alexander Bokovoy
>> Sr. Principal Software Engineer
>> Security / Identity Management Engineering
>> Red Hat Limited, Finland
>>
>>
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland