AD password sync issue

I have an issue with my IDM environment where passwords changed in MAD
are only synchronized to the ID vault when they are changed from the DC
that's hosting the remote loader.

System:
IDM engine version 4.6.3 running on RHEL 7
MAD Domain consists of eight Windows Server 2016 systems
DC-VP08 houses the RL
Remote loader version 4.6.3
ADDriver.DLL version 4.0.2.1
PWFILTER.DLL
Parents
  • Following up: it looks like a firewall issue. When I disabled the
    Windows firewall on the RL server, password changes came through fine.

    Since RPC uses dynamic ports, should I enable inbound connections to the
    RL server on any port from any domain controller?


  • On 04/09/2019 01:00 PM, 6423241 wrote:
    > Following up: it looks like a firewall issue. When I disabled the Windows
    > firewall on the RL server, password changes came through fine.
    >
    > Since RPC uses dynamic ports, should I enable inbound connections to the
    > RL server on any port from any domain controller?


    You can also set a static port, if you'd like, though almost nobody does.
    I presume that is because microsoft active directory (MAD) or windows
    admins have found a way to allow RPC stuff to work otherwise. That's my
    optimistic view; in reality I worry that people just disable firewalls
    altogether by default, even on better platforms like Linux, in which case
    the problem also goes away.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • On 4/9/2019 15:58, ab wrote:
    > On 04/09/2019 01:00 PM, 6423241 wrote:
    >> Following up: it looks like a firewall issue. When I disabled the Windows
    >> firewall on the RL server, password changes came through fine.
    >>
    >> Since RPC uses dynamic ports, should I enable inbound connections to the
    >> RL server on any port from any domain controller?

    >
    > You can also set a static port, if you'd like, though almost nobody does.
    > I presume that is because microsoft active directory (MAD) or windows
    > admins have found a way to allow RPC stuff to work otherwise. That's my
    > optimistic view; in reality I worry that people just disable firewalls
    > altogether by default, even on better platforms like Linux, in which case
    > the problem also goes away.
    >


    I discussed this with our MAD architect (heh) and he strongly prefers
    configuring a static port instead of permitting any traffic over any
    port provided it's coming from a DC in the same domain. I tried this in
    test. I chose an unassigned user port and used netstat to verify that
    the system isn't using it. I then created a firewall exception that
    permits inbound connections over that port and configured the password
    filters to use it.

    Result: no change. A password change only syncs when you are connected
    to the DC that's holding the RL. If I disable the Windows firewall
    altogether, it works normally. Since disabling the firewall is not a
    viable option, I'm continuing to tinker.





  • >
    > Result: no change. A password change only syncs when you are connected
    > to the DC that's holding the RL. If I disable the Windows firewall
    > altogether, it works normally.  Since disabling the firewall is not a
    > viable option, I'm continuing to tinker.
    >


    According to the firewall log, the password filter is still using
    dynamic ports even though I've told it to use a static port.

    ---------------------------------------------------------------------------
    #Fields: date time action protocol src-ip dst-ip src-port dst-port size
    tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path




    2019-04-10 16:05:51 DROP TCP 10.80.5.240 10.80.5.239 58466 55924 52 S
    3633176900 0 8192 - - - RECEIVE
    ----------------------------------------------------------------------------

    This was after removing and reinstalling the filter. I checked the
    registry, and under HKLM\Software\Novell\PwFilter I see Port =
    0x0000bfcc (49100).

    Am I missing something, or is this a bug?












  • At this point I might be talking to myself, but just in case anyone is
    following along:

    My workaround was to configure a firewall rule on the RL server which
    allows traffic to "RPC Dynamic Ports" from ports 49152-65535, provided
    the source IP is one of the other DCs. While this works, I would still
    like to know why PWfilter won't use a static port when I tell it to do
    so. My manager wants me to log a support call to get an answer, but I'm
    holding off for a bit in case someone here has any suggestions.

    Thanks

Reply


  • At this point I might be talking to myself, but just in case anyone is
    following along:

    My workaround was to configure a firewall rule on the RL server which
    allows traffic to "RPC Dynamic Ports" from ports 49152-65535, provided
    the source IP is one of the other DCs. While this works, I would still
    like to know why PWfilter won't use a static port when I tell it to do
    so. My manager wants me to log a support call to get an answer, but I'm
    holding off for a bit in case someone here has any suggestions.

    Thanks

Children
  • On 04/11/2019 12:03 PM, 6423241 wrote:
    >
    > At this point I might be talking to myself, but just in case anyone is
    > following along:


    Not likely; lots of lurkers.

    > My workaround was to configure a firewall rule on the RL server which
    > allows traffic to "RPC Dynamic Ports" from ports 49152-65535, provided the
    > source IP is one of the other DCs. While this works, I would still like to
    > know why PWfilter won't use a static port when I tell it to do so. My
    > manager wants me to log a support call to get an answer, but I'm holding
    > off for a bit in case someone here has any suggestions.


    Is it safe to assume you restarted the DCs after changing the setting on
    them to use a static port?

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • ab,
    >
    >> My workaround was to configure a firewall rule on the RL server which
    >> allows traffic to "RPC Dynamic Ports" from ports 49152-65535, provided the
    >> source IP is one of the other DCs. While this works, I would still like to
    >> know why PWfilter won't use a static port when I tell it to do so. My
    >> manager wants me to log a support call to get an answer, but I'm holding
    >> off for a bit in case someone here has any suggestions.

    >



    > Is it safe to assume you restarted the DCs after changing the setting on
    > them to use a static port?
    >


    Yes. I even tried removing the filter, rebooting, then adding the filter
    back and rebooting again.



  • Well I'm not sure then; sure, open a ticket, though other than fixing it
    in principle I'm not sure what the big deal is about RPC working on many
    ports rather than one. If you have software on a DC that can use RPC,
    authenticate to the RL box, and cause a problem, that's called a virus,
    and since the virus is on a DC, it's likely going to do more interesting
    things locally than it ever will on a Remote Loader box.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • ab,

    > Well I'm not sure then; sure, open a ticket, though other than fixing it
    > in principle I'm not sure what the big deal is about RPC working on many
    > ports rather than one. If you have software on a DC that can use RPC,
    > authenticate to the RL box, and cause a problem, that's called a virus,
    > and since the virus is on a DC, it's likely going to do more interesting
    > things locally than it ever will on a Remote Loader box.



    I tend to agree with you. As long as it's restricted to only RPC ports
    and only traffic from other DCs, I don't see a problem. The domain admin
    feels otherwise and my manager agrees with him. Oh well, it's not like
    the cost of the support incident will come out of my pay.

    Thanks