Multiple mail aliases wont work

[dmraj]

Hi Jarle, We would like to request an enhancement to handle multi-valued Other type email attributes. Currently the type converting process will fail if there is more than one address supplied for Other types. However, this is where aliases are populated for users with multiple addresses.

The skipTypeConvert option will successfully allow all email addresses to be processed, however, then we are unable to properly pull the work type address out into a separate attribute on our LDAP backend. We need to be able to map the Work type address to one attribute, and the Other type addresses to a different attribute.

Config (only the required parts):

"skipTypeConvert": true,
"mailacceptinggeneralid": { "mapTo": "emails.value", "type": "array" }, "maildrop": { "mapTo": "emails.0['value']", "type": "string"

Input:

'{"schemas":["urn:ietf:params:scim:schemas:core:2.0:User","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],"externalId":"scott_test1","userName":"scott_test1@raj.onmicrosoft.com","active":true,"displayName":"Scott Test1","emails":[{"primary":true,"type":"work","value":"primary_address@domain.tld"},{"primary":false,"type":"other","value":"alias4@domain.tld"},{"primary":false,"type":"other","value":"alias3@domain.tld"},{"primary":false,"type":"other","value":"alias2@domain.tld"},{"primary":false,"type":"other","value":"alias1@domain.tld"}],"meta":{"resourceType":"User"},"name":{"formatted":"Scott Test1","familyName":"Test1","givenName":"Scott"}}

Output:

emails":[{"primary":true,"type":"work","value":"mailto:primary_address@domain.tld},{"primary":false,"type":"other","value":"mailto:alias4@domain.tld"},{"primary":false,"type":"other","value":"mailto:alias3@domain.tld"},{"primary":false,"type":"other","value":"mailto:alias2@domain.tld"},{"primary":false,"type":"other","value":"mailto:"mailto:mailto:alias1@domain.tld"}]

LDAP output:

mailacceptinggeneralid: mailto:alias1@domain.tld mailacceptinggeneralid: mailto:alias2@domain.tld mailacceptinggeneralid: mailto:alias3@domain.tld mailacceptinggeneralid: mailto:alias4@domain.tld mailacceptinggeneralid: mailto:primary_address@domain.tld

Expected LDAP output:

mailacceptinggeneralid: mailto:alias1@domain.tld mailacceptinggeneralid: mailto:alias2@domain.tld mailacceptinggeneralid: mailto:alias3@domain.tld mailacceptinggeneralid: mailto:alias4@domain.tld maildrop: mailto:primary_address@domain.tld

maildrop is not processed or submitted. EIther need type convert improved so it can be accessed with emails.work.value, or guidance on how to retrieve it properly with skipTypeConvert true

Thanks Raj DM

[jelhub]

Assume you are using Entra ID as IdP and plugin-ldap for your directory provisioning?

Default "typeConvert" is meant for simplifying multivalue attributes like emails, addresses, +++ and can be combined with endpointMapper. For these standard SCIM multivalue attributes there will be one-to-one mapping, not one-to-many Using "skipTypeConvert=true" gives raw data and full flexibility (not supported by endpointMapper)

You have two alternatives:

1) Use "skipTypeConvert=true" and do your own mappings for multivalue attributes (not using endpointMapper for these)

2) Use default "skipTypeConvert=false". In Entra ID you then define a new target custom multi-value attribute for the source attribute otherMails (do not link this one to target attribute emails). e.g.

Source attribute = otherMails
Target attribute = otherMails (must be multi-value)

Now we are using a none standard SCIM multi-value attribute and scimgateway will not do any "typeConvert" on this attribute.

In the plugin-ldap configuration, this new attribute will be mapped to "mailacceptinggeneralid" using type=array and the "maildrop" attribute should be using standard emails/work attribute

"map": {
  "user" {
    "mailacceptinggeneralid": {
      "mapTo": "otherMails.value",
      "type": "array"
    },
    "maildrop": {
      "mapTo": "emails.work.value",
      "type": "string"
    },

[jelhub]

FYI, I have updated above

Old: Target attribute = otherMails[type eq "custom"].value

New: Target attribute = otherMails (must be multi-value)

When not typeConverted, endpointMapper do not know the type "custom" when converting back to origin.

[inchandru]

Hai @jelhub ,

I got stuck with the exact same issue and I followed the second method (using default "skipTypeConvert=false".In Entra ID you...) and completed all the steps, but it didn't resolve the issue.

Steps I followed:

I created a new OtherMails Target Attribute using below steps.

• Mircrosoft Entra ID --> provisoning --> Attribute mapping --> Show Advanced options ---> Edit attribute list for customappsso --> otherMails(created new multiple value attribute) --> save

Target Attribute SS

• provisoning --> Attribute mapping --> Add New Mapping --> Source Attribute(otherMails) --> target Attribute(otherMails) --> OK --> save

Mappings SS:

Provisioning Errors from Entra ID

In the "Import User" section, I am able to view the "otherMails" field, but I cannot see it in the "Perform Action" section. Please find the SS attached.

SCIM Gateway Error:

2024-05-21T04:28:08.696 plugin-ldap error: scimgateway[plugin-ldap] 8ms ::ffff:10.10.10.10 token GET http://scim.example.com/Users/uid%253Dgautham%2540chandruv.onmicrosoft.c om%252Cou%253DPeople%252Cdc%253Dchandru%252Cdc%253Dcom Inbound = {} Outbound = {"statusCode":404,"statusMessage":"Not Found","body":{"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"] ,"scimType":"invalidSyntax","detail":"scimgateway[plugin-ldap] getUsers error: No Such Object error","status":404}}

Thanks Chandru

[jelhub]

I think the problem you now see is another issue. Entra tries to lookup an id that that does not exist becuase id is not correctly URL encoded.

id: uid=gautham.chandruv.onmicrosoft.com,ou=People,dc=chandru,dc=com

should have been encoded to: uid%3Dgautham.chandruv.onmicrosoft.com%2Cou%3DPeople%2Cdc%3Dchandru%2Cdc%3Dcom

your log shows: uid%253Dgautham%2540chandruv.onmicrosoft.com%252Cou%253DPeople%252Cdc%253Dchandru%252Cdc%253Dcom

So, you have got an additional "25" code. This probably means there have been a double encoding of the id previously returned by createUser, modifyUser or getUser by userName.

Are you using the original default plugin-ldap or a modified one? Has it been working before?

[inchandru]

Hi @jelhub ,

Yes, I'm using default config, the only config I modified is config/plugin-ldap.json. I installed scimgateway using npm i scimgateway. Has it been working before? --> Yes, it was working..

Thanks

[jelhub]

"getUsers error: No Such Object error","status":404 This message tells that user does not exist. This is correct if user do not exist, but incorrect if user does exist.

Does user exist? If yes, you should verify the same request using a browser or rest client

1) - double encoded, same as what have been logged: http://scim.example.com/Users/uid%253Dgautham%2540chandruv.onmicrosoft.com%252Cou%253DPeople%252Cdc%253Dchandru%252Cdc%253Dcom

2) - standard encoding: http://scim.example.com/Users/uid%3Dgautham.chandruv.onmicrosoft.com%2Cou%3DPeople%2Cdc%3Dchandru%2Cdc%3Dcom

[inchandru]

Hi @jelhub

Thank you for your quick response.

The user does not exist, and both the double encoded and standard encoding urls are throwing an error of "scimType": "invalidSyntax".

Here is the Ref:

Thanks

[inchandru]

Hi @jelhub ,

Just wanted to let you know that I fixed the problem with the double encoded URLs by reinstalling scimgateway. And guess what? Step 2(Use default "skipTypeConvert=false". In Entra ID you then...) worked like a charm for adding multiple mailAlternativeAddress.

But now I have a new issue. It's not really an issue, but for some reason, the Entra ID is not sending the otherMails attribute in the first attempt, but it does on the second attempt.

First attempt SS:

Second attempt SS:

Thank you

[jelhub]

Gateway encodes id that is sent back to IdP (in this case Entra ID). The reason for doing this is because some IdP's wrongly do not encode URLs used in SCIM communication. Entra do correct urlencoding and that is why id will become double encoded.

Gateway decodes all incoming URLs and in addition the same will also be done by plugin-ldap. This means double encoded id will not cause any problems.

There seems to be a bug in Entra ID related to self-defined target attributes, and as you mention, these attributes are not included in create user. Also, Entra seems to ignore content retrieved in these attributes resulting in Entra applying the same on every sync.

You may take this problem with Microsoft.

Workaround seems to be using an existing target attribute, but setting multi-value does not work.

I have now uploaded a new version of gateway v4.5.3 that includes:

• endpointMapper supporting comma separated string to be converted to array

Please use this latest version and do the following:

Entra ID configuration:

1. remove what you did previously regarding otherMails
2. also remove from Entra attributes not used by your plugin (ref. mapper configuration), else these will be included on every sync - ref. your last screenshot

3. new configuration to be used:

   Expression = Join(",", Split([otherMails], ","))
   Target attribute = locale (or some other existing attribute, do not set multi-value)

   plugin-ldap mapper configuration to be used:

   "map": { "user": { "mailacceptinggeneralid": { "mapTo": "locale", "type": "array", "typeInbound": "string" }, ...

[inchandru]

Hi @jelhub

Thanks a lot for the solution! I'm happy to report that the above configs are working perfectly. 👍

Regards, Chandru