Migrated users have not attribute ipaNThash

[Kiselev Mikhail]

Hello.
My specs:

cat /etc/system-release
CentOS Linux release 7.8.2003 (Core)

rpm -qa ipa-server
ipa-server-4.6.6-11.el7.centos.x86_64
We migrated users from openLDAP. These users do not have a attribute 
ipaNThash:

ldapsearch -h ipareplica2.opentech.local -D "cn=Directory Manager" -x 
-LLL -W -b 'cn=users,cn=accounts,dc=opentech,dc=local' 'uid=mkiselev' 
ipaNTHash
Enter LDAP Password:
dn: uid=mkiselev,cn=users,cn=accounts,dc=opentech,dc=local
Changing the user's password doesn't help

If a new user is created in FreeIPA, then the attribute is:

ldapsearch -h ipareplica2.opentech.local -D "cn=Directory Manager" -x 
-LLL -W -b 'cn=users,cn=accounts,dc=opentech,dc=local' 'uid=test'
ipaNTHash
Enter LDAP Password:
dn: uid=test,cn=users,cn=accounts,dc=opentech,dc=local
ipaNTHash:: xaI3t+nY5wjYQ2thSKJfoQ==
What could be the problem?

[Alexander Bokovoy]

On pe, 18 joulu 2020, Kiselev Mikhail via FreeIPA-users wrote:
> Hello.
> My specs:
>
> cat /etc/system-release
> CentOS Linux release 7.8.2003 (Core)
>
> rpm -qa ipa-server
> ipa-server-4.6.6-11.el7.centos.x86_64
> We migrated users from openLDAP. These users do not have a attribute 
> ipaNThash:
>
> ldapsearch -h ipareplica2.opentech.local -D "cn=Directory Manager" -x 
> -LLL -W -b 'cn=users,cn=accounts,dc=opentech,dc=local' 'uid=mkiselev' 
> ipaNTHash
> Enter LDAP Password:
> dn: uid=mkiselev,cn=users,cn=accounts,dc=opentech,dc=local
> Changing the user's password doesn't help
>
> If a new user is created in FreeIPA, then the attribute is:
>
> ldapsearch -h ipareplica2.opentech.local -D "cn=Directory Manager" -x 
> -LLL -W -b 'cn=users,cn=accounts,dc=opentech,dc=local' 'uid=test' 
> ipaNTHash
> Enter LDAP Password:
> dn: uid=test,cn=users,cn=accounts,dc=opentech,dc=local
> ipaNTHash:: xaI3t+nY5wjYQ2thSKJfoQ==
> What could be the problem? 
As I answered already in the FreeIPA ticket you created, the issue is
within the content of your migrated user's entry.

In order to allow creating ipaNTHash attribute:
  - IPA configuration should allow storing NT hashes
  - LDAP entry should already have objectclass ipaNTUserAttrs or samSambaAccount
  - user have to change the password

As IPA users already have ipaNTHash, the first two conditions are
satisfied (globally and for the specific user object). IPA users are
required to change their password before use, so third condition is
satisfied as well.

For migrated users, the most likely situation is that they have no
ipaNTUserAttrs objectclass. You cannot easily add yourself because
ipaNTUserAttrs object class requires ipaNTSecurityIdentifier attribute
which value (SID) is autogenerated and tightly connected to the ID
ranges associated with the IPA deployment.

In order to add SIDs to users/groups that don't have them requires use
of 'ipa-adtrust-install --add-sids' on IPA server that has Trust
Controller role.

Running 'ipa-adtrust-install --add-sids' might still not produce SIDs
for some users and groups because their UIDs/GIDs might be out of the ID
range associated with IPA deployment. This is a common issue for users
migrated from a different LDAP server with 'ipa migrate-ds' because
those accounts most likely have UIDs/GIDs from completely different
range.

Either they need UIDs/GIDs to be allocated from IPA ID range or a new ID
range should be created to cover their UIDs/GIDs range. The latter
requires understanding how ID ranges are organized. I'd recommend you to
read 'ipa help idrange' carefully.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Kiselev Mikhail]

Thanks, this is my case:

"Running 'ipa-adtrust-install --add-sids' might still not produce SIDs
for some users and groups because their UIDs/GIDs might be out of the ID
range associated with IPA deployment. This is a common issue for users
migrated from a different LDAP server with 'ipa migrate-ds' because
those accounts most likely have UIDs/GIDs from completely different
range.

Either they need UIDs/GIDs to be allocated from IPA ID range or a new ID
range should be created to cover their UIDs/GIDs range. The latter
requires understanding how ID ranges are organized. I'd recommend you to
read 'ipa help idrange' carefully."

On 18.12.2020 17:31, Alexander Bokovoy wrote:
> As I answered already in the FreeIPA ticket you created, the issue is
> within the content of your migrated user's entry.
>
> In order to allow creating ipaNTHash attribute:
>  - IPA configuration should allow storing NT hashes
>  - LDAP entry should already have objectclass ipaNTUserAttrs or 
> samSambaAccount
>  - user have to change the password
>
> As IPA users already have ipaNTHash, the first two conditions are
> satisfied (globally and for the specific user object). IPA users are
> required to change their password before use, so third condition is
> satisfied as well.
>
> For migrated users, the most likely situation is that they have no
> ipaNTUserAttrs objectclass. You cannot easily add yourself because
> ipaNTUserAttrs object class requires ipaNTSecurityIdentifier attribute
> which value (SID) is autogenerated and tightly connected to the ID
> ranges associated with the IPA deployment.
>
> In order to add SIDs to users/groups that don't have them requires use
> of 'ipa-adtrust-install --add-sids' on IPA server that has Trust
> Controller role.
>
> Running 'ipa-adtrust-install --add-sids' might still not produce SIDs
> for some users and groups because their UIDs/GIDs might be out of the ID
> range associated with IPA deployment. This is a common issue for users
> migrated from a different LDAP server with 'ipa migrate-ds' because
> those accounts most likely have UIDs/GIDs from completely different
> range.
>
> Either they need UIDs/GIDs to be allocated from IPA ID range or a new ID
> range should be created to cover their UIDs/GIDs range. The latter
> requires understanding how ID ranges are organized. I'd recommend you to
> read 'ipa help idrange' carefully.

[Alexander Bokovoy]

On pe, 18 joulu 2020, Kiselev Mikhail via FreeIPA-users wrote:
> Thanks, this is my case:
>
> "Running 'ipa-adtrust-install --add-sids' might still not produce SIDs
> for some users and groups because their UIDs/GIDs might be out of the ID
> range associated with IPA deployment. This is a common issue for users
> migrated from a different LDAP server with 'ipa migrate-ds' because
> those accounts most likely have UIDs/GIDs from completely different
> range.
>
> Either they need UIDs/GIDs to be allocated from IPA ID range or a new ID
> range should be created to cover their UIDs/GIDs range. The latter
> requires understanding how ID ranges are organized. I'd recommend you to
> read 'ipa help idrange' carefully." 
Yep. See https://www.redhat.com/archives/freeipa-users/2017-February/msg00114.html

> On 18.12.2020 17:31, Alexander Bokovoy wrote:
> >As I answered already in the FreeIPA ticket you created, the issue is
> >within the content of your migrated user's entry.
> >
> >In order to allow creating ipaNTHash attribute:
> >Â - IPA configuration should allow storing NT hashes
> >Â - LDAP entry should already have objectclass ipaNTUserAttrs or 
> >samSambaAccount
> >Â - user have to change the password
> >
> >As IPA users already have ipaNTHash, the first two conditions are
> >satisfied (globally and for the specific user object). IPA users are
> >required to change their password before use, so third condition is
> >satisfied as well.
> >
> >For migrated users, the most likely situation is that they have no
> >ipaNTUserAttrs objectclass. You cannot easily add yourself because
> >ipaNTUserAttrs object class requires ipaNTSecurityIdentifier attribute
> >which value (SID) is autogenerated and tightly connected to the ID
> >ranges associated with the IPA deployment.
> >
> >In order to add SIDs to users/groups that don't have them requires use
> >of 'ipa-adtrust-install --add-sids' on IPA server that has Trust
> >Controller role.
> >
> >Running 'ipa-adtrust-install --add-sids' might still not produce SIDs
> >for some users and groups because their UIDs/GIDs might be out of the ID
> >range associated with IPA deployment. This is a common issue for users
> >migrated from a different LDAP server with 'ipa migrate-ds' because
> >those accounts most likely have UIDs/GIDs from completely different
> >range.
> >
> >Either they need UIDs/GIDs to be allocated from IPA ID range or a new ID
> >range should be created to cover their UIDs/GIDs range. The latter
> >requires understanding how ID ranges are organized. I'd recommend you to
> >read 'ipa help idrange' carefully.
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)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/[e-mail]... 


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Mikhail Kiselev]

I'm not add range:

[root@ipa ~]# ipa idrange-add --base-id=1000 --range-size=1000 --rid-base=1000
--secondary-rid-base=1000000 magrated_range                                               
                                       
ipa: ERROR: Constraint violation: New base range overlaps with existing base range.
[root@ipa ~]# ipa idrange-find
----------------
2 ranges matched
----------------
  Range name: E2E4.LOCAL_id_range
  First Posix ID of the range: 5
  Number of IDs in the range: 100000
  Domain SID of the trusted domain: S-1-5-21-585446347-204204591-2842534922
  Range type: Active Directory trust range with POSIX attributes

  Range name: OPENTECH.LOCAL_id_range
  First Posix ID of the range: 346600000
  Number of IDs in the range: 200000
  First RID of the corresponding RID range: 1000
  First RID of the secondary RID range: 100000000
  Range type: local domain range
----------------------------
Number of entries returned 2
----------------------------
[root@ipa ~]# ipa idrange-del E2E4.LOCAL_id_range
ipa: ERROR: invalid 'ipabaseid,ipaidrangesize': range modification leaving objects
with ID out of the defined range is not allowed
[root@ipa ~]# ipa trust-find
----------------
0 trusts matched
----------------
----------------------------
Number of entries returned 0
----------------------------

[Alexander Bokovoy]

On ma, 21 joulu 2020, Mikhail Kiselev via FreeIPA-users wrote:
> I'm not add range: 
Yes, you cannot because you are not following explanation in 
'ipa help idrange' and what I suggested. You need to design it
carefully.

> [root@ipa ~]# ipa idrange-add --base-id=1000 --range-size=1000 --rid-base=1000
> --secondary-rid-base=1000000 magrated_range 
You are attempting to create an ID range from 1000 to 2000.

> ipa: ERROR: Constraint violation: New base range overlaps with
> existing base range.
> [root@ipa ~]# ipa idrange-find
> ----------------
> 2 ranges matched
> ----------------
>   Range name: E2E4.LOCAL_id_range
>   First Posix ID of the range: 5
>   Number of IDs in the range: 100000
>   Domain SID of the trusted domain: S-1-5-21-585446347-204204591-2842534922
>   Range type: Active Directory trust range with POSIX attributes 
The range from 5 to 100000 has been already occupied by this ID range.
You cannot create an overlapping ID range object.

>   Range name: OPENTECH.LOCAL_id_range
>   First Posix ID of the range: 346600000
>   Number of IDs in the range: 200000
>   First RID of the corresponding RID range: 1000
>   First RID of the secondary RID range: 100000000
>   Range type: local domain range
> ----------------------------
> Number of entries returned 2
> ----------------------------
> [root@ipa ~]# ipa idrange-del E2E4.LOCAL_id_range
> ipa: ERROR: invalid 'ipabaseid,ipaidrangesize': range modification leaving objects
> with ID out of the defined range is not allowed 
You can manually check which IDs are in that range by looking at the
query in the directory server's access log and re-running it manually as
directory manager. When you run 'ipa idrange-del <range>', we do a check
that uses the range's values like this:

[21/Dec/2020:09:07:05.563137207 +0200] conn=345 op=4 SRCH
base="cn=accounts,dc=ipa1,dc=test" scope=2
filter="(&(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDObject))(|(&(uidNumber>=775400000)(uidNumber<=775599999))(&(gidNumber>=775400000)(gidNumber<=775599999))))"
attrs="uid cn"

so in your case it would be something like

(&(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDObject))(|(&(uidNumber>=5)(uidNumber<=100005))(&(gidNumber>=5)(gidNumber<=100005))))

Obvisouly, since you already migrated your old users/groups which have
UID/GID values in the range of (1000,2000), they would match the very
same LDAP filter and would be counted as belonging to the ID range you
are trying to remove, thus preventing you from removing the object.

> [root@ipa ~]# ipa trust-find
> ----------------
> 0 trusts matched
> ----------------
> ----------------------------
> Number of entries returned 0
> ---------------------------- 
If you already don't have the trust in place, you can remove the ID
object for E2E4.LOCAL_id_range with ldapdelete as cn=Directory Manager.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland