Environment
Novell Identity Manager Identity Manager 3.0
Novell Identity Manager Identity Manager 3.5
Novell Identity Manager Driver- Active Directory Driver
Novell Identity Manager Nsure Identity Manager 2.0
Novell Identity Manager Identity Manager 3.5
Novell Identity Manager Driver- Active Directory Driver
Novell Identity Manager Nsure Identity Manager 2.0
Situation
In many cases applications running on a server can authenticate
with system credentials using a local system account. This
allows the application to run with system credentials without
specifying those credentials in any files, across any wires, or in
any other way except via system calls made to the server.
Resolution
LSA access for Identity Manager (with the Remote Loader or Engine
on the domain controller (DC)) is not supported. Username and
password credentials must always be specified for a driver to have
the ability to reliably authenticate to Active Directory.
Doing otherwise may work at times but it is not tested or verified
to work in all cases. Encryption of all traffic using SSL
makes this option safe and should be used for all connections that
take place over a network.
While the Authentication ID and password are required the Authentication Context is not. That field, the DNS name of a DC, is only required when the Remote Loader is not running on a DC locally but instead connects via LDAP. An implementation with the Remote Loader physically on the DC prevents points of failure, minimizes connections which could be intercepted by an attacker and keeps the utilization of the DC to a minimum. Therefore this is the recommended approach.
While the Authentication ID and password are required the Authentication Context is not. That field, the DNS name of a DC, is only required when the Remote Loader is not running on a DC locally but instead connects via LDAP. An implementation with the Remote Loader physically on the DC prevents points of failure, minimizes connections which could be intercepted by an attacker and keeps the utilization of the DC to a minimum. Therefore this is the recommended approach.
Additional Information
The PassSync filters depend upon the Windows Remote Registry
service and other Windows RPC type stuff in order to operate, even
when working with a filter that is installed on the same machine as
the driver is running.
This is where you run into trouble with the LOCAL SYSTEM principal. SYSTEM is privileged to everything on a local machine, however, when accessing network resources the
story is different. In the pre-Windows 2000 days, SYSTEM had no privilege on the network (used so called "null sessions", which is why you need to enable all of the pre-Windows 2000 anonymous enumeration functionality if you are in a mixed environment with NT4 servers in a Windows 2000 domain.)
Windows 2000 changed this slightly and in a Windows 2000/2003 environment, SYSTEM accesses network resources using the privileges of the computer object representing that machine in AD. Unless assigned special permissions, this normally translates into the same privileges of a normal domain user account.
When running on a Domain Controller things get slightly more interesting. Since all local SAM accounts are moved into AD on domain controllers, there is no distinction between local and AD principals on DCs. On a domain controller, SYSTEM has full access to the directory.
Leaving the Authentication ID blank in the driver config, the driver runs in the same security context of the DHost or Remote Loader process running it, i.e. SYSTEM. Since this is on a DC, that was sufficient to obtain full access to AD but not for PassSync since this depends on RPC. For that, the driver needs credentials with appropriate rights to the machines running the filter.
This is where you run into trouble with the LOCAL SYSTEM principal. SYSTEM is privileged to everything on a local machine, however, when accessing network resources the
story is different. In the pre-Windows 2000 days, SYSTEM had no privilege on the network (used so called "null sessions", which is why you need to enable all of the pre-Windows 2000 anonymous enumeration functionality if you are in a mixed environment with NT4 servers in a Windows 2000 domain.)
Windows 2000 changed this slightly and in a Windows 2000/2003 environment, SYSTEM accesses network resources using the privileges of the computer object representing that machine in AD. Unless assigned special permissions, this normally translates into the same privileges of a normal domain user account.
When running on a Domain Controller things get slightly more interesting. Since all local SAM accounts are moved into AD on domain controllers, there is no distinction between local and AD principals on DCs. On a domain controller, SYSTEM has full access to the directory.
Leaving the Authentication ID blank in the driver config, the driver runs in the same security context of the DHost or Remote Loader process running it, i.e. SYSTEM. Since this is on a DC, that was sufficient to obtain full access to AD but not for PassSync since this depends on RPC. For that, the driver needs credentials with appropriate rights to the machines running the filter.