Univention Bugzilla – Bug 39499
user is not detected as user if functional in univentionObjectFlag
Last modified: 2022-09-26 15:20:00 CEST
I created a user but the user is not detected as user anymore after creation. » udm users/user create "$@" \ » » --position "cn=users,$ldap_base" \ » » --set username="foobar" --set lastname="schoolopsiadmin" --set firstname="schoolopsiadmin" \ » » --set password="PASSWORD" --set objectFlag="functional" \ » » --option ldap_pwd --option posix # udm users/user remove --dn uid=schoolopsiadmin-master,cn=users,dc=univention,dc=intranet --set lastname=Foo E: object not found # udm users/user remove --dn uid=schoolopsiadmin-master,cn=users,dc=univention,dc=intranet E: object not found LDIF of the user: 569 uid=schoolopsiadmin-master,cn=users,dc=univention,dc=intranet uid: schoolopsiadmin-master objectClass: top objectClass: person objectClass: univentionPWHistory objectClass: posixAccount objectClass: shadowAccount objectClass: simpleSecurityObject objectClass: uidObject objectClass: univentionObject loginShell: /bin/bash userPassword: {crypt}$6$w864X85NJXqyZmW1$bH5NiTb/ZGU/QYsCO11YiYRgyzTpPbBOvIq2omEjgx6Ct9OzUSq6.WE/zcL.mTsokAzSurR5na.oKENN5e4TA0 uidNumber: 2022 univentionObjectFlag: functional gecos: schoolopsiadmin sn: schoolopsiadmin pwhistory: $6$tia7DIfdhgeOguYt$vIvg1YbPb9/kq3Eyo1GQoNUpjKhdO6oTdWj8HhA6UMitVkimI.XvAR7rToel2QgH9o0QvxsxCVp.aTFOACUe21 homeDirectory: /home/schoolopsiadmin-master univentionObjectType: users/user cn: schoolopsiadmin gidNumber: 5001
AFAIK the objectFlag / univentionObjectFlag value "functional" was introduced to ignore uses from the license count, maybe the implementer achieved this goal by adding the line and not 'functional' in attr.get('univentionObjectFlag',[]) to the identify function of the UDM users/user module. This is "not optimal".
Ahh, now I understand. Maybe hidden would have been sufficient in my case (I don't know).
But still I consider this a bug. The objectFlag is not "hidden" or whatever but "functional", which must *only* exclude it from the license count.
The requirement at the time was, that a functional user should also be hidden, even if the name suggests otherwise.
univentionObjectFlag is multivalue.
We should adjust UMC and UDM-CLI to just don't list them. And then remove the broken identification. Otherwise one cannot even change those users easily.
Why not just additionally flag them as hidden? =========================================================================== #!/bin/bash eval "$(ucr shell)" ldif="$(univention-ldapsearch -xLLL \ '(&(univentionObjectFlag=functional)(!(univentionObjectFlag=hidden)))' \ ) relevant_dns=$(sed -n 's/^dn: //p' <<<"$ldif") while read dn; do ldapmodify -x -D "cn=admin,$ldap_base" -y /etc/ldap.secret <<-%EOR dn: $dn changetype: modify add: univentionObjectFlag univentionObjectFlag: hidden %EOR done <<<"$relevant_dns" ===========================================================================
(In reply to Arvid Requate from comment #7) > Why not just additionally flag them as hidden? Maybe because they are not really hidden then? Currently you cannot see those users in UMC at all. If you change this and activate the 'show hidden' checkbox in UMC you will see them again. Also on the CLI they are currently "really" hidden.
(In reply to Florian Best from comment #6) > We should adjust UMC and UDM-CLI to just don't list them. And then remove > the broken identification. Otherwise one cannot even change those users > easily. I think it is fine to have *all* users displayed via UDM-CLI. Why should such a user be excluded? I see primary reasons for usability with UMC, not for the CLI.
> I think it is fine to have *all* users displayed via UDM-CLI. No objections.
@Andreas: My suggested solution might not work due to this bug.
This issue has been filled against UCS 4.0. The maintenance with bug and security fixes for UCS 4.0 has ended on 31st of May 2016. Customers still on UCS 4.0 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
Still causing trouble in UCS 5.0. See also Bug #51653.