Quote from: Justin Derrick on September 03, 2025, 05:19:52 PMYou need to specify the Application Group or User Group that you want to apply that query restriction to.

As a matter of good governance, all permissions should be administered at the Group level, and users added to and removed from Groups in order to grant or restrict or deny access/permissions.

-JD.

Yes, although I specified the group, I still cannot update the query restriction using the arsxml command.

...
  <applicationGroup name="AG1" ... >
     <permission group="GROUP"  ....... queryRes="br_code = '001'" />
...

IBM suggested to create a common group in AD and map all the other groups as a member of this group. And use the common group to get all the users linked to the member groups using nested query.

Common group name : ONDM-ALL

ARS_LDAP_USER_FILTER=(&(objectclass=user)(memberof:1.2.840.113556.1.4.1941:=CN=ONDM-ALL,OU=ONDM-IN,OU=APPS,dc=xxxx,dc=yyyy,dc=zzz,dc=com))

You need to specify the Application Group or User Group that you want to apply that query restriction to.

As a matter of good governance, all permissions should be administered at the Group level, and users added to and removed from Groups in order to grant or restrict or deny access/permissions.

-JD.

I'm during try update query restriction by arsxml.

USER1 has permission to view application group AG1 but no query restriction configured at first time.
So, I export xml by arsxml export will have output xml something like this:

<onDemand xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <applicationGroup name="AG1" ... >
      <field name ... >
      <permission user="USER1" adminAuthority="true" lvAuthority="true" accessAuthority="true" docViewPerm="true" docAddPerm="true" docUpdatePerm="false" docDeletePerm="true" docPrintPerm="true" docCopyPerm="true" docHoldPerm="true" docCFSODPerm="true" docFTIPerm="true" annotViewPerm="true" annotAddPerm="true" annotDeletePerm="false" annotUpdatePerm="false" annotCopyPerm="true" />
       ....
   </applicationGroup>
</onDemand>

-- Then I have edit to --

<onDemand xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <applicationGroup name="AG1" ... >
      <field name ... >
      <permission user="USER1" adminAuthority="true" lvAuthority="true" accessAuthority="true" docViewPerm="true" docAddPerm="true" docUpdatePerm="false" docDeletePerm="true" docPrintPerm="true" docCopyPerm="true" docHoldPerm="true" docCFSODPerm="true" docFTIPerm="true" annotViewPerm="true" annotAddPerm="true" annotDeletePerm="false" annotUpdatePerm="false" annotCopyPerm="true"  queryRes="br_code = '001'" />
       ....
   </applicationGroup>
</onDemand>

When I execute arsxml command, it's not updated anything in permission:
arsxml  -hlocalhost -uadmin -ppassword -i update_perm.xml  -v -x -ecu

...
ARS7709I Adding applicationGroup-permission, AG1-USER1
ARS7743E A permission object named 'USER1' already exists.
ARS7761I Add of applicationGroup-permission, USER1-USER1 failed.

 -- Then I tried 'task="update"' inside xml tag, still no luck --
      <permission user="USER1" task="update" adminAuthority="true" lvAuthority="true" accessAuthority="true" docViewPerm="true" docAddPerm="true" docUpdatePerm="false" docDeletePerm="true" docPrintPerm="true" docCopyPerm="true" docHoldPerm="true" docCFSODPerm="true" docFTIPerm="true" annotViewPerm="true" annotAddPerm="true" annotDeletePerm="false" annotUpdatePerm="false" annotCopyPerm="true"  queryRes="br_code = '001'" />

But something changed in message ...

ARS7755E The permission object named 'USER1' can not be updated unless the parent object is also being updated.

Can anyone suggest solution to me?

Audience:    Anyone who uploads files to Blue Diamond using the SFTP protocol.

Description:    The current RSA SSH key, used to establish a connection to the Blue Diamond FTP server, will be replaced by an ECDSA (Elliptic Curve Digital Signature Algorithm) key. This change will affect anyone who uploads files to Blue Diamond using the SFTP protocol via command line or FTP clients such as FileZilla or WinSCP.

Effective Date:    September 8, 2025.

Action/Impact:    The current RSA SSH key, used to establish a connection to the Blue Diamond FTP server, will be replaced with an ECDSA key on September 8, 2025. Anyone using the SFTP protocol must accept the new key on or after this date in order to continue uploading files to Blue Diamond.

Implementing the new ECDSA key
•   Command line (sftp/scp) - Update your "known_hosts" file (this process varies between different OS. If in doubt, please refer to your System Admin or appropriate documentation)
o   If your known_hosts file has plain text hostnames (not hashed values):
�   Backup your "known_hosts" file
�   Get the new key from the Blue Diamond FTP Server and add it to your known_hosts file

ssh-keyscan -t ecdsa msciftpgw.im-ies.ibm.com >> ~/.ssh/known_hosts
o   For hashed hostnames/ip in known_hosts file:
�   Backup your "known_hosts" file
�   Get the new key from the Blue Diamond FTP Server and add it to your known_hosts file

ssh-keyscan -t ecdsa -H msciftpgw.im-ies.ibm.com >> ~/.ssh/known_hosts
•   FTP clients (ie. FileZilla or WinSCP) - When you attempt to connect to the Blue Diamond FTP server using these Windows tools, you will be prompted to add the new key to the cache.  When prompted, click "Always trust this host, add this key to the cache" and click OK.

•   zOS: Ensure your OS version supports ECDSA IBM zOS Support Doc at https://www.ibm.com/docs/en/zos/3.1.0?topic=ssl-elliptic-curve-cryptography-support

Support/Contact:    For more information or to request support, please email sdsmsci@us.ibm.com

Additional information:    For up-to-date status information on Blue Diamond Services, visit our Status Page at Blue Diamond Status Page at https://status.im-ies.ibm.com/index.html?continue

Hi Lincoln -- as you've already discovered, it's very complicated...

You need to match a user to the groups they belong to, and then the user groups to Folders, and then to specific Application Groups and Applications -- and there might even be query restrictions involved which further reduce the pool of data an individual user might have access to.

In the past, I've had to manually copy access privileges between servers, and it was a real challenge to get everything working properly.

I'll go through some old scripts / notes and post some SQL that might be helpful.

Hi Grahaj & Lars.

There's no real standard for what the various return codes mean, it's up to the developer to define them for each utility.

I'm guessing that in this situation, I'm guessing both 3 and 768 are warnings.  I'll test out this specific situation and see if I can narrow it down.  Both 3 and 768 are peculiar numbers, as they translate to 0000000011 and 1100000000 in binary, so the return codes might be different based on the 'endianness' of the CPU/OS.

-JD.

I reached this post via a link from a CMOD Wiki page relating to arsdoc Return Codes.

When I run a similar command, I receive RC 3, not 768. The main differences:
a. I run on a Windows cmd client, a Windows 2022 server, and I use CMOD version 10.5.0.7 (on both ends)
b. I run arsdoc QUERY, not GET:
   arsdoc query -h ondemand -f "myFolder" -i "WHERE field1='value1' AND field2='value2'" -u LILOLDME -p C:\Temp\my.stash -L 1

Maybe they changed the return code in a later version, or maybe it is different whether you run GET or QUERY?

I know the z/OS versions sometimes are quite different, and that they may not be in sync with the Multiplatform versions, but it would be interesting to know; If you run the same again, do you still get the same RC? Or has it indeed been changed.

@Admins: please don't ban me for typing the "W" word in a z/OS sub-forum! ;)

I am trying to write up some SQL to create a report showing all users and the reports and folders they have access to but I am struggling with it.
Would anyone happen to have done this before or have a sample SQL that is doing this same thing?

Thanks, Lincoln

We have Ondemand 10.5 running in Linux. We are setting up LDAP sync with Active Directory. Below is our configuration.

ARS_LDAP_SERVER=xxxxx.yyy.zzz.com
ARS_LDAP_PORT=636
ARS_LDAP_USE_SSL=TRUE
ARS_LDAP_BASE_DN=DC=xxxx,DC=yyyyy,DC=zzz,DC=com
ARS_LDAP_BIND_ATTRIBUTE=sAMAccountName
ARS_LDAP_MAPPED_ATTRIBUTE=CN
ARS_LDAP_ALLOW_ANONYMOUS=FALSE
ARS_LDAP_REFERRALS=FALSE
ARS_LDAP_BIND_MESSAGES_FILE=
ARS_LDAP_IGN_USERIDS=admin
ARS_LDAP_IGN_GROUPS=admin,admin1
ARS_LDAP_KEYRING_FILE=/ars/certs/ondemand.kdb
ARS_LDAP_KEYRING_LABEL=CERTS
ARS_LDAP_SERVER_TYPE=AD
ARS_LDAP_GROUP_FILTER=(&(objectClass=group)(CN=ONDM*,OU=ONDM-IN,OU=APPS,dc=xxxx,dc=yyyy,dc=zzz,dc=com))
ARS_LDAP_USER_FILTER=(&(objectclass=user)(memberOf=CN=ONDM*,OU=ONDM-IN,OU=APPS,dc=xxxx,dc=yyyy,dc=zzz,dc=com))
ARS_LDAP_GROUP_MAPPED_ATTRIBUTE=CN


Multiple Security Groups under OU: APPS/ONDM-IN

ONDM-ADMINS
ONDM-USERS-READONLY
ONDM-OPS

When running ARSLSYNC, we are able to pull the groups all under the OU which starts with the name ONDM.
But not able to pull the users. Seems memberOf attribute running at DN level not allowing wildcard. If we provide the group name explicitly, we are able to get the users.

Anyone did any similar setup, Kindly advise,