[PATCH] s4-drs: Delete RODC filtered attributes from objects

[Anatoliy Atanasov]

> Hi Fernando,
> 
>  > In this patch, if there is an update on an attributeSchema object such
>  > that it become part of the RODC filtered set, then we delete the
>  > values of that attribute from any object which contains it.
> 
> I think this isn't the right approach.
> 
> When a DC is a RODC, then when it replicates from another DC, it gets
> a subset of the attributes. So there is no need for it to delete
> attributes. The reason it gets a subset is that a RODC is not trusted
> to hold all attributes, so they will never be sent by the other DC.
> 
> I think these are the logical changes we need to support RODC
> operation:
> 
>  1) when we are a RODC we should refuse changes to the directory. This
>  would happen in repl_meta_data.c module. I think the logical place
>  for this check is in replmd_update_rpmd_element()
I am on it, I was wondering where this check should happen, I though about ldap_server/ldap_backend.c because as far as I know the LDAP request goes thru there first.
 
>  2) when we are sending changes as a DRS server, and the recipient is
>  a RODC, then we should filter the attributes that we send. That
>  should happen in get_nc_changes_build_object() I think (via a helper
>  function).
Fernando, regarding the filtered attribute set this task is closer to what you investigated so far, you can try and solve this.
 
>  3) in both cases (client and server) we need to make sure we set the
>  flags to say that we are a RODC. Look for all places we set the
>  DRSUAPI_DRS_WRIT_REP flag, and see if they need to change.
I changed that while doing a RODC join, the check if we are RODC is samdb_rodc.
 
> There is also the problem of request forwarding when we are a RODC. A
> RODC usually does not have the passwords of users (although the admin
> may allow it to have the passwords of some users). So when it gets a
> login request, it has to forward it to a DC that does have the
> passwords. I haven't looked into how that works yet, but I suspect it
> will be the trickiest part of the changes for RODC support.
I read about that and the solution for this is called credential caching, I described this task in: http://wiki.samba.org/index.php/Samba4_DRS_TODO_List#Support_RODC

> Cheers, Tridge

Regards,
Anatoliy