On 2/1/22 09:24, Scott Serr via FreeIPA-users wrote:
Hello,
I have an IPA cluster of 5 servers, running version 4.9.6-10. The
system was put in production Feb 2021 and has been updated several
times. These updates have sometimes not gone well:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
I'll try to keep this concise. A user was not able to access an NFS
share provided by our EMC Isilon. They were a member of the group
that owned the directory/share. But not always, it depended upon what
Isilon IP was mounted. After many hours of troubleshooting, we found
the group was newly created and different than our old groups.
The group had an attribute we are not yet familiar with:
ipaNTSecurityIdentifier
The group also had an objectClass none of our others have:
ipaNTGroupAttrs
This brought to my attention an issue I saw last week when trying to
add an IPA replica to our cluster. This is new prompting that I have
not seen before while setting up replicas:
WARNING: 1755 existing users or groups do not have a SID identifier
assigned.
Installer can run a task to have ipa-sidgen Directory Server plugin
generate
the SID identifier for all these users. Please note, in case of a high
number of users and groups, the operation might lead to high replication
traffic and performance degradation. Refer to ipa-adtrust-install(1)
man page
for details.
Do you want to run the ipa-sidgen task? [no]:
----
I'm trying to understand the thread "Login failed due to an unknown
reason"
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
where Alexander explains how to fix SIDs. Also there is a thread: IPA
WebGUI login fails with "Login failed due to an unknown reason".
Are SIDs now required? An aside, in one of my install-replica
attempts last week I was asked to provide a NetBIOS name. :(
My IPA cluster is now wanting to do these SMB/AD sorts of things.
Newly created groups now have ipaNTSecurityIdentifier, which causes
permission issues when mounting NFS on our Isilon. Are we forced down
this road or do I have something misconfigured that is "half-way"
doing AD? I'd like to learn about the big picture.
Alexander asked in the "Login failed do to an unknown reason" thread if
ipa migrate-ds was run from another IPA instance. It was and seems to
have caused these sorts of problems. In my case I ran migrate-ds from
OpenLDAP. Would this be causing my SID issues? I may need to setup a
test environment and run "ipa-sidgen" and see if it behaves. I'm
apprehensive of doing it in production, as it really confused Isilon NFS
mount permission.
Thank you for any guidance,
Scott