LDAP eDirectory output is random numbers
up vote
0
down vote
favorite
Using Netiq's eDirectory system we have numerous roles that contain AD Groups.
I do not know how this is set up exactly, but the raw input value for the role (nrfEntitlementRef) looks like this:
cn=C10_AD_GroupMembership,cn=C10_AD2008,cn=DriverSet,ou=RESOURCES,o=SYSTEM#0#<ref>
<id/>
<param>GG_PROJECT_MBX_IAM_PROJECT</param>
</ref>
Now when I use Apache Directory Studio (software used to browse the eDirectory) and export this into an XML to import it later it converts it to base64, that's fine I can work with that.
Recently I've been trying to connect to the eDirectory with Powershell, trying to get the same output resulted in the following:
PS: $ldapquery.properties.nrfentitlementref
99
110
61
67
49
48
95
65
68
95
71
114
111
117
112
77
101
109
98
101
114
115
104
105
112
44
99
110
61
67
49
48
95
65
68
50
48
48
56
44
99
110
61
68
114
105
118
101
114
83
101
116
44
111
117
61
82
69
83
79
85
82
67
69
83
44
111
61
83
89
83
84
69
77
35
48
35
60
114
101
102
62
10
9
60
105
100
47
62
10
9
60
112
97
114
97
109
62
71
71
95
80
82
79
74
69
67
84
95
77
66
88
95
73
65
77
95
80
82
79
74
69
67
84
60
47
112
97
114
97
109
62
9
10
60
47
114
101
102
62
10
When I use a .getType() on the parameter it returns:
ResultPropertyValueCollection
It has a length of 141 and looks to be some sort of ASCII-esque encoding but I don't know how I would be able to properly decode it for automation.
powershell character-encoding edirectory
add a comment |
up vote
0
down vote
favorite
Using Netiq's eDirectory system we have numerous roles that contain AD Groups.
I do not know how this is set up exactly, but the raw input value for the role (nrfEntitlementRef) looks like this:
cn=C10_AD_GroupMembership,cn=C10_AD2008,cn=DriverSet,ou=RESOURCES,o=SYSTEM#0#<ref>
<id/>
<param>GG_PROJECT_MBX_IAM_PROJECT</param>
</ref>
Now when I use Apache Directory Studio (software used to browse the eDirectory) and export this into an XML to import it later it converts it to base64, that's fine I can work with that.
Recently I've been trying to connect to the eDirectory with Powershell, trying to get the same output resulted in the following:
PS: $ldapquery.properties.nrfentitlementref
99
110
61
67
49
48
95
65
68
95
71
114
111
117
112
77
101
109
98
101
114
115
104
105
112
44
99
110
61
67
49
48
95
65
68
50
48
48
56
44
99
110
61
68
114
105
118
101
114
83
101
116
44
111
117
61
82
69
83
79
85
82
67
69
83
44
111
61
83
89
83
84
69
77
35
48
35
60
114
101
102
62
10
9
60
105
100
47
62
10
9
60
112
97
114
97
109
62
71
71
95
80
82
79
74
69
67
84
95
77
66
88
95
73
65
77
95
80
82
79
74
69
67
84
60
47
112
97
114
97
109
62
9
10
60
47
114
101
102
62
10
When I use a .getType() on the parameter it returns:
ResultPropertyValueCollection
It has a length of 141 and looks to be some sort of ASCII-esque encoding but I don't know how I would be able to properly decode it for automation.
powershell character-encoding edirectory
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Using Netiq's eDirectory system we have numerous roles that contain AD Groups.
I do not know how this is set up exactly, but the raw input value for the role (nrfEntitlementRef) looks like this:
cn=C10_AD_GroupMembership,cn=C10_AD2008,cn=DriverSet,ou=RESOURCES,o=SYSTEM#0#<ref>
<id/>
<param>GG_PROJECT_MBX_IAM_PROJECT</param>
</ref>
Now when I use Apache Directory Studio (software used to browse the eDirectory) and export this into an XML to import it later it converts it to base64, that's fine I can work with that.
Recently I've been trying to connect to the eDirectory with Powershell, trying to get the same output resulted in the following:
PS: $ldapquery.properties.nrfentitlementref
99
110
61
67
49
48
95
65
68
95
71
114
111
117
112
77
101
109
98
101
114
115
104
105
112
44
99
110
61
67
49
48
95
65
68
50
48
48
56
44
99
110
61
68
114
105
118
101
114
83
101
116
44
111
117
61
82
69
83
79
85
82
67
69
83
44
111
61
83
89
83
84
69
77
35
48
35
60
114
101
102
62
10
9
60
105
100
47
62
10
9
60
112
97
114
97
109
62
71
71
95
80
82
79
74
69
67
84
95
77
66
88
95
73
65
77
95
80
82
79
74
69
67
84
60
47
112
97
114
97
109
62
9
10
60
47
114
101
102
62
10
When I use a .getType() on the parameter it returns:
ResultPropertyValueCollection
It has a length of 141 and looks to be some sort of ASCII-esque encoding but I don't know how I would be able to properly decode it for automation.
powershell character-encoding edirectory
Using Netiq's eDirectory system we have numerous roles that contain AD Groups.
I do not know how this is set up exactly, but the raw input value for the role (nrfEntitlementRef) looks like this:
cn=C10_AD_GroupMembership,cn=C10_AD2008,cn=DriverSet,ou=RESOURCES,o=SYSTEM#0#<ref>
<id/>
<param>GG_PROJECT_MBX_IAM_PROJECT</param>
</ref>
Now when I use Apache Directory Studio (software used to browse the eDirectory) and export this into an XML to import it later it converts it to base64, that's fine I can work with that.
Recently I've been trying to connect to the eDirectory with Powershell, trying to get the same output resulted in the following:
PS: $ldapquery.properties.nrfentitlementref
99
110
61
67
49
48
95
65
68
95
71
114
111
117
112
77
101
109
98
101
114
115
104
105
112
44
99
110
61
67
49
48
95
65
68
50
48
48
56
44
99
110
61
68
114
105
118
101
114
83
101
116
44
111
117
61
82
69
83
79
85
82
67
69
83
44
111
61
83
89
83
84
69
77
35
48
35
60
114
101
102
62
10
9
60
105
100
47
62
10
9
60
112
97
114
97
109
62
71
71
95
80
82
79
74
69
67
84
95
77
66
88
95
73
65
77
95
80
82
79
74
69
67
84
60
47
112
97
114
97
109
62
9
10
60
47
114
101
102
62
10
When I use a .getType() on the parameter it returns:
ResultPropertyValueCollection
It has a length of 141 and looks to be some sort of ASCII-esque encoding but I don't know how I would be able to properly decode it for automation.
powershell character-encoding edirectory
powershell character-encoding edirectory
asked yesterday
Thom Ernst
4419
4419
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
It was actually ASCII, the program I was using to convert it had an error in it which produced unknown characters.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
It was actually ASCII, the program I was using to convert it had an error in it which produced unknown characters.
add a comment |
up vote
0
down vote
It was actually ASCII, the program I was using to convert it had an error in it which produced unknown characters.
add a comment |
up vote
0
down vote
up vote
0
down vote
It was actually ASCII, the program I was using to convert it had an error in it which produced unknown characters.
It was actually ASCII, the program I was using to convert it had an error in it which produced unknown characters.
answered yesterday
Thom Ernst
4419
4419
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53204272%2fldap-edirectory-output-is-random-numbers%23new-answer', 'question_page');
}
);
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password