AD Driver - service user can't read password files

[Zygomax]

We have an AD Driver that is primarily a Publisher of info and passwords from AD to eDir. The Driver is running as a Remote Loader service on a Win2008 box, so a Win2016 box has been added to the domain as a member server, not a domain controller (yet).

The Driver service needs to log in as a domain user account rather than Local System to have the proper rights to AD. This is working fine on Win2008. However, on Win2016, when using the same service user, starting the service fails with this error: "Remote loader password and driver object password must be set".

The Driver is installed to C:\Novell\RemoteLoader. I looked in that directory and the files dxicert.pem and dxipkey.pem are present, which I assume are used for the passwords. I therefore believe the service account can't access this directory (or the specific files) due to rights--if the Driver is set to be Local System, it starts normally.

I've compared the Local System Policy permissions between Win2008 and Win2016 and haven't found anything obvious. The service user has the Log On As a Service permission.

Any suggestions?

eDirectory: 8.8.8 Latest SP
IDM: 4.6.2
AD Driver: 4.0.3.0 (64-bit)
Windows 2016 Data Center

Thanks!
Sam

[Zygomax]

PS I'm listed as a Micro Focus Employee but am actually a contingent worker--this question is for my "day job" organization.

Sam

[geoffc]

On 10/24/2018 8:44 AM, Zygomax wrote:
>
> PS I'm listed as a Micro Focus Employee but am actually a contingent
> worker--this question is for my "day job" organization.

Damn uni folk. How is life down there? We prefer you in your support
role for the drivers you support. Glad to help when we can. 🙂

[dgersic]

Zygomax;2489382 wrote:
We have an AD Driver that is primarily a Publisher of info and passwords from AD to eDir. The Driver is running as a Remote Loader service on a Win2008 box, so a Win2016 box has been added to the domain as a member server, not a domain controller (yet).

The Driver service needs to log in as a domain user account rather than Local System to have the proper rights to AD. This is working fine on Win2008. However, on Win2016, when using the same service user, starting the service fails with this error: "Remote loader password and driver object password must be set".

The Driver is installed to C:\Novell\RemoteLoader. I looked in that directory and the files dxicert.pem and dxipkey.pem are present, which I assume are used for the passwords. I therefore believe the service account can't access this directory (or the specific files) due to rights--if the Driver is set to be Local System, it starts normally.

I've compared the Local System Policy permissions between Win2008 and Win2016 and haven't found anything obvious. The service user has the Log On As a Service permission.

Any suggestions?

eDirectory: 8.8.8 Latest SP
IDM: 4.6.2
AD Driver: 4.0.3.0 (64-bit)
Windows 2016 Data Center

Thanks!
Sam

The *.pem files are certificates, not passwords.

On Windows, you need the remote loader applet thing. Find the remote loader instance in there, and set the driver object and remote loader passwords. Then start the remote loader.

[geoffc]

On 10/24/2018 9:24 AM, dgersic wrote:
>
> Zygomax;2489382 Wrote:
>> We have an AD Driver that is primarily a Publisher of info and passwords
>> from AD to eDir. The Driver is running as a Remote Loader service on a
>> Win2008 box, so a Win2016 box has been added to the domain as a member
>> server, not a domain controller (yet).
>>
>> The Driver service needs to log in as a domain user account rather than
>> Local System to have the proper rights to AD. This is working fine on
>> Win2008. However, on Win2016, when using the same service user, starting
>> the service fails with this error: "Remote loader password and driver
>> object password must be set".
>>
>> The Driver is installed to C:\Novell\RemoteLoader. I looked in that
>> directory and the files dxicert.pem and dxipkey.pem are present, which I
>> assume are used for the passwords. I therefore believe the service
>> account can't access this directory (or the specific files) due to
>> rights--if the Driver is set to be Local System, it starts normally.
>>
>> I've compared the Local System Policy permissions between Win2008 and
>> Win2016 and haven't found anything obvious. The service user has the Log
>> On As a Service permission.
>>
>> Any suggestions?
>>
>> eDirectory: 8.8.8 Latest SP
>> IDM: 4.6.2
>> AD Driver: 4.0.3.0 (64-bit)
>> Windows 2016 Data Center
>>
>> Thanks!
>> Sam
>
> The *.pem files are certificates, not passwords.
>
> On Windows, you need the remote loader applet thing. Find the remote
> loader instance in there, and set the driver object and remote loader
> passwords. Then start the remote loader.

The .conf file also seems to be mirrored in thee registry, and I am
unclear which one is actually used in real life.

Remember when using the Rlconsole.exe run as adminstrator else you may
not be able to free/reuse the port.

[Zygomax]

It looks like passwords are now in the registry under HKLM\Software\Novell\DirXML Remote Loader\Command port NNNN.

I've reproduced the issue on a dev VM with RL 4.6.1 on it. On the other hand, we have a prod driver in another domain that is running fine (4.6.2).

This may be from a Windows update as I haven't seen this before.

I'll update the dev VM to 4.6.3 and see what happens.

Thanks,
Sam

PS I'm doing fine, Geoff. I'll be even better when I figure this out!

[geoffc]

> PS I'm doing fine, Geoff. I'll be even better when I figure this out!

Not seen any issues you can help us with here of late, but always glad
to have you here.

[Zygomax]

OK, I had my wires crossed on this. The service should log on as Local System--the AD service user is specified in the Driver Config. So things are working now.

Thanks for the help though!
Sam

[geoffc]

On 10/25/2018 12:44 PM, Zygomax wrote:
>
> OK, I had my wires crossed on this. The service should log on as Local
> System--the AD service user is specified in the Driver Config. So things
> are working now.

That makes sense.

The RL service itself, runs as Local System. This runs a Java process
that auths to AD via the user/pass in Driver config.

It MAY call out to PowerShell, which is passed to a second service, who
must be logged in as a user with permissions to make the PS commands.

Slightly confusing. 3 logins at least possible.

[dgersic]

Zygomax;2489382 wrote:
We have an AD Driver that is primarily a Publisher of info and passwords from AD to eDir. The Driver is running as a Remote Loader service on a Win2008 box, so a Win2016 box has been added to the domain as a member server, not a domain controller (yet).

The Driver service needs to log in as a domain user account rather than Local System to have the proper rights to AD. This is working fine on Win2008. However, on Win2016, when using the same service user, starting the service fails with this error: "Remote loader password and driver object password must be set".

The Driver is installed to C:\Novell\RemoteLoader. I looked in that directory and the files dxicert.pem and dxipkey.pem are present, which I assume are used for the passwords. I therefore believe the service account can't access this directory (or the specific files) due to rights--if the Driver is set to be Local System, it starts normally.

I've compared the Local System Policy permissions between Win2008 and Win2016 and haven't found anything obvious. The service user has the Log On As a Service permission.

Any suggestions?

eDirectory: 8.8.8 Latest SP
IDM: 4.6.2
AD Driver: 4.0.3.0 (64-bit)
Windows 2016 Data Center

Thanks!
Sam

And if you really want to know how this works, there's this epic bit of fun I had back in 2014 figuring out why I suddenly couldn't configure a working remote loader.

https://forums.novell.com/showthread.php/485016-RemoteLoaderSvc-exe-%28-Net-Remote-Loader%29-loads-but-doesn-t-work?p=2438567#post2438567

I wonder if those bugs ever got fixed.

Bugzilla #898824 and #899043.

[geoffc]

> The Driver is installed to C:\Novell\RemoteLoader. I looked in that
> directory and the files dxicert.pem and dxipkey.pem are present, which I
> assume are used for the passwords. I therefore believe the service

In a normal driver, the password files are dlXXXX and lpdXXXX where XXXX
is hex value of the Command port.