AnsweredAssumed Answered

Unable to place sentences in new-line in Active directory

Question asked by L . on Apr 10, 2020
Latest reply on Apr 16, 2020 by Subash Chandra Behera

Like • Show 0 Likes0
Comment • 14

Hello,

I'm using "Active directory" connector to update one of the attribute in AD.I'm taking the values from the internal database and placing it in AD attribute.When I execute the query in database results are coming in line-by-line.
But through the connector I'm unable to include the line breaker between sentences even though I'm using "CHR(10)" in query.

Actual output= Location Code = 10
Location Desc. = US
Rank Code = 13
Job Code = 23

Current output to the query:Location Code = 10Location Desc. = USRank Code = 13Job Code = 23

Can we places the values line by line in "Active directory" connector template?

Mostafa Helmy

Apr 14, 2020 8:35 PM

Correct Answer

I was able to reproduce this. I can confirm it is some sort of limitation/defect in the Workflow processing and how it stores values.

I used a very basic WF which selects values into workflow variables then passes them to a provisioning command node calling the AFX Update Account capability. I used this SQL statement as a test:

SELECT
    'CN=Aabel\, Franz,OU=US,OU=vcloud Users,DC=2k8r2-vcloud,DC=local'    AS account,
    '784 Mandan Road'
    || CHR(13)
    || CHR(10)
    || 'Apartment 204'           AS streetaddress
FROM
    dual;

The attribute on AD was not populated with the new line. I did a packet capture and found that apparently AFX isn't sending CR LF. It only sends the LF character (which does get stored in AD but does not constitute to a new line in Windows).

Further digging I check the workflow variables table WP_USER_DATA and found that the workflow only stores the LF character and ignores the CR character for some reason.

I think this should go to RSA Support to confirm if this is a defect or a limitation by design.

See the reply in context

No one else had this question

Outcomes

Pradeep Kadambar

Apr 10, 2020 6:25 PM

Did you try to do the same using an LDAP editor ? Can you share the results of that ?

Actions

L . @ Pradeep Kadambar on Apr 13, 2020 10:33 AM

Hi Pradeep,

I have excuted the powershell command inside the AD server.It's updating attribute with line breaker.But from RSA through the sql queries its not coming.

PowerShell command:

Set-ADUser -Identity "12689" Replace @{info="Location Code = 10 `r`n Location Desc. = New Jersy"}

SQL query:

select (
'Location Code = ' || LOCATION ||CHR(10)|| 'Location Desc. = ' || OFFICE ) as info
from pv_users where employee_id='12689';

I'm passing info in Active directory connector.

Actions

Ian Staines

@ L . on Apr 13, 2020 12:21 PM

Can you rephrase your problem in terms of what aspect of RSA IG&L is not working as expected? What is the result you want and what is the result you are getting?

Actions

Mostafa Helmy

Apr 14, 2020 1:03 PM

Since windows systems use CR LF for new lines (not just LF), perhaps chr(10) alone is not enough.

I haven't tested this, but try adding chr(13) and chr(10) to your string? According to your example, something like this:

select 
  (
    'Location Code = ' || LOCATION || CHR(13) || CHR(10)|| 'Location Desc. = ' || OFFICE
  ) as info 
from 
  pv_users 
where 
  employee_id = '12689';

1 person found this helpful

Actions

L . @ Mostafa Helmy on Apr 14, 2020 5:19 AM

I tried with "|| CHR(13) || CHR(10)||" but no luck.

Actions

Ian Staines

@ L . on Apr 14, 2020 10:52 AM

Perhaps you could do the string manipulation on the PowerShell side? PowerShell is a scripting language.

Actions

Mostafa Helmy

@ L . on Apr 14, 2020 8:35 PM

I was able to reproduce this. I can confirm it is some sort of limitation/defect in the Workflow processing and how it stores values.

I used a very basic WF which selects values into workflow variables then passes them to a provisioning command node calling the AFX Update Account capability. I used this SQL statement as a test:

SELECT
    'CN=Aabel\, Franz,OU=US,OU=vcloud Users,DC=2k8r2-vcloud,DC=local'    AS account,
    '784 Mandan Road'
    || CHR(13)
    || CHR(10)
    || 'Apartment 204'           AS streetaddress
FROM
    dual;

Further digging I check the workflow variables table WP_USER_DATA and found that the workflow only stores the LF character and ignores the CR character for some reason.

I think this should go to RSA Support to confirm if this is a defect or a limitation by design.

1 person found this helpful

Actions

Pradeep Kadambar

Apr 14, 2020 12:59 PM

RSA IGL uses LDAP standards to write to AD. CHR(10) not a valid LDAP construct.

As per LDAP standards, CR (carriage return) and LF (line feed) are recognized constructs.

You can try CR LF in your description field

1 person found this helpful

Actions

Ian Staines

@ Pradeep Kadambar on Apr 14, 2020 2:30 PM

The customer just says they are using an "Active Directory" connector but it is not clear if this is the default IG&L Active Directory LDAP connector, or a custom PowerShell connector. They also mentioned PowerShell so I assumed the latter.

I see the customer has opened an RSA Customer Support case for this so perhaps that is the best place to get the customers full information and solve the issue in context.

Actions

Mostafa Helmy

@ Pradeep Kadambar on Apr 14, 2020 7:09 PM

But CHR(10) is LF (0x0A) and CHR(13) is CR (0x0D) in Oracle, so CHR(13) || CHR(10) should translate into CR LF. I've used this trick before in Oracle but not with AFX.

I believe these characters are being removed somewhere between IGL, AFX and AD LDAP.

Actions

Pradeep Kadambar

@ Mostafa Helmy on Apr 14, 2020 8:28 PM

Agreed, it's best to turn on the DEBUG logging for the Active Directory connector and see the data that is being passed from ACM to AFX and from AFX to AD.

Actions

Subash Chandra Behera

Apr 15, 2020 9:46 AM

Hi Mostafa Helmy, Pradeep Kadambar- Do we have any workaround for this. Got a case where customer reported this issue. Since AFX is truncating the CHR(10), can we report it as a bug?

Actions

Mostafa Helmy

@ Subash Chandra Behera on Apr 15, 2020 9:52 AM

I would recommend logging this as a bug and seeing what the CE team has to say. To be specific, it's a Workflow issue not an AFX issue. The workflow is storing the variable without the CR hence passing the wrong value to AFX.

Actions

Subash Chandra Behera

@ Mostafa Helmy on Apr 16, 2020 6:18 AM

Thanks Mostafa Helmy. An Engineering jira ACM-105001 been created to track this issue.

Actions

14 Replies

Pradeep Kadambar Apr 10, 2020 6:25 PM
Mark Correct
Correct Answer
Did you try to do the same using an LDAP editor ? Can you share the results of that ?
Like • Show 0 Likes0
Actions
- L . @ Pradeep Kadambar on Apr 13, 2020 10:33 AM
  Mark Correct
  Correct Answer
  Hi Pradeep,
  
  I have excuted the powershell command inside the AD server.It's updating attribute with line breaker.But from RSA through the sql queries its not coming.
  
  PowerShell command:
  Set-ADUser -Identity "12689" Replace @{info="Location Code = 10 `r`n Location Desc. = New Jersy"}
  
  SQL query:
  select ( 'Location Code = ' || LOCATION ||CHR(10)|| 'Location Desc. = ' || OFFICE ) as info from pv_users where employee_id='12689';
  I'm passing info in Active directory connector.
  Like • Show 0 Likes0
  Actions
  - Ian Staines @ L . on Apr 13, 2020 12:21 PM
    Mark Correct
    Correct Answer
    Can you rephrase your problem in terms of what aspect of RSA IG&L is not working as expected? What is the result you want and what is the result you are getting?
    Like • Show 0 Likes0
    Actions
Mostafa Helmy Apr 14, 2020 1:03 PM
Mark Correct
Correct Answer
Since windows systems use CR LF for new lines (not just LF), perhaps chr(10) alone is not enough.

I haven't tested this, but try adding chr(13) and chr(10) to your string? According to your example, something like this:
select ( 'Location Code = ' || LOCATION || CHR(13) || CHR(10)|| 'Location Desc. = ' || OFFICE ) as info from pv_users where employee_id = '12689';
1 person found this helpful
Like • Show 1 Like1
Actions
- L . @ Mostafa Helmy on Apr 14, 2020 5:19 AM
  Mark Correct
  Correct Answer
  I tried with "|| CHR(13) || CHR(10)||" but no luck.
  Like • Show 0 Likes0
  Actions
  - Ian Staines @ L . on Apr 14, 2020 10:52 AM
    Mark Correct
    Correct Answer
    Perhaps you could do the string manipulation on the PowerShell side? PowerShell is a scripting language.
    Like • Show 0 Likes0
    Actions
  - Mostafa Helmy @ L . on Apr 14, 2020 8:35 PM
    Unmark Correct
    Correct Answer
    I was able to reproduce this. I can confirm it is some sort of limitation/defect in the Workflow processing and how it stores values.
    
    I used a very basic WF which selects values into workflow variables then passes them to a provisioning command node calling the AFX Update Account capability. I used this SQL statement as a test:
    
    SELECT 'CN=Aabel\, Franz,OU=US,OU=vcloud Users,DC=2k8r2-vcloud,DC=local' AS account, '784 Mandan Road' || CHR(13) || CHR(10) || 'Apartment 204' AS streetaddress FROM dual;
    
    The attribute on AD was not populated with the new line. I did a packet capture and found that apparently AFX isn't sending CR LF. It only sends the LF character (which does get stored in AD but does not constitute to a new line in Windows).
    
    Further digging I check the workflow variables table WP_USER_DATA and found that the workflow only stores the LF character and ignores the CR character for some reason.
    
    I think this should go to RSA Support to confirm if this is a defect or a limitation by design.
    1 person found this helpful
    Like • Show 2 Likes2
    Actions
Pradeep Kadambar Apr 14, 2020 12:59 PM
Mark Correct
Correct Answer
RSA IGL uses LDAP standards to write to AD. CHR(10) not a valid LDAP construct.

As per LDAP standards, CR (carriage return) and LF (line feed) are recognized constructs.

You can try CR LF in your description field

1 person found this helpful
Like • Show 1 Like1
Actions
- Ian Staines @ Pradeep Kadambar on Apr 14, 2020 2:30 PM
  Mark Correct
  Correct Answer
  The customer just says they are using an "Active Directory" connector but it is not clear if this is the default IG&L Active Directory LDAP connector, or a custom PowerShell connector. They also mentioned PowerShell so I assumed the latter.
  
  I see the customer has opened an RSA Customer Support case for this so perhaps that is the best place to get the customers full information and solve the issue in context.
  Like • Show 1 Like1
  Actions
- Mostafa Helmy @ Pradeep Kadambar on Apr 14, 2020 7:09 PM
  Mark Correct
  Correct Answer
  But CHR(10) is LF (0x0A) and CHR(13) is CR (0x0D) in Oracle, so CHR(13) || CHR(10) should translate into CR LF. I've used this trick before in Oracle but not with AFX.
  
  I believe these characters are being removed somewhere between IGL, AFX and AD LDAP.
  Like • Show 0 Likes0
  Actions
  - Pradeep Kadambar @ Mostafa Helmy on Apr 14, 2020 8:28 PM
    Mark Correct
    Correct Answer
    Agreed, it's best to turn on the DEBUG logging for the Active Directory connector and see the data that is being passed from ACM to AFX and from AFX to AD.
    Like • Show 0 Likes0
    Actions
Subash Chandra Behera Apr 15, 2020 9:46 AM
Mark Correct
Correct Answer
Hi Mostafa Helmy, Pradeep Kadambar- Do we have any workaround for this. Got a case where customer reported this issue. Since AFX is truncating the CHR(10), can we report it as a bug?
Like • Show 0 Likes0
Actions
- Mostafa Helmy @ Subash Chandra Behera on Apr 15, 2020 9:52 AM
  Mark Correct
  Correct Answer
  I would recommend logging this as a bug and seeing what the CE team has to say. To be specific, it's a Workflow issue not an AFX issue. The workflow is storing the variable without the CR hence passing the wrong value to AFX.
  Like • Show 0 Likes0
  Actions
  - Subash Chandra Behera @ Mostafa Helmy on Apr 16, 2020 6:18 AM
    Mark Correct
    Correct Answer
    Thanks Mostafa Helmy. An Engineering jira ACM-105001 been created to track this issue.
    Like • Show 0 Likes0
    Actions

Unable to place sentences in new-line in Active directory

Outcomes

Related Content

Recommended Content