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
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
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?)
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
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
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.
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
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.
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
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:
- 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.
- 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.
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
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.
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
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,
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
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.
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
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?
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 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...
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@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@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.orgmailto: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/
On 11/21/2011 07:42 PM, Greg.Lehmann@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@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/
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
On 11/22/2011 01:46 AM, Dmitri Pal wrote:
On 11/21/2011 07:42 PM, Greg.Lehmann@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
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@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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel@lists.fedorahosted.org