Configuration profile not defining multiple settings

[cfsievers]

Preface: I'm an utter neophyte at XML and .mobileconfig files, so please forgive what is likely to be my thundering ignorance.

The feature set of the Privileges app is a fantastic fit for my needs. I only have some modest requirements around locking the app preferences down to make it perfect. I have Jamf Pro available to push the profiles to my test Mac. Unfortunately I'm struggling to figure out why I can't seem to write a .mobileconfig file that defines multiple preference values. The profiles I've tried with single prefs work fine; it's just when I put multiple prefs that things fail; none of the settings are applied.

As I'm not really a coder and have next to no experience with XML in particular, I'm kind of cargo-culting my way around, but to no avail. Here is my current .mobileconfig test contents wherein I'm just trying to test the implementation of LimitToUser and ExpirationIntervalMax together in the same profile. Surely I am making some really obvious rookie mistake.

Code to follow if I can even figure out how to get it to render inline properly.

[cfsievers]

Okay, figured out the formatting:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>PayloadContent</key>
	<array>
		<dict>
			<key>PayloadContent</key>
			<dict>
				<key>corp.sap.privileges</key>
				<dict>
					<key>Forced</key>
					<array>
						<dict>
							<key>mcx_preference_settings</key>
							<dict>
                   				<!-- Defines which local users can request elevation -->
                   				<key>LimitToUser</key>
								<array>
									<string>test1</string>
									<string>test3</string>
								</array>
								<!-- Defines maximum time of elevated permissions, per request, in minutes -->
								<key>ExpirationIntervalMax</key>
								<integer>30</integer>									
							</dict>
						</dict>
					</array>
				</dict>
			</dict>
			<key>PayloadDescription</key>
			<string/>
			<key>PayloadDisplayName</key>
			<string>Privileges configuration</string>
			<key>PayloadEnabled</key>
			<true/>
			<key>PayloadIdentifier</key>
			<string>com.apple.ManagedClient.preferences.36132147-235E-4663-ADA8-2664C67C4DD2</string>
			<key>PayloadOrganization</key>
			<string>SAP SE</string>
			<key>PayloadType</key>
			<string>com.apple.ManagedClient.preferences</string>
			<key>PayloadUUID</key>
			<string>36132147-235E-4663-ADA8-2664C67C4DD2</string>
			<key>PayloadVersion</key>
			<integer>1</integer>
		</dict>
	</array>
	<key>PayloadDescription</key>
	<string>Configures the Privileges app.</string>
	<key>PayloadDisplayName</key>
	<string>Privileges configuration</string>
	<key>PayloadEnabled</key>
	<true/>
	<key>PayloadIdentifier</key>
	<string>CF401A42-35CA-4DA6-9123-5A49C87ECB5A</string>
	<key>PayloadOrganization</key>
	<string>SAP SE</string>
	<key>PayloadRemovalDisallowed</key>
	<true/>
	<key>PayloadScope</key>
	<string>System</string>
	<key>PayloadType</key>
	<string>Configuration</string>
	<key>PayloadUUID</key>
	<string>50870D16-7AAD-478B-BFFE-BED09499F7E0</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
</dict>
</plist>

[cfsievers]

Well, I'm not really sure what to think. I erased the Mac and installed macOS 15.3.
I used the same config profile as was provided here, and verified it was pushed to the Mac.
I logged in as user "test2" and was able to launch Privileges, and no expiration maximum is set (i.e., nothing is greyed out).

[cfsievers]

Using Privileges 2.1 now, FWIW.

[mthielemann]

How does the output of defaults read /Library/Managed\ Preferences/corp.sap.privileges look like?

[mthielemann]

If you use the Upload function in Jamf Pro, your profile must just look like this, because Jamf tried to make it easier for their users:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plist version="1.0">
<dict>
	<key>LimitToUser</key>
	<array>
		<string>test1</string>
		<string>test3</string>
	</array>
	<key>ExpirationIntervalMax</key>
	<integer>30</integer>
</dict>
</plist>

[cfsievers]

For what it's worth, I performed a rudimentary test yesterday to try and determine if perhaps just one of the keys I was testing didn't play nice with others in general.

Just before closing yesterday I clobbered the existing Privileges config profile and created two new ones. The first defined LimitToUser, the second defined ExpirationIntervalMax. Both settings were successfully configured on the endpoint. I then added ReasonRequired to the second profile. All settings were successfully applied to the endpoint.

Obviously this test has nowhere near the number of data points needed to form any conclusions yet, but I mention the test for the sake of providing all the information I can.

I have been using the upload function in Jamf Pro, yes. Since (as I mentioned) I'm cargo-culting code, I've been using the entirety of the XML in the provided examples, and making modifications from there (adding keys and changing key values). So my XML hasn't looked as austere as the sample you just provided. I did notice that Jamf seemed to be discarding/ignoring PayloadDescription values, though it does seem to use provided PayloadDisplayName values.

Based on the last two comments, I'm going to test whether or not the stripped-down XML style makes a difference. I will delete all existing test profiles and upload a barebones profile that uses the original two keys that were tested: LimitToUser and ExpirationIntervalMax. If they are both successfully applied to the endpoint, I'm going to assume Jamf is somehow choking on the other payload information. If they aren't, I'll look at the output of defaults.

If you happen to read this before I can report back, please let me know if I'm making a goof with my assumption/methodology.

[cfsievers]

The stripped-down XML seems to have done the trick; thanks. I love it when apps "help" without telling you (looking at you, Jamf).

[cfsievers]

Indentation is a little wonky here, but it doesn't look like that in my editors, not that it should matter with regards to functionality.