6:29 a.m.
Hi list,
Currently, we are using Centrify for Linux&AD integration so I was thinking we could
soon save some $$$ and use sssd for the same purpose.
There is still one thing (among others to which a RFEs have already been submitted) I am
missing:
Would it be possible for sssd to maintain the OperatingSystem attribute in AD updated? I
know that IPA uses quite minimalistic LDAP schema
so it is pity that it does not have any such an attribute, but if it had (comments
needed), the same code could be used for IPA and AD domains.
I am asking for auditing purposes - currently with Centrify it is easy to query AD just
for OperatingSystem attribute and one can
immediately see which OSes have been installed in the company.
Many thanks,
Ondrej
6:34 a.m.
On Mon, 21 Nov 2011, Ondrej Valousek wrote:
I am asking for auditing purposes - currently with Centrify it is
easy to
query AD just for OperatingSystem attribute and one can immediately see
which OSes have been installed in the company.
Do you want it maintained or merely created correctly in the first place?
If you're joining with AD, couldn't you do:
net ads join osName=CentOS osVer=6
jh
7:01 a.m.
On 11/21/2011 01:34 PM, John Hodrien wrote:
Do you want it maintained or merely created correctly in the first
place?
If you're joining with AD, couldn't you do:
net ads join osName=CentOS osVer=6
Ok, I did not know about that one (also no mention about it in "man
net"). So thanks.
Perhaps having it created (via the "net" command) would be easier to implement
right now but it have disadvantages (attribute won't change
as I update the system).
Centrify does this this way:
[ondrejv@ara /]$ cat /etc/redhat-release
Red Hat Enterprise Linux Client release 5.6 (Tikanga)
is parsed as:
OperatingSystem = Red Hat Enterprise Linux Client
OperatingSystemVersion = 5.6 (Tikanga)
OperatingSystemServicePack = CentrifyDC 4.3.0 -- here we could possibly have something
like Samba 3.6 or SSSD 1.8 or something like that
All attributes are arbitrary strings.
Summary:
- I do not know whose responsibility would this be (if sssd or samba) or how happily would
this RFE be accepted (thanks Stephen for the
offer) so I wanted to discuss here before submitting a RFE
- I would also like to see something like this in the pure IPA domains if possible
- also question if it is easier to have attributes above created/updated upon machine join
or if it is OK to maintain it updated on-the-fly.
Thanks,
Ondrej
7:04 a.m.
On Mon, 21 Nov 2011, Ondrej Valousek wrote:
Ok, I did not know about that one (also no mention about it in
"man net"). So thanks.
net ads join --help listed it on my system
Perhaps having it created (via the "net" command) would be
easier to
implement right now but it have disadvantages (attribute won't change as I
update the system).
I don't disagree in the slightest. I think there'd be some discussion on what
the content of these attributes would be best storing.
jh
7:12 a.m.
On Mon, 2011-11-21 at 14:01 +0100, Ondrej Valousek wrote:
On 11/21/2011 01:34 PM, John Hodrien wrote:
> Do you want it maintained or merely created correctly in the first place?
>
> If you're joining with AD, couldn't you do:
>
> net ads join osName=CentOS osVer=6
>
Ok, I did not know about that one (also no mention about it in "man
net"). So thanks.
Perhaps having it created (via the "net" command) would be easier to
implement right now but it have disadvantages (attribute won't change
as I update the system).
Centrify does this this way:
[ondrejv@ara /]$ cat /etc/redhat-release
Red Hat Enterprise Linux Client release 5.6 (Tikanga)
is parsed as:
OperatingSystem = Red Hat Enterprise Linux Client
OperatingSystemVersion = 5.6 (Tikanga)
OperatingSystemServicePack = CentrifyDC 4.3.0 -- here we could
possibly have something like Samba 3.6 or SSSD 1.8 or something like
that
All attributes are arbitrary strings.
Summary:
- I do not know whose responsibility would this be (if sssd or samba)
or how happily would this RFE be accepted (thanks Stephen for the
offer) so I wanted to discuss here before submitting a RFE
- I would also like to see something like this in the pure IPA domains
if possible
- also question if it is easier to have attributes above
created/updated upon machine join or if it is OK to maintain it
updated on-the-fly.
The problem with having this updated on-the-fly is that it implies (by
necessity) that client applications have to have privilege to change
this at whim. That means that this information cannot be used as
authoritative (since the client could very possibly be lying about
this). I think it's probably better to rely on setting it at join time
with 'net ads' and then only allow it to be changed by an administrator
later.
7:20 a.m.
On 11/21/2011 02:12 PM, Stephen Gallagher wrote:
The problem with having this updated on-the-fly is that it implies
(by
necessity) that client applications have to have privilege to change
this at whim. That means that this information cannot be used as
authoritative (since the client could very possibly be lying about
this). I think it's probably better to rely on setting it at join time
with 'net ads' and then only allow it to be changed by an administrator
later.
I do not understand. Not all applications have access, only those which have
access to the system Kerberos database (krb5.keytab).
Typically, only root (like sssd) applications have such an access and I can not imagine
why would sssd lie about this....
Can you clarify?
Ondrej
7:55 a.m.
On Mon, 2011-11-21 at 14:20 +0100, Ondrej Valousek wrote:
On 11/21/2011 02:12 PM, Stephen Gallagher wrote:
> The problem with having this updated on-the-fly is that it implies (by
> necessity) that client applications have to have privilege to change
> this at whim. That means that this information cannot be used as
> authoritative (since the client could very possibly be lying about
> this). I think it's probably better to rely on setting it at join time
> with 'net ads' and then only allow it to be changed by an administrator
> later.
I do not understand. Not all applications have access, only those
which have access to the system Kerberos database (krb5.keytab).
Typically, only root (like sssd) applications have such an access and
I can not imagine why would sssd lie about this....
Can you clarify?
Well, any root-level application can change this value. What this means
is that if root of the client was malicious (or simply obnoxious), they
could use the keytab to change this value at a whim, thus rendering the
option useless for searching, sorting, etc. This could potentially be
part of a complicated attack, as if a malicious user gained root access
on the machine, they could potentially delay a response (such as
patching a known vulnerability) by impacting the administrators'
abilities to see which machines were running an OS that was at risk.
Granted, that's a bit of a contrived example, but as a rule I tend to
feel that data like this should be configured centrally, rather than
updated by clients. First rule of security: always assume your clients
are malicious.
8:44 a.m.
On 11/21/2011 02:55 PM, Stephen Gallagher wrote:
Granted, that's a bit of a contrived example, but as a rule I
tend to
feel that data like this should be configured centrally, rather than
updated by clients. First rule of security: always assume your clients
are malicious.
I see. I needed this purely for auditing computers on LAN - so no
big danger of malicious clients.
Even in your (indeed contrived) example could the malicious application cause to disjoin
machine from AD/IPA domain or perform DOS attacks
against the servers. Eventually:
1. Even if we agree that we will set it up once upon machine join, the malicious client
can change it any time later. So no big difference here.
2. Even Microsoft AD clients (AD member computers) do it this way I believe.
I think in all cases you have to (to some extent) either trust your clients to make damn
sure that no user application can gain root
privileges. Even such a well perceived protocol like Kerberos can not protect you against
malicious root application running on your desktop.
So, with all respect, I do not take your arguments.
Ondrej
9:01 a.m.
On Mon, 2011-11-21 at 15:44 +0100, Ondrej Valousek wrote:
On 11/21/2011 02:55 PM, Stephen Gallagher wrote:
> Granted, that's a bit of a contrived example, but as a rule I tend to
> feel that data like this should be configured centrally, rather than
> updated by clients. First rule of security: always assume your clients
> are malicious.
>
I see. I needed this purely for auditing computers on LAN - so no big
danger of malicious clients.
Even in your (indeed contrived) example could the malicious
application cause to disjoin machine from AD/IPA domain or perform DOS
attacks against the servers. Eventually:
1. Even if we agree that we will set it up once upon machine join, the
malicious client can change it any time later. So no big difference
here.
No, this is the entire point I was making. When you're joining the
machine, you're doing so with Administrator credentials, not machine
credentials. The privilege to change this value is not given to the
machine, so it cannot change them later.
2. Even Microsoft AD clients (AD member computers) do it this way I
believe.
I'm not in the business of making the same mistakes as Microsoft :)
I think in all cases you have to (to some extent) either trust your
clients to make damn sure that no user application can gain root
privileges. Even such a well perceived protocol like Kerberos can not
protect you against malicious root application running on your
desktop.
Right, exactly. That's why we don't allow the client to have the
privilege to make such changes. You need to somehow acquire
administrative privileges to change it instead. I'm not sure if AD
allows you this configuration (that's a separate discussion), but
trusting the client is inherently bad.
So, with all respect, I do not take your arguments.
No offense
taken.
9:10 a.m.
On Mon, 21 Nov 2011, Stephen Gallagher wrote:
No, this is the entire point I was making. When you're joining
the
machine, you're doing so with Administrator credentials, not machine
credentials. The privilege to change this value is not given to the
machine, so it cannot change them later.
Nearly, but I wouldn't describe it as Administrator credentials. You're doing
it with credentials that can join a machine to the domain which is
significantly less privileged.
Question is, what *can* a machine do with its own credential? For example,
net ads keytab add works using a machine credential (at least it does on the
AD domain I'm testing against), so it can make service principals and update
its own ldap record as a result...
jh
9:18 a.m.
On Mon, 2011-11-21 at 15:10 +0000, John Hodrien wrote:
On Mon, 21 Nov 2011, Stephen Gallagher wrote:
> No, this is the entire point I was making. When you're joining the
> machine, you're doing so with Administrator credentials, not machine
> credentials. The privilege to change this value is not given to the
> machine, so it cannot change them later.
Nearly, but I wouldn't describe it as Administrator credentials. You're doing
it with credentials that can join a machine to the domain which is
significantly less privileged.
Question is, what *can* a machine do with its own credential? For example,
net ads keytab add works using a machine credential (at least it does on the
AD domain I'm testing against), so it can make service principals and update
its own ldap record as a result...
Well, I don't know how much of that is happening due to direct
modification of LDAP versus using RPC to initiate a routine to make the
changes. The latter can at least be validated.
Allowing direct access to LDAP attributes means that you have no control
over what they become.
9:21 a.m.
On Mon, 21 Nov 2011, Stephen Gallagher wrote:
Well, I don't know how much of that is happening due to direct
modification of LDAP versus using RPC to initiate a routine to make the
changes. The latter can at least be validated.
Allowing direct access to LDAP attributes means that you have no control
over what they become.
I'm assuming a machine can be updated by an auto-update process and the
machine will the fields in AD. In a way, it doesn't matter all that much
whether that's over RPC or LDAP as far as your hypothetical case goes does it?
All I mean is, I assume that hole exists for windows machines.
So if you stick with your comment about not repeating the mistakes microsoft
has made, that probably also means not using AD.
jh
9:47 a.m.
Hi,
On 2011-11-21 17:21, John Hodrien wrote:
On Mon, 21 Nov 2011, Stephen Gallagher wrote:
> Well, I don't know how much of that is happening due to direct
> modification of LDAP versus using RPC to initiate a routine to make the
> changes. The latter can at least be validated.
>
> Allowing direct access to LDAP attributes means that you have no control
> over what they become.
I'm assuming a machine can be updated by an auto-update process and the
machine will the fields in AD. In a way, it doesn't matter all that much
whether that's over RPC or LDAP as far as your hypothetical case goes does it?
when you operate as the user who has privileges to join machines to the
domain you can also do direct modifications of those hosts' LDAP
attributes. However, if you have only the privileges of the principal
from the host keytab, you don't have permissions to change the machine
attributes.
Cheers,
--
Marko Myllynen
10:27 a.m.
On 11/21/2011 04:47 PM, Marko Myllynen wrote:
when you operate as the user who has privileges to join machines to
the
domain you can also do direct modifications of those hosts' LDAP
attributes. However, if you have only the privileges of the principal
from the host keytab, you don't have permissions to change the machine
attributes.
Thanks for this update - I was too lazy to check myself :-)
This leaves us with the single option - set the attributes upon the client join time using
admin privileges, right?
If so against which component should I submit the RFE, against samba or sssd?
I think I have heard the 'net' command is going to be a part of the sssd package
in the future, but I might be wrong....
Ondrej
10:34 a.m.
On Mon, 2011-11-21 at 17:27 +0100, Ondrej Valousek wrote:
On 11/21/2011 04:47 PM, Marko Myllynen wrote:
> when you operate as the user who has privileges to join machines to the
> domain you can also do direct modifications of those hosts' LDAP
> attributes. However, if you have only the privileges of the principal
> from the host keytab, you don't have permissions to change the machine
> attributes.
Thanks for this update - I was too lazy to check myself :-)
This leaves us with the single option - set the attributes upon the
client join time using admin privileges, right?
If so against which component should I submit the RFE, against samba
or sssd?
I think I have heard the 'net' command is going to be a part of the
sssd package in the future, but I might be wrong....
File it against samba. The 'net' command is always going to remain a
part of samba/winbind. SSSD might pull it in at some point, but it will
be a dependency, not an internal component.
10:41 a.m.
On 11/21/2011 05:34 PM, Stephen Gallagher wrote:
File it against samba. The 'net' command is always going to
remain a
part of samba/winbind. SSSD might pull it in at some point, but it will
be a dependency, not an internal component.
Ok then there is probably nothing to
file as I can always use the 'net ads join' options that John mentioned earlier in
this thread.
Thanks all involved anyway...
Ondrej
10:43 a.m.
On 11/21/2011 05:41 PM, Ondrej Valousek wrote:
Ok then there is probably nothing to file as I can always use the
'net ads join' options that John mentioned earlier in this thread.
Thanks all involved anyway...
Maybe there is one thing I can do. File a RFE about
extending IPA schema to contain a similar attributes in the IPA domain, too. Does it
make any sense?
6:07 p.m.
On 11/21/2011 11:43 AM, Ondrej Valousek wrote:
On 11/21/2011 05:41 PM, Ondrej Valousek wrote:
> Ok then there is probably nothing to file as I can always use the
> 'net ads join' options that John mentioned earlier in this thread.
> Thanks all involved anyway...
Maybe there is one thing I can do. File a RFE about extending IPA
schema to contain a similar attributes in the IPA domain, too. Does it
make any sense?
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
Interesting enough this
feature was considered from the very beginning.
See item 1.3.5.2
http://freeipa.org/page/V2BPRD#1._Machine_Identity_and_Authentication
But during design the same concerns were risen.
I have a question: can this attribute be made reliable meaning that it
adequately reflect the reality?
We could not figure out how to make it happen during the design. If it
can't be made such, is it really useful? Would it be used or
administrators will try, see that it does not work out and abandon the
idea? We have so many things in front of us. Is it really something that
would be usable? Can it be made usable?
If yes, let us file the ticket...
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
6:42 p.m.
It seems to me what you really need is an inventory management system. I’d suggest
extending AD schemas to handle this is not practical. Probably the same for IPA, but I
must admit I am not that familiar with it.
Cheers,
Greg
From: sssd-devel-bounces(a)lists.fedorahosted.org
[mailto:sssd-devel-bounces@lists.fedorahosted.org] On Behalf Of Dmitri Pal
Sent: Tuesday, 22 November 2011 10:08 AM
To: sssd-devel(a)lists.fedorahosted.org
Subject: Re: [SSSD] SSSD (another) wish-list
On 11/21/2011 11:43 AM, Ondrej Valousek wrote:
On 11/21/2011 05:41 PM, Ondrej Valousek wrote:
Ok then there is probably nothing to file as I can always use the 'net ads join'
options that John mentioned earlier in this thread.
Thanks all involved anyway...
Maybe there is one thing I can do. File a RFE about extending IPA schema to contain a
similar attributes in the IPA domain, too. Does it make any sense?
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org<mailto:sssd-devel@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/sssd-devel
Interesting enough this feature was considered from the very beginning. See item 1.3.5.2
http://freeipa.org/page/V2BPRD#1._Machine_Identity_and_Authentication
But during design the same concerns were risen.
I have a question: can this attribute be made reliable meaning that it adequately reflect
the reality?
We could not figure out how to make it happen during the design. If it can't be made
such, is it really useful? Would it be used or administrators will try, see that it does
not work out and abandon the idea? We have so many things in front of us. Is it really
something that would be usable? Can it be made usable?
If yes, let us file the ticket...
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>
6:46 p.m.
On 11/21/2011 07:42 PM, Greg.Lehmann(a)csiro.au wrote:
It seems to me what you really need is an inventory management system.
I’d suggest extending AD schemas to handle this is not practical.
Probably the same for IPA, but I must admit I am not that familiar
with it.
Actually this is a very good point. I think that content management
system like Satellite is probably what you should look for.
Cheers,
Greg
*From:*sssd-devel-bounces@lists.fedorahosted.org
[mailto:sssd-devel-bounces@lists.fedorahosted.org] *On Behalf Of
*Dmitri Pal
*Sent:* Tuesday, 22 November 2011 10:08 AM
*To:* sssd-devel(a)lists.fedorahosted.org
*Subject:* Re: [SSSD] SSSD (another) wish-list
On 11/21/2011 11:43 AM, Ondrej Valousek wrote:
On 11/21/2011 05:41 PM, Ondrej Valousek wrote:
Ok then there is probably nothing to file as I can always use the 'net
ads join' options that John mentioned earlier in this thread.
Thanks all involved anyway...
Maybe there is one thing I can do. File a RFE about extending IPA
schema to contain a similar attributes in the IPA domain, too. Does it
make any sense?
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org <mailto:sssd-devel@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/sssd-devel
Interesting enough this feature was considered from the very
beginning. See item 1.3.5.2
http://freeipa.org/page/V2BPRD#1._Machine_Identity_and_Authentication
But during design the same concerns were risen.
I have a question: can this attribute be made reliable meaning that it
adequately reflect the reality?
We could not figure out how to make it happen during the design. If
it can't be made such, is it really useful? Would it be used or
administrators will try, see that it does not work out and abandon the
idea? We have so many things in front of us. Is it really something
that would be usable? Can it be made usable?
If yes, let us file the ticket...
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
1:57 a.m.
On Tue, 22 Nov 2011, Dmitri Pal wrote:
Actually this is a very good point. I think that content management
system
like Satellite is probably what you should look for.
I'm not sure I'd describe Satellite as a CMS, but I agree with your point.
Other than listing a machine as running RHEL 6, I wasn't sure I saw the appeal
of storing anything more in AD, as it's such a crude level of reporting anyway
(who really cares that a machine is running Service Pack 2 if it's not got a
critical patch installed?).
Spacewalk/Satellite do much more fine grained reporting, along with detailed
hardware inventories.
jh
4:07 a.m.
On 11/22/2011 01:46 AM, Dmitri Pal wrote:
On 11/21/2011 07:42 PM, Greg.Lehmann(a)csiro.au wrote:
>
> It seems to me what you really need is an inventory management system. I’d suggest
extending AD schemas to handle this is not practical.
> Probably the same for IPA, but I must admit I am not that familiar with it.
>
Actually this is a very good point. I think that content management system like Satellite
is probably what you should look for.
Understood, but we are looking for something
not too complicated & possibly free - we are ready to accept that it is not 100%
reliable.
The beauty of using LDAP attributes is that it requires no special software to maintain
and it is easily implementable.
So despite its obvious disadvantages, I believe it would find its use in smaller
networks.
I am no expert over content management systems so if it (CMS) is on the IPA roadmap
already, then fine, but if not, then something like this
(ldap attrs) would be (maybe) a good starting point.
Ondrej
7:39 a.m.
On 11/22/2011 05:07 AM, Ondrej Valousek wrote:
On 11/22/2011 01:46 AM, Dmitri Pal wrote:
> On 11/21/2011 07:42 PM, Greg.Lehmann(a)csiro.au wrote:
>>
>> It seems to me what you really need is an inventory management
>> system. I’d suggest extending AD schemas to handle this is not
>> practical. Probably the same for IPA, but I must admit I am not that
>> familiar with it.
>>
>
> Actually this is a very good point. I think that content management
> system like Satellite is probably what you should look for.
Understood, but we are looking for something not too complicated &
possibly free - we are ready to accept that it is not 100% reliable.
The beauty of using LDAP attributes is that it requires no special
software to maintain and it is easily implementable.
So despite its obvious disadvantages, I believe it would find its use
in smaller networks.
I am no expert over content management systems so if it (CMS) is on
the IPA roadmap already, then fine, but if not, then something like
this (ldap attrs) would be (maybe) a good starting point.
I am still not convinced. It seems that the package management tools are
much better equipped to do what you are looking for and they are also free.
Ondrej
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
6:37 a.m.
On Mon, 2011-11-21 at 13:29 +0100, Ondrej Valousek wrote:
Hi list,
Currently, we are using Centrify for Linux&AD integration so I was
thinking we could soon save some $$$ and use sssd for the same
purpose.
There is still one thing (among others to which a RFEs have already
been submitted) I am missing:
Would it be possible for sssd to maintain the OperatingSystem
attribute in AD updated? I know that IPA uses quite minimalistic LDAP
schema so it is pity that it does not have any such an attribute, but
if it had (comments needed), the same code could be used for IPA and
AD domains.
I am asking for auditing purposes - currently with Centrify it is easy
to query AD just for OperatingSystem attribute and one can immediately
see which OSes have been installed in the company.
Please file an RFE in the SSSD bug tracker at
https://fedorahosted.org/sssd
Please also include some details about the OperatingSystem attribute
(Specifically, what is the expected format of the contents? Is it an
arbitrary string or does it need to be structured in a particular way.
If it's an arbitrary string, is there a convention it should follow?)
4558
days inactive
4559
days old
sssd-devel@lists.fedorahosted.org
23 comments
6 participants
participants (6)
-
Dmitri Pal -
Greg Lehmann -
John Hodrien -
Marko Myllynen -
Ondrej Valousek -
Stephen Gallagher