----- Original Message -----
On Tue, Jun 17, 2014 at 04:44:20PM -0400, Yassir Elley wrote:
>
>
> ----- Original Message -----
> >
> >
> > ----- Original Message -----
> > > On Sun, Jun 15, 2014 at 07:08:55PM -0400, Yassir Elley wrote:
> > > >
> > > >
> > > > * You suggested using the name of the DC that SSSD is currently
> > > > connected
> > > > to in the smb uri (rather than the domain.name, which will require
> > > > libsmbclient to perform a DNS resolution). Is there an easy way to
> > > > get
> > > > the
> > > > name of the DC that SSSD is currently connected to? I am having
> > > > trouble
> > > > finding it.
> > > >
> > >
> > > In struct ad_gpo_access_state you have a member struct sdap_id_conn_ctx
> > > *conn. conn->service->uri is the LDAP uri for the current
connection.
> > > You can use calls from OpenLDAP or ldb to split it into components,
> > > picj
> > > the hostname and create the smb uri.
> > >
> > > In general the uri should always be available since you read the GPO
> > > data from LDAP before doing the smb operations. Nevertheless you can
> > > call be_resolve_server_send() to make sure it is set, see e.g.
> > > auth_get_server() how to use it.
> > >
> > > HTH
> > >
> > > bye,
> > > Sumit
> > > _______________________________________________
> > > sssd-devel mailing list
> > > sssd-devel(a)lists.fedorahosted.org
> > >
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> > >
> >
> > I have attached a revised patch that modifies the smb uri to use the
> > server
> > name rather than the domain name.
> >
> > Thanks,
> > Yassir.
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel(a)lists.fedorahosted.org
> >
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> >
>
> Oops. Forgot to attach the patch.
>
> Yassir.
Thank you, the patch is working as expected and now uses the hostname to
connect to the DC. But please use e.g. ldap_url_parse() from OpenLDAP to
split the url and take the hostname from the lud_host member of typedef
struct ldap_url_desc. The LDAP url can contain port numbers which would
currently cause troubles with your scheme.
As a general comment, please try to split your patches into smaller
units. This would help to review them especially to compare multiple
versions of a patch.
I thought you had previously indicated a preference for a single patch (with the
understanding that this makes it more difficult for the reviewer). Perhaps I
misunderstood. In any case, I have attached two patches to this email: the previous patch,
and a new patch to address your comment about using ldap_url_parse().
I have not looked at the child code in details yet, but I would like to
suggest a change in the workflow. I think the child should only download
the gpo file and save it at some place, e.g. /var/lib/sss/gpo_cache/ and
then the backend will read an process it. This way you already have the
file available in the offline case. When calling the child the backend
should provide the smb url and a location to store the result. The child
can e.g. return a checksum for the file which the backend can save
together with the download time in the sysdb cache in a subtree below
cn=custom (grep sysdb.h for 'custom' to find the related sysdb calls).
With the download time it would be even possible to specific cache
lifetime during which the gpo file will not be downloaded again to save
bandwidth. But this should be optional.
What do you think?
bye,
Sumit
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
With regard to your suggestion to store the policy data in a local file (and store the
file's metadata in the cache), I think it would be preferrable to have the child parse
the file, and store the relevant data/metadata directly to the cache. I believe this is
how IPA HBAC currently works (i.e. storing to cache, rather than to file). This would
allow the file parsing to be done once (when it is written by the child), rather than the
file parsing being done every time the policy is processed (when it is read by the
backend). Additionally, keep in mind that we are interested in only a subset of the
stanzas (i.e. "Privilege Rights" stanza) in the Security Settings policy file
(GptTmpl.inf). In other words, only a small portion of the file contains data that is
relevant for us.
For this initial patch, I am having the child return the allowed_sids and denied_sids to
the backend for further processing. However, in subsequent patches, I am planning on
having the child store the relevant policy data to the cache, and then have the backend
retrieve the relevant policy data from the cache. In other words, the proposed logic for
future patches is:
* if we are online, the backend calls the child (which stores the parsed data to cache)
* regardless of whether we are online or offline, the backend retrieves the parsed data
from the cache and makes a policy decision.
With regard to reducing unnecessary downloads, I am planning on implementing the logic
suggested by [MS-GPOL] of comparing the cached gpo version against the current gpo version
(by downloading only the GPT.INI file). If the gpo versions are the same, there is no need
to download the policy file. Again, this is intended for a subsequent patch.
Regards,
Yassir.