AD Driver - service user can't read password files

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
Parents
  • 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.
Reply
  • 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.
Children
  • 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.


  • 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!

  • > 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.



  • 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
  • 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.