Univention Bugzilla – Bug 56572
Add option to create context admin user, when creating context
Last modified: 2023-09-18 08:27:36 CEST
Summary: The core issue is that logging in as the Context Administrator ("oxadmin-context") is not possible. This is causing a critical problem in managing calendar access. Details: School Number: 110504 (OX-Context) Calendar Name: School Calendar Previous Owner: [Previous Owner's Name] Current Owner: Context Admin Issue: Unable to log in as the Context Administrator, which is essential for managing calendar access. Developer's Response: The developer has identified that the login as "oxadmin-context110504" is failing due to the following error in the log: 2023-08-31T12:31:10,589+0200 ERROR [OXWorker-0050500] com.openexchange.authentication.ucs.common.impl.UCSLookupImpl.getUserDn(UCSLookupImpl.java:439) User oxadmin-context110504 not found in LDAP This error indicates that the user "oxadmin-context110504" is not found in LDAP, which is a critical part of the authentication process. Severity: This issue is classified as Critical because it prevents the Context Administrator from accessing the system, affecting calendar management. Steps to Reproduce: Attempt to log in as "oxadmin-context110504." Observe the error in the log: "User oxadmin-context110504 not found in LDAP." Expected Results: The Context Administrator should be able to log in successfully. Actual Results: The login as "oxadmin-context110504" fails with the error message "User oxadmin-context110504 not found in LDAP."
Please state the version of UCS and the apps you are using. → Copy the output of "univention-app info" here.
Ticket 2023083021000196 Note 6 explicitly states that the current solution doesn't create a corresponding account in LDAP. So thanks to Daniel for re-classifying the Bug as OX related rather than an LDAP bug.
# univention-app info UCS: 5.0-4 errata750 Installed: fetchmail=6.3.26 mailserver=12.0 ox-connector=2.2.7 oxseforucs=7.10.6-ucs9 During the creation of the default context 10 an account for the context admin (oxadmin) is created in LDAP as well. Obviously the same password is set in LDAP and in OX (for the Admin API) . It is possible to log in to OX App Suite using this account and do administrative things like re-assigment of public calendars/contactfolders. For contexts that a created later there is no corresponding account in LDAP. While it is possible to create such an account manually in LDAP its suitability is limited as the capabilities of the additional context-admins are limited in a way that using the App Suite is impossible. root@dn1:~# listoxuser.sh 20 --csv Display_name,PrimaryEmail,MaxQuota,UsedQuota,LoadRemoteMailContentByDefault,PasswordMech,Mail_folder_confirmed_ham_name,Mail_folder_confirmed_spam_name,GUI_Spam_filter_capabilities_enabled,DefaultSenderAddress,FolderTree,DriveFolderMode,UserAttributes,GuiPreferences,Email1,Mailenabled,Password,Sur_name,Given_name,FilestoreId,FilestoreOwner,Filestore_name,Birthday,Anniversary,Branches,Business_category,Postal_code_business,State_business,Street_business,Telephone_callback,City_home,Commercial_register,Country_home,Company,Department,Email2,Email3,EmployeeType,Fax_business,Fax_home,Fax_other,ImapServer,ImapLogin,SmtpServer,Instant_messenger1,Instant_messenger2,Telephone_ip,Telephone_isdn,Mail_folder_drafts_name,Mail_folder_sent_name,Mail_folder_spam_name,Mail_folder_trash_name,Mail_folder_archive_full_name,Manager_name,Marital_status,Cellular_telephone1,Cellular_telephone2,Info,Nickname,Number_of_children,Note,Number_of_employee,Telephone_pager,Password_expired,Telephone_assistant,Telephone_business1,Telephone_business2,Telephone_car,Telephone_company,Telephone_home1,Telephone_home2,Telephone_other,Position,Postal_code_home,Profession,Telephone_radio,Room_number,Sales_volume,City_other,Country_other,Middle_name,Postal_code_other,State_other,Street_other,Spouse_name,State_home,Street_home,Suffix,Tax_id,Telephone_telex,Timezone,Title,Telephone_ttytdd,UploadFileSizeLimit,UploadFileSizeLimitPerFile,Image1ContentType,Url,Userfield01,Userfield02,Userfield03,Userfield04,Userfield05,Userfield06,Userfield07,Userfield08,Userfield09,Userfield10,Userfield11,Userfield12,Userfield13,Userfield14,Userfield15,Userfield16,Userfield17,Userfield18,Userfield19,Userfield20,PrimaryAccountName,Aliases,City_business,Country_business,Assistant_name,Telephone_primary,Categories,Name,Language,Id,access-calendar,access-contacts,access-delegate-tasks,access-edit-public-folder,access-ical,access-infostore,access-read-create-shared-Folders,access-syncml,access-tasks,access-vcard,access-webdav,access-webdav-xml,access-webmail,access-edit-group,access-edit-resource,access-edit-password,access-collect-email-addresses,access-multiple-mail-accounts,access-subscription,access-publication,access-active-sync,access-usm,access-olox20,access-denied-portal,access-global-address-book-disabled,access-public-folder-editable "OX Admin","oxadmin-context20@training.ucs","-1","null","false","{SHA-256}",,,"false","oxadmin-context20@training.ucs","null",,"loginnamerecorder=[user_login=oxadmin-context20],config=[com.openexchange.mail.specialuse.check=true]",,"oxadmin-context20@training.ucs","true",,"Admin","OX","0","0",,,,,,,,,,,,,,,,,,,,,"imap://localhost:143",,"smtp://localhost:25",,,,,,,,,"",,,,,,,,,,,"false",,,,,,,,,,,,,,,,,,,,,,,,,,,"Europe/Berlin",,,"-1","-1",,,,,,,,,,,,,,,,,,,,,,,"E-Mail","oxadmin-context20@training.ucs",,,,,,"oxadmin-context20","en_US","2","false","true","false","false","false","false","false","false","false","false","false","false","true","false","false","false","false","false","false","false","false","false","false","false","false","false" There might be a chance tryining to fix this with the changeuser tool (OX-cli).
The behaviour that no LDAP-accounts have been created for additional contexts appears to be unrelated to the switch of the provisioning methods. But there is a regression regarding the capabilities example of the values created with the old provisioning. "OX Admin","oxadmin-context110504@redacted.de","-1","null",,,,,"false","{SHA}",,,"false","oxadmin-context110504@redacted.de","null",,"loginnamerecorder=[user_login=oxadmin-context110504],config=[com.openexchange.mail.specialuse.check=true]",,"oxadmin-context110504@redacted.de","true",,"Admin","OX","0","0",,,,,,,,,,,,,,,,,,,,,"imap://localhost:143",,"smtp://localhost:25",,,,,,,,,"",,,,,,,,,,,"false",,,,,,,,,,,,,,,,,,,,,,,,,,,"Europe/Berlin",,,"-1","-1",,,,,,,,,,,,,,,,,,,,,,,"E-Mail","oxadmin-context110504@redactedde",,"oxadmin-context110504","de_DE","2","true","true","true","true","true","false","true","false","true","true","true","true","true","false","false","false","true","false","true","false","false","true","true","false","false","false"
Yes, this is no regression from the previous behavior. UDM user accounts have never been automatically created for additional contexts. So I have relabeled this as a feature request. Please open a separate bug about the changed capabilities of newly created context admins, and the impact of that change. --- Feature request: Add an option to the "oxmail/oxcontext" UDM module (and thus also the UMC module) that results in the system (probably listener) creating a UDM users/user object for the new ox context. This should result in the same behavior that exists for the "oxadmin" of context 10 when installing the OX app.