SAP GRC Valid From problem

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

I am having an issue with deactivating an account in SAP GRC. When I send the disabled, the current date is automatically added to the Valid From attribute. However, this is not the behavior I need; I want to keep the original date of the account in the Valid From attribute and not have it replaced by the current date when the request is sent.

I have tried several alternatives without success:
For example, I configured the provisioning policies as indicated in the documentation, using a list with the systems to deactivate and their validation dates (validFrom), such as SystemA with the desired date.

I also tried modifying the updateValidFrom attribute in the source, testing both true and false values, but neither option solved the problem.

My goal is to always keep the original date (for the Valid From attribute) that the account has or, alternatively, send the startDate of the identity, trying to preserve the existing validFrom.

Currently, the connector is sending the date of the request for the Valid From field, which causes an issue.

I am attaching an example of the XML generated in the VAs. It appears that the XML is correctly sent as shown; however, SAP GRC adds the date when the deactivation request was made to the Valid From attribute. I consulted with the client, and they informed me that they successfully performed a test by sending an XML with a similar format to this one, and the system accepted it without any issues.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:sap-com:document:sap:soap:functions:mc-style">
  <soapenv:Header/>
  <soapenv:Body>
    <urn:GracIdmUsrAccsReqServices>
      <RequestHeaderData>
        <Reqtype>024</Reqtype>
        <Priority>010</Priority>
        <ReqInitSystem>NEQCLNT500</ReqInitSystem>
        <Requestorid>IDMSAILPOINT</Requestorid>
        <Email>lherrera@assertiva.biz</Email>
        <RequestReason>Requester comments are not present. Disable user request from IdentityNOW</RequestReason>
        <Bproc>basis</Bproc>
      </RequestHeaderData>
      <RequestedLineItem>
        <item>
          <ItemName>BIQCLNT400</ItemName>
          <Connector>BIQCLNT400</Connector>
          <ProvItemType>SYS</ProvItemType>
          <ValidFrom>20250428</ValidFrom>
          <ValidTo>20250515</ValidTo>
          <ProvAction>002</ProvAction>
        </item>
        <item>
          <ItemName>NEQCLNT500</ItemName>
          <Connector>NEQCLNT500</Connector>
          <ProvItemType>SYS</ProvItemType>
          <ValidFrom>20250428</ValidFrom>
          <ValidTo>20250515</ValidTo>
          <ProvAction>002</ProvAction>
        </item>
      </RequestedLineItem>
      <UserGroup>
        <item>
          <UserGroup>ELIMINADOS</UserGroup>
          <UserGroupDesc>LOGON-NEQCLNT500</UserGroupDesc>
        </item>
        <item>
          <UserGroup>ELIMINADOS</UserGroup>
          <UserGroupDesc>LOGON-BIQCLNT400</UserGroupDesc>
        </item>
        <item>
          <UserGroup>ELIMINADOS</UserGroup>
          <UserGroupDesc>LOGON-ARIBACIG2</UserGroupDesc>
        </item>
      </UserGroup>
      <UserInfo>
        <item>
          <SncName>++</SncName>
          <Company>Ecopetrol S.A.</Company>
          <Email>Jhoyner.navarroa@tivit.com</Email>
          <Emptype>1</Emptype>
          <Costcenter>Gerencia Judicial  y Extrajudicial</Costcenter>
          <Lname>Member Torres</Lname>
          <Userid>34267</Userid>
          <UnsecSnc>" "</UnsecSnc>
          <Fname>Yuly Prueba</Fname>
          <UserGroup>LOGON-ELIMINADOS</UserGroup>
          <UserGroup>LOGON-ELIMINADOS</UserGroup>
          <UserGroup>LOGON-ELIMINADOS</UserGroup>
        </item>
      </UserInfo>
    </urn:GracIdmUsrAccsReqServices>
  </soapenv:Body>
</soapenv:Envelope>

Any idea what might be happening? Has anyone experienced a similar issue?

2

Have you tried modifying them back using before provisioning rule? I remember seeing some post around this issue in the past too. You should reach to SailPoint support.

3

At the moment, using a ‘Before Provisioning’ rule isn’t an option. As far as I understand, it should be possible to implement this without one. I will escalate this to Sailpoint support.

4

if possible, share the updates whenever you have the workaround or fix for this issue.

5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.