Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-22 Thread Bryan Smith
On Thu, Sep 22, 2016 at 5:52 AM, Mark Clarke  wrote:

> Your points have not convinced about the level of deployment of the IPA
> solution
>

Virtually _all_ mixed environments I've worked in since 2012 have use SSSD,
including Ubuntu 2013+, and the "common denominator" of "Policy Objects" in
those environments are the ones in IPA, even if it's hosted on 389 or even
OpenLDAP.

I.e., The fact that you're so "tunnel visioned" on thinking IPA is a Samba
or LDAP replacement is part of your problem here.  I'm _talking_ "Policy
Objects" in the directdory server, whether it's IPA, 389 or even OpenLDAP,
with SSSD on the client.

I have now stated the _context_ of my 'position' a dozen times.

but your passions is undeniable.
>

Okay, I'll humor you ...

_Where_ do you think that alleged "passion" comes from?  Could it be actual
integrations?  Corporate adoption?

Or "ancedotal evidence" that the "NSS/389/Dogtag" is an "emerging
technology"?  ;)

My opinions still stands the exams objectives and weightings should reflect
> what administrators come across in their day-to-day work.
>

In your world, yes.
What you're failing to understand is ... I have my experience too.

How this can be controversial I do not understand.
>

Yet, you cannot respect my experience as anything but "ancedotal."

By your own admission, you don't see NSS/389/Dogtag at all.  You think it's
an "emerging technology."  And you also think any coverage of IPA in 303 is
already overboard.

What you fail to understand is, with Microsoft's change for Windows
10/Server 2016 and the corresponding AD 2016 domain/forest-level, Microsoft
is going to _force_ adoption of something like IPA, in "mixed
environments."  But this wasn't accidental.  In fact, it was Microsoft
giving Red Hat a nod that they 'got it right.'

Because AD architects don't want any POSIX in their AD Forest, because AD
admins don't populate, much less understand, even the basic IETF RFC 2307
attributes.  Less than 1% of AD domains have a single IDMU populated.
That's why they are dropping them.

At the same time, AD architects and their AD admins _do_ want to access
Linux resources, such as Samba servers.  The Samba service itself has a lot
of issues with this as a Member Server in many, huge corporate AD
environments.  It's only really good for segmented, departmental or SMB
setups.

Putting Samba in an IPA dmain solves that, with the corresponding AD Forest
Trust with Windows systems.  Windows stays Windows, POSIX stays POSIX.

I guess we will wait for others to give us their insights and opinions on
> this matter and be guided by them.
>

Well, I'm certainly not here for my health.  I.e., I have a lot of people
who tell me not to bother with LPI because of statements exactly like
yours.  ;)

But what do I know?  I just offer "ancedotal evidence."

-- bjs
___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-22 Thread Mark Clarke
Your points have not convinced about the level of deployment of the IPA
solution but your passions is undeniable. My opinions still stands the
exams objectives and weightings should reflect what administrators come
across in their day-to-day work. How this can be controversial I do not
understand.   I guess we will wait for others to give us their insights
and opinions on this matter and be guided by them.


On 22/09/2016 10:58, Bryan Smith wrote:
> On Thu, Sep 22, 2016 at 1:00 AM, Mark Clarke  > wrote:
>
> I get it you think IPA is the best technology ever
>
>
> Thank you for justifying why someone like myself is around.  ;)
>
> Again, re-quoting myself ...
>
> o  Short version ...
>
>   SSSD support of Policy Objects is well proliferated.
>
> o  In bullets ...
>
>   _If_ we are going to include 'Policy Objects' ...
>- Start with the IPA ones, specifically where ...
>- SSSD**, w/o IPA, supports them so not only ...
>- All Linux distros** support them, but ...
>- Any LDAP server (OpenLDAP, 389, etc... ) does too
>
> The _context_ of my _entire_ response has been under "Policy Objects,"
> after someone suggested coverage of "GPO" (Group Policy Objects).
>
> and everybody else is ignorant for not adopting it sooner
>
>
> No, again, re-quoting myself ...
>
> o  Case-in-point ...
>
>   **This assumption is the the most frustrating reality I
> deal with day-in, day out:
>  "the only distro that supports it is Fedora,
>   and is largely unsupported in the rest of them.
>   Seems like a distro specific feature?"
>
> I do a _lot_ of Debian and Ubuntu as well.  It has SSSD, so it can
> support Policy Objects as well.  Newer Debian builds even have IPA,
> including the Server portion, thanx to the hard work of one Canonical
> employee.  But he's not well served by even Ubuntu users because of
> things said ... exactly what you're saying here.
>
> Furthermore, you also said ...
>
>   "I wouldn't say NSS/389/Dogtag has
>been widely adopted outside RedHat yet
>it very well might be an emerging technology
>but its not something every sys admin needs
>to know. If its included  at an "awareness level"
>then ok - but until it gets wide spread adoption,
>and mind share, I can't agree that it should be
>covered in any more details. To be frank I think
>there the coverage in 303 is overboard."
>
> This ^^^ is an example of ignorance.
>
> It's like saying, _literally_, Mozilla Firefox is an "emerging
> technology" in browsers.  Because just like some of the NCSA team, a
> lot of the Michigan LDAP team directly created the code lineage!  It's
> not only in _major_ installations, but with Oracle dropping support
> this decade, it's become the defacto standard.
>
> but I don't think the purpose of LPI is to push what we think 
>
> is the next big thing but to see what is actually out there in use.
>
>
> You mean no one uses SSSD, 389/Dogtag, et al., and that lineage,
> right?  It's an "emerging technology" that no one uses, right?
>
> So those Policy Objects are useless.  No one uses them.  No one
> manages anything.  So we shouldn't look at what 389 does, and
> especially not IPA.
>
> From you own anecdotal evidence
>
>
> Oa, my "ancedotal evidence."
>
> of the use of IPA it is a technology that may be in the process of 
>
> being slowly adopted.
>
>
> Again, I'll requote myself ...
>
> o  Short version ...
>
>   SSSD support of Policy Objects is well proliferated.
>
> o  In bullets ...
>
>   _If_ we are going to include 'Policy Objects' ...
>- Start with the IPA ones, specifically where ...
>- SSSD**, w/o IPA, supports them so not only ...
>- All Linux distros** support them, but ...
>- Any LDAP server (OpenLDAP, 389, etc... ) does too
>
> The _context_ of my _entire_ response has been under "Policy Objects,"
> after someone suggested coverage of "GPO" (Group Policy Objects).
>
> So is BTRFS, ZFS,
>
>
> Well, ZFS, at least from Oracle.  It gets weird outside of Oracle. 
> But that's anoterhs tory.
>
> Linux capabilities, name spaces etc.
>
>
> Nope.  I don't know anything about modern DevOps with CloudFoundry,
> OpenShift, et al.
>  
>
> If it use continues to grow we have a process to review the level
> of coverage - and if something else ends up replacing it then we
> can swap it out.  
>
> There are plenty of technologies people are passionate about but
> have not yet been widely adopted
>
>
> Well, all I have is my "ancedotal evidence."  Not that I'm here to
> actually talk about what corporate are using.  I mean, I'm Mr.
> "ancedotal evidence."  I'm just passionate, and have no basis for what
> I say.  Yep.
>  
>
> - I don't see people using LPI objectives to push these agendas.
> Upstart/Systemd is a case in point.
>
>
> Nope.  Corporations don't use SMF under Solaris, and don't expect
> equivalent service manageme

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-22 Thread Bryan Smith
On Mon, Sep 19, 2016 at 8:11 PM, alexbm...@gmail.com
 wrote:
> Gentlemen,
> It would be interesting to insert GPO referring to samba.
> To: Relevance of NT4 domains vs. AD domains.

So, I'm going to step back, to where this all starts.

First off, I can be "snarky" at times in public discussions.  I fully
admit that.  Part of that reason is that I hear these comments all too
often, and I have to ask people's managers to not include them in
meetings until later.  That way we can get things done.

Because, secondly, as I mentioned before ...

o  The cringe-worthy ...

  The sad thing here is, AD architects follow me better than Linux
  "enthusiasts."  Especially when I explain SSSD modular stack as being
  like the NT LSA modular stack.

  I literally _cringe_ when Linux "enthusiasts" tell client
  stakeholders, "Oh, Linux doesn't have something like that, or it's not
  easy to support, so just buy" ... (insert really expensive,
  proprietary client).

So, when people say "Why doesn't Linux use GPOs?", and "Samba can
replace AD" and even "Linux doesn't have something like AD," etc...,
it gets exceedingly difficult, especially since some of these
facilities have little to do with real-world, corporate deployments.
They are all standalone, division or SMB deployments.

Most corporate deployments of "mixed environments" already have
separate AD and LDAP, some with some sort of exchange, others possibly
with AD for all Kerberos authentication, while LDAP is used for all
POSIX attributes.  In nearly all cases of the last few years, most are
now using SSSD, instead of any legacy, client-side setup.  With SSSD
comes the ability for true, universal Policy Objects on Linux.

And IPA as a drop-in, which then adds AD Forest Trusts.

Again, since we've gone from Mixed Environments, to Security, let's
look at how IPA works with AD, and how Samba does not.  Especially
since Microsoft is basically forcing IPA adoption, after dropping IDMU
in Windows 10/Server 2016.  To start, I'll include this reddit post
from 2015. [1]  It highlights the real issues a lot of corporations
have with the Samba AD DC functionality.

Again, the biggest issue with Samba AD DC is that it really doesn't
like AD Forests, with lots of domains, and the underlying Linux system
that the Samba service is running on cannot be managed by AD well at
all.  In fact, it was the SSSD/IPA guys that basically ported most of
the multi-domain code over to Samba, as many are also Samba
contributors.  SSSD/IPA's origins are heavily with major Samba
contributors who wanted a more "universal Winbindd" and a "AD for
POSIX," respectively.

This is why more and more organizations would rather keep their Samba
services under a solution where it can be managed, especially since
there are so many issues with non-Windows systems, and utter lack of
attributes for POSIX (sans only "basic" IDMU, which is going away).
Windows stays AD, POSIX stays IPA, and the two have an AD Forest Trust
between.  That's where mixed environments are going, which is really
just a refinement of the separate LDAP and AD trees in corporations.
But now one where they can use each other's resources, and be managed
by the teams on each.

Which even Microsoft is nodding its head, because its own AD
architects don't want any POSIX systems in AD, because its own AD
admins don't even know how to manage even basic attributes.  The stats
on even just basic IDMU population is a somber reminder.

-- bjs

[1] 
https://www.reddit.com/r/linuxadmin/comments/2jlo0v/has_anybody_did_a_side_by_side_review_of_freeipa/clkzs20
___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev


Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-22 Thread Bryan Smith
On Thu, Sep 22, 2016 at 1:00 AM, Mark Clarke  wrote:

> I get it you think IPA is the best technology ever
>

Thank you for justifying why someone like myself is around.  ;)

Again, re-quoting myself ...

o  Short version ...

  SSSD support of Policy Objects is well proliferated.

o  In bullets ...

  _If_ we are going to include 'Policy Objects' ...
   - Start with the IPA ones, specifically where ...
   - SSSD**, w/o IPA, supports them so not only ...
   - All Linux distros** support them, but ...
   - Any LDAP server (OpenLDAP, 389, etc... ) does too

The _context_ of my _entire_ response has been under "Policy Objects,"
after someone suggested coverage of "GPO" (Group Policy Objects).

and everybody else is ignorant for not adopting it sooner
>

No, again, re-quoting myself ...

o  Case-in-point ...

  **This assumption is the the most frustrating reality I
deal with day-in, day out:
 "the only distro that supports it is Fedora,
  and is largely unsupported in the rest of them.
  Seems like a distro specific feature?"

I do a _lot_ of Debian and Ubuntu as well.  It has SSSD, so it can support
Policy Objects as well.  Newer Debian builds even have IPA, including the
Server portion, thanx to the hard work of one Canonical employee.  But he's
not well served by even Ubuntu users because of things said ... exactly
what you're saying here.

Furthermore, you also said ...

  "I wouldn't say NSS/389/Dogtag has
   been widely adopted outside RedHat yet
   it very well might be an emerging technology
   but its not something every sys admin needs
   to know. If its included  at an "awareness level"
   then ok - but until it gets wide spread adoption,
   and mind share, I can't agree that it should be
   covered in any more details. To be frank I think
   there the coverage in 303 is overboard."

This ^^^ is an example of ignorance.

It's like saying, _literally_, Mozilla Firefox is an "emerging technology"
in browsers.  Because just like some of the NCSA team, a lot of the
Michigan LDAP team directly created the code lineage!  It's not only in
_major_ installations, but with Oracle dropping support this decade, it's
become the defacto standard.

but I don't think the purpose of LPI is to push what we think
>
is the next big thing but to see what is actually out there in use.
>

You mean no one uses SSSD, 389/Dogtag, et al., and that lineage, right?
It's an "emerging technology" that no one uses, right?

So those Policy Objects are useless.  No one uses them.  No one manages
anything.  So we shouldn't look at what 389 does, and especially not IPA.

>From you own anecdotal evidence
>

Oa, my "ancedotal evidence."

of the use of IPA it is a technology that may be in the process of
>
being slowly adopted.
>

Again, I'll requote myself ...

o  Short version ...

  SSSD support of Policy Objects is well proliferated.

o  In bullets ...

  _If_ we are going to include 'Policy Objects' ...
   - Start with the IPA ones, specifically where ...
   - SSSD**, w/o IPA, supports them so not only ...
   - All Linux distros** support them, but ...
   - Any LDAP server (OpenLDAP, 389, etc... ) does too

The _context_ of my _entire_ response has been under "Policy Objects,"
after someone suggested coverage of "GPO" (Group Policy Objects).

So is BTRFS, ZFS,
>

Well, ZFS, at least from Oracle.  It gets weird outside of Oracle.  But
that's anoterhs tory.

Linux capabilities, name spaces etc.
>

Nope.  I don't know anything about modern DevOps with CloudFoundry,
OpenShift, et al.


> If it use continues to grow we have a process to review the level of
> coverage - and if something else ends up replacing it then we can swap it
> out.
>
There are plenty of technologies people are passionate about but have not
> yet been widely adopted
>

Well, all I have is my "ancedotal evidence."  Not that I'm here to actually
talk about what corporate are using.  I mean, I'm Mr. "ancedotal evidence."
 I'm just passionate, and have no basis for what I say.  Yep.


> - I don't see people using LPI objectives to push these agendas.
> Upstart/Systemd is a case in point.
>

Nope.  Corporations don't use SMF under Solaris, and don't expect
equivalent service management under Linux (e.g., Upstart), much more
dynamic service, resource and system state capabilities (e.g., the *d/*ctl
solutions).  The latter isn't required for dynamic, software defined
networking (SDN) and storage (SDS) in things libvirt, such as for things
like OpenStack.   Nope.

I'm just a passionate guy.  Have nothing to do with leading any
professional services or enablement at anyone pushing Debian and
Fedora-based distros, integrating some of the first or largest
installations int he past, or writing any of the first sets of
documentation.

Don't listen to me.  I'm a guy that is only passionate about Fedora-only
stuff.  ;)


-- 
Bryan J Smith  -  http://www.linkedin.com/in/bjsmith
E-mail:  b.j.smith at ieee.org  or  me at bjsmith.me

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-21 Thread Mark Clarke
I get it you think IPA is the best technology ever and everybody else is
ignorant for not adopting it sooner but I don't think the purpose of LPI
is to push what we think is the next big thing but to see what is
actually out there in use. From you own anecdotal evidence of the use of
IPA it is a technology that may be in the process of being slowly
adopted.  So is BTRFS, ZFS,  Linux capabilities, name spaces etc. If it
use continues to grow we have a process to review the level of coverage
- and if something else ends up replacing it then we can swap it out.

There are plenty of technologies people are passionate about but have
not yet been widely adopted - I don't see people using LPI objectives to
push these agendas. Upstart/Systemd is a case in point.



On 21/09/2016 13:15, Bryan Smith wrote:
>
> And if you're unaware ...
>
> SuSE shipped OpenLDAP as it's pre-configured directory server (and
> very well), but once acquired by Novell (now Attachment), they started
> pushing their proprietary server. This was around the same time Red
> Hat acquired iPlanet assets a dozen years ago.
>
> Canonical has long just pushed people towards a couple of costly,
> proprietary add-ons (we're talking CALs of US$100s per Linux system)
> to add POSIX policies to AD DCs running Windows.
>
> Samba doesn't address POSIX services, it's just a Windows client
> service, even the DC is an AD/Windows-only capability, atop of a POSIX
> platform. There is no AD facility to support the underlying POSIX
> platform, no standard schema in AD to support POSIX platforms, and
> Identity Management for UNIX (IDMU) only adds extremely basic user
> (iNetOrgPerson IETF 2307bis) to AD, which is dropped in Win10/2016
> Domain/Forest levels.
>
> No, you have to manage POSIX attributes with POSIX schema in LDAP,
> ideally with Certificate and Kerberos for both Security and Trust
> aspects.  So, what is the *only* open source solution in the world
> that has done this?  The only one to introduces an "equivalent" to the
> NT LSA in SSSD, the only one that handles a full, multi-domain,
> multi-tree, AD Forrest in Kerberos Trusts (IPA Server) all while
> making Keys and POSIX Policy Objects cake to push out to the POSIX
> clients (IPA Client, via SSSD)?
>
> Name one other, 100% open source solution from client to server, and
> I'm all ears.  Until then, distros have scrambled to add NSS/SSSD/IPA
> Client, and desperately are trying to integrate 389/Dogtag/IPA Server,
> after years of ignoring Red Hat overtures as they either tried to sell
> their "proprietary" add-on, or ignored the problem altogether and
> relied on proprietary 3rd parties.
>
> That's the history, in-a-nutshell.
>
> -- bjs
>
> DISCLAIMER: Sent from phone, please excuse any typos
> -- 
> Bryan J Smith - Technology Mercenary
> b.j.sm...@ieee.org  - m...@bjsmith.me
>  - http://linkedin.com/in/bjsmith
>
>
>
> On Sep 21, 2016 06:58, "Bryan Smith"  > wrote:
>
> They used to say the same thing about NSS/389/Dogtag.  Now every
> distribution is hacking in support for SSSD and IPA.  Why is that? ;)
>
> E.g.., how many people used to not only OpenLDAP was the only open
> source directory server, but say inherent, multi-master
> replication wasn't available or didn't work well?
>
> I. e., cannot help if people are unfamiliar, and distributions
> don't get enough maintainers to port it. The first time someone
> sees AD Forest Trusts at work, they are instantly drawn to it.
> Heck, just the SSSD portion draws them.
>
> So, let me re-iterate my point one more time ...
>
> AD Group Policy Objects (GPO) are used to manage Windows
> attributes. So why would we include them in a POSIX (UNIX/Linux)
> security exam?  There are no free or open source implementations
> that add POSIX support to GPOs, only proprietary solutions.
>
> Ergo ...
>
> If we're going to add any 'Policy' objectives to any POSIX
> security exam, they should be the POSIX attributes that can be
> stored in a LDAP set of schema instead.  And I'd argue the most
> 'standarized' set of 'Policy' Objects are the ones that cover
> certificates, SSH, sudoers, auto_home, etc...
>
> These were popularized in NSS/389/Dogtag (fka iPlanet
> Security/Directory/Certificate, well proliferated in major
> installations), acquired by Red Hat in 2004, fully open sourced in
> 2005 (a few components were re-written), including its inherent,
> multi-master replication, and most people implement in Identity,
> Policy, Audit (IPA) out-of-the-box. Other than certificate, this
> schema can also be implemented in OpenLDAP as well.
>
> Most distributions have been hacking in SSSD/IPA support, after
> ignoring NSS/389/Dogtag for a decade, because unlike
> Samba-Winbindd/OpenLDAP, it actually addresses a crapload of
> interoperability and security issues, let

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-21 Thread Bryan Smith
Now my more productive response ...  ;)


  o  Short version ...

SSSD support of Policy Objects is well proliferated.


  o  In bullets ...

_If_ we are going to include 'Policy Objects' ...
 - Start with the IPA ones, specifically where ...
 - SSSD**, w/o IPA, supports them so not only ...
 - All Linux distros** support them, but ...
 - Any LDAP server (OpenLDAP, 389, etc... ) does too


  o  Case-in-point ...

**This assumption is the the most frustrating reality I deal with
day-in, day out:
  "the only distro that supports it is Fedora,
   and is largely unsupported in the rest of them.
   Seems like a distro specific feature?"

I hear that from Ubuntu admins on SSSD regularly.  But then I ask them
to "humor me," and then they setup SSSD for the first time, and say 2
things ...

1)  "Why the heck was I hacking up PAM (LDAP/KRB5), Samba (Winbindd)
and dealing with flaky NSCD?"

SSSD was designed by some of the best Samba and Directory Server
maintainers for a reason.  Many things that SSSD implemented has been
ported and patched in Winbindd, but doesn't solve the root issues that
SSSD does.

2)  "But can't there be an easier, single client that prevents me from
having to setup anything?"

That's IPA Client.  If distros would have adopted and integrated
NSS/389/Dogtag some dozen (12) years ago, then IPA Client would be a
no-brainer.  But because they didn't, they are behind.


  o  The cringe-worthy ...

The sad thing here is, AD architects follow me better than Linux
"enthusiasts."  Especially when I explain SSSD modular stack as being
like the NT LSA modular stack.

I literally _cringe_ when Linux "enthusiasts" tell client
stakeholders, "Oh, Linux doesn't have something like that, or it's not
easy to support, so just buy" ... (insert really expensive,
proprietary client).

It's _not_ about IPA at all.
It's about Policy Objects.
SSSD supports them, including ...
With_out_ IPA.

IPA is really _nothing_ more than a 'canned' LDAP + Kerberos + DNS +
Certificate + Policy + etc..., and relies on all the features in SSSD
stack on the client side ...

Just like AD relies on the LSA stack on the client side.

If your distro supports SSSD, and virtually _everyone_ does today, a
number of Policy Objects are supported out-of-the-box.  That's what
this is literally about, _not_ the directory server.

Now the added reality is ... imagine if you had to setup AD-LDAP
'manually' and other things, with MS-Kerberos, etc...   No, the
Windows world wouldn't accept that.  Heck, Canonical doesn't even
bother.

IPA is just well-liked because you run ipa-client, and you're done.
You don't have to hack up files, from PAM to SSSD to LDAP to Kerberos
to various RPC to others.  But you do _not_ need to do such.  You can
use _any_ LDAP server for many of the policies.

_Every_ distro has SSSD now, and most have the IPA Client ported over.
But because they didn't integrate the NSS/389/Dogtag stack a dozen
years ago, they are shotgunning efforts now.

Has _nothing_ to do with "distro-specific," but user ignorance.  Many
users of many distros don't work in corporate environments where they
push open source first.  They just buy something proprietary instead.

That's the problem.  ;)

-- bjs


On Wed, Sep 21, 2016 at 7:16 AM, Bryan Smith  wrote:
> Again, ignorance is bliss.
>
> DISCLAIMER: Sent from phone, please excuse any typos
> --
> Bryan J Smith - Technology Mercenary
> b.j.sm...@ieee.org - m...@bjsmith.me - http://linkedin.com/in/bjsmith
>
>
>
> On Sep 21, 2016 07:09, "Mark Clarke"  wrote:
>>
>> On 21/09/2016 12:58, Bryan Smith wrote:
>> >
>> > They used to say the same thing about NSS/389/Dogtag.  Now every
>> > distribution is hacking in support for SSSD and IPA.  Why is that? ;)
>> >
>> > E.g.., how many people used to not only OpenLDAP was the only open
>> > source directory server, but say inherent, multi-master replication
>> > wasn't available or didn't work well?
>> >
>> > I. e., cannot help if people are unfamiliar, and distributions don't
>> > get enough maintainers to port it. The first time someone sees AD
>> > Forest Trusts at work, they are instantly drawn to it. Heck, just the
>> > SSSD portion draws them.
>> >
>> I wouldn't say NSS/389/Dogtag has been widely adopted outside RedHat yet
>> - it very well might be an emerging technology but its not something
>> every sys admin needs to know. If its included  at an "awareness level"
>> then ok - but until it gets wide spread adoption, and mind share, I
>> can't agree that it should be covered in any more details. To be frank I
>> think there the coverage in 303 is overboard. BTRFS and ZFS should have
>> a much bigger weighting in the certs - but that is not relevant here :)
>>
>>
>>
>>
>> --
>> Mark Clarke
>> 📱  +2711-781 8014
>> 🌠  www.JumpingBean.co.za
>>
>> ___
>> lpi-examdev mailing list
>> lpi-examdev@lpi.org
>> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev



-- 

--
Bryan J Smith  -  http://www.linkedi

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-21 Thread Bryan Smith
Again, ignorance is bliss.

DISCLAIMER: Sent from phone, please excuse any typos
-- 
Bryan J Smith - Technology Mercenary
b.j.sm...@ieee.org - m...@bjsmith.me - http://linkedin.com/in/bjsmith


On Sep 21, 2016 07:09, "Mark Clarke"  wrote:

> On 21/09/2016 12:58, Bryan Smith wrote:
> >
> > They used to say the same thing about NSS/389/Dogtag.  Now every
> > distribution is hacking in support for SSSD and IPA.  Why is that? ;)
> >
> > E.g.., how many people used to not only OpenLDAP was the only open
> > source directory server, but say inherent, multi-master replication
> > wasn't available or didn't work well?
> >
> > I. e., cannot help if people are unfamiliar, and distributions don't
> > get enough maintainers to port it. The first time someone sees AD
> > Forest Trusts at work, they are instantly drawn to it. Heck, just the
> > SSSD portion draws them.
> >
> I wouldn't say NSS/389/Dogtag has been widely adopted outside RedHat yet
> - it very well might be an emerging technology but its not something
> every sys admin needs to know. If its included  at an "awareness level"
> then ok - but until it gets wide spread adoption, and mind share, I
> can't agree that it should be covered in any more details. To be frank I
> think there the coverage in 303 is overboard. BTRFS and ZFS should have
> a much bigger weighting in the certs - but that is not relevant here :)
>
>
>
>
> --
> Mark Clarke
> 📱  +2711-781 8014
> 🌠  www.JumpingBean.co.za
>
> ___
> lpi-examdev mailing list
> lpi-examdev@lpi.org
> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
>
___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-21 Thread Bryan Smith
And if you're unaware ...

SuSE shipped OpenLDAP as it's pre-configured directory server (and very
well), but once acquired by Novell (now Attachment), they started pushing
their proprietary server. This was around the same time Red Hat acquired
iPlanet assets a dozen years ago.

Canonical has long just pushed people towards a couple of costly,
proprietary add-ons (we're talking CALs of US$100s per Linux system) to add
POSIX policies to AD DCs running Windows.

Samba doesn't address POSIX services, it's just a Windows client service,
even the DC is an AD/Windows-only capability, atop of a POSIX platform.
There is no AD facility to support the underlying POSIX platform, no
standard schema in AD to support POSIX platforms, and Identity Management
for UNIX (IDMU) only adds extremely basic user (iNetOrgPerson IETF 2307bis)
to AD, which is dropped in Win10/2016 Domain/Forest levels.

No, you have to manage POSIX attributes with POSIX schema in LDAP, ideally
with Certificate and Kerberos for both Security and Trust aspects.  So,
what is the *only* open source solution in the world that has done this?
The only one to introduces an "equivalent" to the NT LSA in SSSD, the only
one that handles a full, multi-domain, multi-tree, AD Forrest in Kerberos
Trusts (IPA Server) all while making Keys and POSIX Policy Objects cake to
push out to the POSIX clients (IPA Client, via SSSD)?

Name one other, 100% open source solution from client to server, and I'm
all ears.  Until then, distros have scrambled to add NSS/SSSD/IPA Client,
and desperately are trying to integrate 389/Dogtag/IPA Server, after years
of ignoring Red Hat overtures as they either tried to sell their
"proprietary" add-on, or ignored the problem altogether and relied on
proprietary 3rd parties.

That's the history, in-a-nutshell.

-- bjs

DISCLAIMER: Sent from phone, please excuse any typos
-- 
Bryan J Smith - Technology Mercenary
b.j.sm...@ieee.org - m...@bjsmith.me - http://linkedin.com/in/bjsmith


On Sep 21, 2016 06:58, "Bryan Smith"  wrote:

> They used to say the same thing about NSS/389/Dogtag.  Now every
> distribution is hacking in support for SSSD and IPA.  Why is that? ;)
>
> E.g.., how many people used to not only OpenLDAP was the only open source
> directory server, but say inherent, multi-master replication wasn't
> available or didn't work well?
>
> I. e., cannot help if people are unfamiliar, and distributions don't get
> enough maintainers to port it. The first time someone sees AD Forest Trusts
> at work, they are instantly drawn to it. Heck, just the SSSD portion draws
> them.
>
> So, let me re-iterate my point one more time ...
>
> AD Group Policy Objects (GPO) are used to manage Windows attributes. So
> why would we include them in a POSIX (UNIX/Linux) security exam?  There are
> no free or open source implementations that add POSIX support to GPOs, only
> proprietary solutions.
>
> Ergo ...
>
> If we're going to add any 'Policy' objectives to any POSIX security exam,
> they should be the POSIX attributes that can be stored in a LDAP set of
> schema instead.  And I'd argue the most 'standarized' set of 'Policy'
> Objects are the ones that cover certificates, SSH, sudoers, auto_home,
> etc...
>
> These were popularized in NSS/389/Dogtag (fka iPlanet 
> Security/Directory/Certificate,
> well proliferated in major installations), acquired by Red Hat in 2004,
> fully open sourced in 2005 (a few components were re-written), including
> its inherent, multi-master replication, and most people implement in
> Identity, Policy, Audit (IPA) out-of-the-box. Other than certificate, this
> schema can also be implemented in OpenLDAP as well.
>
> Most distributions have been hacking in SSSD/IPA support, after ignoring
> NSS/389/Dogtag for a decade, because unlike Samba-Winbindd/OpenLDAP, it
> actually addresses a crapload of interoperability and security issues, let
> alone provides a "canned" Policy set that is a serious PITA to setup in a
> generic LDAP server, like OpenLDAP or 389 itself for that matter.  It was
> also, heavily written by Samba maintainers, especially IPAv3 components
> that add AD Forest Trusts.
>
> Because AD schema isn't designed for POSIX attributes, but Windows ones.
> And in an AD Forest, all domains and systems have to have the same schema.
> Microsoft, prior to Windows 10 (Server 2016), only supports basic IETF
> RFC2307bis (IDMU), no POSIX Policy. And with 10/2016, they are dropping it.
>
> In other words ... one cannot store POSIX Policy Objects and Attributes in
> AD, so GPOs are useless for POSIX systems. Meanwhile, Microsoft has dropped
> even basic POSIX attributes from the latest AD/Server, because IPA exists
> with its AD Forest Trust. That way AD Forest can stay "pure Windows
> attributes" like 99% of AD architects expect (let alone too many AD admins
> are ignorant of), and all POSIX attributes and resources go into an IPA
> domain.
>
> Including Samba Servers being in an IPA domain, instead of AD. That way,
> via t

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-21 Thread Mark Clarke
On 21/09/2016 12:58, Bryan Smith wrote:
>
> They used to say the same thing about NSS/389/Dogtag.  Now every
> distribution is hacking in support for SSSD and IPA.  Why is that? ;)
>
> E.g.., how many people used to not only OpenLDAP was the only open
> source directory server, but say inherent, multi-master replication
> wasn't available or didn't work well?
>
> I. e., cannot help if people are unfamiliar, and distributions don't
> get enough maintainers to port it. The first time someone sees AD
> Forest Trusts at work, they are instantly drawn to it. Heck, just the
> SSSD portion draws them.
>
I wouldn't say NSS/389/Dogtag has been widely adopted outside RedHat yet
- it very well might be an emerging technology but its not something
every sys admin needs to know. If its included  at an "awareness level"
then ok - but until it gets wide spread adoption, and mind share, I
can't agree that it should be covered in any more details. To be frank I
think there the coverage in 303 is overboard. BTRFS and ZFS should have
a much bigger weighting in the certs - but that is not relevant here :)




--
Mark Clarke
📱  +2711-781 8014
�  www.JumpingBean.co.za
___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-21 Thread Bryan Smith
They used to say the same thing about NSS/389/Dogtag.  Now every
distribution is hacking in support for SSSD and IPA.  Why is that? ;)

E.g.., how many people used to not only OpenLDAP was the only open source
directory server, but say inherent, multi-master replication wasn't
available or didn't work well?

I. e., cannot help if people are unfamiliar, and distributions don't get
enough maintainers to port it. The first time someone sees AD Forest Trusts
at work, they are instantly drawn to it. Heck, just the SSSD portion draws
them.

So, let me re-iterate my point one more time ...

AD Group Policy Objects (GPO) are used to manage Windows attributes. So why
would we include them in a POSIX (UNIX/Linux) security exam?  There are no
free or open source implementations that add POSIX support to GPOs, only
proprietary solutions.

Ergo ...

If we're going to add any 'Policy' objectives to any POSIX security exam,
they should be the POSIX attributes that can be stored in a LDAP set of
schema instead.  And I'd argue the most 'standarized' set of 'Policy'
Objects are the ones that cover certificates, SSH, sudoers, auto_home,
etc...

These were popularized in NSS/389/Dogtag (fka iPlanet
Security/Directory/Certificate, well proliferated in major installations),
acquired by Red Hat in 2004, fully open sourced in 2005 (a few components
were re-written), including its inherent, multi-master replication, and
most people implement in Identity, Policy, Audit (IPA) out-of-the-box.
Other than certificate, this schema can also be implemented in OpenLDAP as
well.

Most distributions have been hacking in SSSD/IPA support, after ignoring
NSS/389/Dogtag for a decade, because unlike Samba-Winbindd/OpenLDAP, it
actually addresses a crapload of interoperability and security issues, let
alone provides a "canned" Policy set that is a serious PITA to setup in a
generic LDAP server, like OpenLDAP or 389 itself for that matter.  It was
also, heavily written by Samba maintainers, especially IPAv3 components
that add AD Forest Trusts.

Because AD schema isn't designed for POSIX attributes, but Windows ones.
And in an AD Forest, all domains and systems have to have the same schema.
Microsoft, prior to Windows 10 (Server 2016), only supports basic IETF
RFC2307bis (IDMU), no POSIX Policy. And with 10/2016, they are dropping it.

In other words ... one cannot store POSIX Policy Objects and Attributes in
AD, so GPOs are useless for POSIX systems. Meanwhile, Microsoft has dropped
even basic POSIX attributes from the latest AD/Server, because IPA exists
with its AD Forest Trust. That way AD Forest can stay "pure Windows
attributes" like 99% of AD architects expect (let alone too many AD admins
are ignorant of), and all POSIX attributes and resources go into an IPA
domain.

Including Samba Servers being in an IPA domain, instead of AD. That way,
via the AD Forest Trusts, the POSIX architects/admins can put AD Security
groups in IPA [Resource] Groups that have access to Samba shares.  All the
meanwhile, the same IPA domain can push down actual POSIX (UNIX/Linux)
policies on the actual POSIX/Samba server, something AD with it's GPOs
cannot do outside of the Samba server itself 'emulating" itself as a
Windows server (quite literally nothing).

I cannot help of people are wholly unfamiliar with how AD, GPOs,
schema/attributes (especially Windows v. IETF/POSIX) works, especially how
limited Samba is, and why many Samba contributors took 389/Dogtag and
basically invented AD for POSIX. Same thing goes for distributions that
snubbed NSS, and didn't integrate 389/Dogtag, but are now scrambling to add
SSSD/IPA because it's a killer service set that has no equal.

It's certainly not because Red Hat/Fedora doesn't put maintainers time on
other distributions (like a lot of what they do, even employer other
distributions maintainers), but because too many users don't work in huge,
corporate environments where 389/Dogtag already exists because of OpenLDAP
limitation, and now love what SSSD/IPA finally addresses.

Ignorance is bliss. ;)

-- bjs

DISCLAIMER: Sent from phone, please excuse any typos
-- 
Bryan J Smith - Technology Mercenary
b.j.sm...@ieee.org - m...@bjsmith.me - http://linkedin.com/in/bjsmith


On Sep 21, 2016 06:22, "Mark Clarke"  wrote:

> I don't do a lot of work with Samba, other than fairly vanilla
> implementations, but can comment on the IPA/FreeIPA that has been included
> in the security cert. The issue I have IPA/FreeIPA is the only distro that
> supports it is Fedora/Feroda and is largely unsupported in the rest of
> them. Seems like a distro specific feature?
>
> On 21/09/2016 06:11, Kenneth Peiruza wrote:
>
> Hi,
>
> Why do we have openldap on the same course as Samba?
>
> We lost t'he 'centralized auth' ldap part when LPIC 301 passed away.
>
> IMHO, FreeIPA would make a lot more sense in this de facto 'Centralized
> Authentication Services' LPIc rather than in LPIc 3 security.
>
> Regards,
>
>
>
> Sent from my Mi phone
> On Bryan Smi

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-21 Thread Mark Clarke
I don't do a lot of work with Samba, other than fairly vanilla
implementations, but can comment on the IPA/FreeIPA that has been
included in the security cert. The issue I have IPA/FreeIPA is the only
distro that supports it is Fedora/Feroda and is largely unsupported in
the rest of them. Seems like a distro specific feature?

On 21/09/2016 06:11, Kenneth Peiruza wrote:
> Hi,
>
> Why do we have openldap on the same course as Samba?
>
> We lost t'he 'centralized auth' ldap part when LPIC 301 passed away.
>
> IMHO, FreeIPA would make a lot more sense in this de facto
> 'Centralized Authentication Services' LPIc rather than in LPIc 3 security.
>
> Regards,
>
>
>
> Sent from my Mi phone
> On Bryan Smith , Sep 20, 2016 2:41 AM wrote:
>
> Policies?  That's really a 100% Windows client aspect.
>
> I don't see how it has anything to do with POSIX (UNIX/Linux), and
> requires an entire discussion of Windows client assumptions, from the
> NT Local Security Authority (LSA) on down.  Furthermore, on the AD
> Forest side, even Samba4 has limited, AD Forest support and related
> tree/domain delegation/trust.  Most of its limited support has been
> hacked in from IPA contributions (long story).  It's really a topic
> for Microsoft's dedicated policy and security exams in their tracks.
>
> Again, it's a Windows aspect, because AD schema is only designed to
> manage Windows schema.**  The only non-Windows, like POSIX, support
> with Policy Objects are all costly, proprietary add-ons.  I haven't
> seen a free one yet.  The free ones only provide similar functionality
> to SSSD and, more legcy, Winbindd.  And even when it comes to basic
> IETF 2307bis -- aka Identity Management for UNIX (IDMU), Microsoft has
> announced they are no longer going to provide it with Windows 10.**
>
> -- bjs
>
> **P.S.  In-a-nutshell, Microsoft has all but agreed Red Hat has the
> right idea by using IPA domains, keeping POSIX objects and schema
> _away_ from AD, because AD admins don't install/use IDMU, much less
> populate.  It's much easier to use AD Forest Trusts between AD domains
> and IPA domains, with AD admins designating what AD resources external
> IPA groups have access to, and vice-versa.
>
> On Mon, Sep 19, 2016 at 8:11 PM, alexbm...@gmail.com
> 
> mailto:alexbm...@gmail.com>> wrote:
> > Gentlemen,
> >
> > It would be interesting to insert GPO referring to samba.
> >
> > To: Relevance of NT4 domains vs. AD domains.
> >
> >
> >
> >
> >
> >
> > On 09/18/2016 01:07 PM, Bryan Smith wrote:
> >
> > Well, Samba 3 and Samba 4 aren't much different.  The protocol in
> > Samba 4 is the same as Samba 3.
> >
> > Samba 4 introduces the DC option, but not all distros include it.
> > E.g., Red Hat has gone the IPA route for AD Forest Trusts,
> instead of
> > allowing a Samba Server to be a DC in a native AD Forest.
> >
> >
> > On Sun, Sep 18, 2016 at 9:17 AM, G. Matthew Rice
> mailto:m...@starnix.com>> wrote:
> >
> > +1 for these changes...samba 3 should definitely go.
> >
> > I know there are a lot of samba3 installs still out therebut
> there
> > shouldn't be. :)
> >
> >
> > On Sep 17, 2016 2:17 PM, "Fabian Thorns"  > wrote:
> >
> > Dear all,
> >
> > taking a look at
> >
> >   https://wiki.lpi.org/wiki/LPIC-3_300_Objectives_V1
> >
> > You will notice that it's time to review the current LPIC-300
> objectives
> > to ensure they are still up to date. Therefore I'd like you all
> to share
> > your thoughts about our current objectives with the list,
> including wishes
> > what should be changed in the next update. We have however to
> obey that it
> > will be "minor update", so we can't fundamentally turn the while
> exam
> > around.
> >
> > Some things we should discuss from my point of view would be:
> >
> >  * Relevance of NT4 domains vs. AD domains
> >  * Same for NBNS vs. DNS
> >  * Shift from Samba 3 to Samba 4 (which shouldn't cause too much
> trouble,
> > though)
> >
> > However, I don't want to limit the discussion on these points.
> Just go
> > ahead and point out what you think. As usual, I will comment
> when necessary
> > and condense all the comments into a draft for potential updated
> objectives
> > which we will then review altogether again.
> >
> > Looking forward to an interesting discussion,
> >
> > Fabian
> >
> >
> > ___
> > lpi-examdev mailing list
> > lpi-examdev@lpi.org 
> > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
> >
> > ___

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-20 Thread Kenneth Peiruza
Hi,

Why do we have openldap on the same course as Samba?

We lost t'he 'centralized auth' ldap part when LPIC 301 passed away.

IMHO, FreeIPA would make a lot more sense in this de facto 'Centralized Authentication Services' LPIc rather than in LPIc 3 security.

Regards,



Sent from my Mi phoneOn Bryan Smith , Sep 20, 2016 2:41 AM wrote:Policies?  That's really a 100% Windows client aspect.
I don't see how it has anything to do with POSIX (UNIX/Linux), and
requires an entire discussion of Windows client assumptions, from the
NT Local Security Authority (LSA) on down.  Furthermore, on the AD
Forest side, even Samba4 has limited, AD Forest support and related
tree/domain delegation/trust.  Most of its limited support has been
hacked in from IPA contributions (long story).  It's really a topic
for Microsoft's dedicated policy and security exams in their tracks.
Again, it's a Windows aspect, because AD schema is only designed to
manage Windows schema.**  The only non-Windows, like POSIX, support
with Policy Objects are all costly, proprietary add-ons.  I haven't
seen a free one yet.  The free ones only provide similar functionality
to SSSD and, more legcy, Winbindd.  And even when it comes to basic
IETF 2307bis -- aka Identity Management for UNIX (IDMU), Microsoft has
announced they are no longer going to provide it with Windows 10.**
-- bjs
**P.S.  In-a-nutshell, Microsoft has all but agreed Red Hat has the
right idea by using IPA domains, keeping POSIX objects and schema
_away_ from AD, because AD admins don't install/use IDMU, much less
populate.  It's much easier to use AD Forest Trusts between AD domains
and IPA domains, with AD admins designating what AD resources external
IPA groups have access to, and vice-versa.
On Mon, Sep 19, 2016 at 8:11 PM, alexbm...@gmail.com
 wrote:
> Gentlemen,
>
> It would be interesting to insert GPO referring to samba.
>
> To: Relevance of NT4 domains vs. AD domains.
>
>
>
>
>
>
> On 09/18/2016 01:07 PM, Bryan Smith wrote:
>
> Well, Samba 3 and Samba 4 aren't much different.  The protocol in
> Samba 4 is the same as Samba 3.
>
> Samba 4 introduces the DC option, but not all distros include it.
> E.g., Red Hat has gone the IPA route for AD Forest Trusts, instead of
> allowing a Samba Server to be a DC in a native AD Forest.
>
>
> On Sun, Sep 18, 2016 at 9:17 AM, G. Matthew Rice  wrote:
>
> +1 for these changes...samba 3 should definitely go.
>
> I know there are a lot of samba3 installs still out therebut there
> shouldn't be. :)
>
>
> On Sep 17, 2016 2:17 PM, "Fabian Thorns"  wrote:
>
> Dear all,
>
> taking a look at
>
>   https://wiki.lpi.org/wiki/LPIC-3_300_Objectives_V1
>
> You will notice that it's time to review the current LPIC-300 objectives
> to ensure they are still up to date. Therefore I'd like you all to share
> your thoughts about our current objectives with the list, including wishes
> what should be changed in the next update. We have however to obey that it
> will be "minor update", so we can't fundamentally turn the while exam
> around.
>
> Some things we should discuss from my point of view would be:
>
>  * Relevance of NT4 domains vs. AD domains
>  * Same for NBNS vs. DNS
>  * Shift from Samba 3 to Samba 4 (which shouldn't cause too much trouble,
> though)
>
> However, I don't want to limit the discussion on these points. Just go
> ahead and point out what you think. As usual, I will comment when necessary
> and condense all the comments into a draft for potential updated objectives
> which we will then review altogether again.
>
> Looking forward to an interesting discussion,
>
> Fabian
>
>
> ___
> lpi-examdev mailing list
> lpi-examdev@lpi.org
> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
>
> ___
> lpi-examdev mailing list
> lpi-examdev@lpi.org
> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
>
>
>
> --
> Alex Clemente
> 11 979919870
> a.clementesi...@uol.com.br
> alexbm...@gmail.com
> Analista Linux e Unix
> Instrutor Linux e Open Source
> Alex Clemente
> 11 979919870
> a.clementesi...@uol.com.br
> alexbm...@gmail.com
> Analista Linux e Unix
> Instrutor Linux e Open Source
> Linux+ – CompTIA Linux+ (Powered by LPI)
> SUSE CLA 11 – Certified Linux Administrator
> SUSE CLP 12 – Certified Linux Professional
> SUSE 11 Tech Espec – Technical Especialist
> LPIC-1 – Linux Professional Institute Certified Level 1
> LPIC-2 – Linux Professional Institute Certified Level 2
>
>
> ___
> lpi-examdev mailing list
> lpi-examdev@lpi.org
> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
-- 
--
Bryan J Smith  -  http://www.linkedin.com/in/bjsmith
E-mail:  b.j.smith at ieee.org  or  me at bjsmith.me
___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-20 Thread mwienstroer39194
I agree with Bryan,
it should not be part of the LPI certifications because it is microsofts part.
>From my point of view maybe MS should include it but not LPI.
>From my point of view the only part is the mixed environment component. 
How samba could interact with MS domains.
A whole domain with samba is from my point if view not the best way. Why?
If you want an AD, then go and buy MS stuff. No problem.
But if you want it another way then use LDAP or some kind of other stuff.

So from my point of view we should have a look that we are not trying to 
simulate an AD copy in a LPI exam.
LPI and Linux is much more than that :-)


Regards



Maik

 

 

 

-Original Message-
From: Bryan Smith 
To: This is the lpi-examdev mailing list. 
Sent: Tue, Sep 20, 2016 2:42 am
Subject: Re: [lpi-examdev] LPIC-300 Objective Discussion

Typo ...

" ... Again, it's a Windows aspect, because AD schema is only designed
to manage Windows" ATTRIBUTES (not schema)

-- bjs
___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-19 Thread Bryan Smith
Typo ...

" ... Again, it's a Windows aspect, because AD schema is only designed
to manage Windows" ATTRIBUTES (not schema)

-- bjs
___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev


Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-19 Thread Bryan Smith
Policies?  That's really a 100% Windows client aspect.

I don't see how it has anything to do with POSIX (UNIX/Linux), and
requires an entire discussion of Windows client assumptions, from the
NT Local Security Authority (LSA) on down.  Furthermore, on the AD
Forest side, even Samba4 has limited, AD Forest support and related
tree/domain delegation/trust.  Most of its limited support has been
hacked in from IPA contributions (long story).  It's really a topic
for Microsoft's dedicated policy and security exams in their tracks.

Again, it's a Windows aspect, because AD schema is only designed to
manage Windows schema.**  The only non-Windows, like POSIX, support
with Policy Objects are all costly, proprietary add-ons.  I haven't
seen a free one yet.  The free ones only provide similar functionality
to SSSD and, more legcy, Winbindd.  And even when it comes to basic
IETF 2307bis -- aka Identity Management for UNIX (IDMU), Microsoft has
announced they are no longer going to provide it with Windows 10.**

-- bjs

**P.S.  In-a-nutshell, Microsoft has all but agreed Red Hat has the
right idea by using IPA domains, keeping POSIX objects and schema
_away_ from AD, because AD admins don't install/use IDMU, much less
populate.  It's much easier to use AD Forest Trusts between AD domains
and IPA domains, with AD admins designating what AD resources external
IPA groups have access to, and vice-versa.



On Mon, Sep 19, 2016 at 8:11 PM, alexbm...@gmail.com
 wrote:
> Gentlemen,
>
> It would be interesting to insert GPO referring to samba.
>
> To: Relevance of NT4 domains vs. AD domains.
>
>
>
>
>
>
> On 09/18/2016 01:07 PM, Bryan Smith wrote:
>
> Well, Samba 3 and Samba 4 aren't much different.  The protocol in
> Samba 4 is the same as Samba 3.
>
> Samba 4 introduces the DC option, but not all distros include it.
> E.g., Red Hat has gone the IPA route for AD Forest Trusts, instead of
> allowing a Samba Server to be a DC in a native AD Forest.
>
>
> On Sun, Sep 18, 2016 at 9:17 AM, G. Matthew Rice  wrote:
>
> +1 for these changes...samba 3 should definitely go.
>
> I know there are a lot of samba3 installs still out therebut there
> shouldn't be. :)
>
>
> On Sep 17, 2016 2:17 PM, "Fabian Thorns"  wrote:
>
> Dear all,
>
> taking a look at
>
>   https://wiki.lpi.org/wiki/LPIC-3_300_Objectives_V1
>
> You will notice that it's time to review the current LPIC-300 objectives
> to ensure they are still up to date. Therefore I'd like you all to share
> your thoughts about our current objectives with the list, including wishes
> what should be changed in the next update. We have however to obey that it
> will be "minor update", so we can't fundamentally turn the while exam
> around.
>
> Some things we should discuss from my point of view would be:
>
>  * Relevance of NT4 domains vs. AD domains
>  * Same for NBNS vs. DNS
>  * Shift from Samba 3 to Samba 4 (which shouldn't cause too much trouble,
> though)
>
> However, I don't want to limit the discussion on these points. Just go
> ahead and point out what you think. As usual, I will comment when necessary
> and condense all the comments into a draft for potential updated objectives
> which we will then review altogether again.
>
> Looking forward to an interesting discussion,
>
> Fabian
>
>
> ___
> lpi-examdev mailing list
> lpi-examdev@lpi.org
> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
>
> ___
> lpi-examdev mailing list
> lpi-examdev@lpi.org
> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
>
>
>
> --
> Alex Clemente
> 11 979919870
> a.clementesi...@uol.com.br
> alexbm...@gmail.com
> Analista Linux e Unix
> Instrutor Linux e Open Source
> Alex Clemente
> 11 979919870
> a.clementesi...@uol.com.br
> alexbm...@gmail.com
> Analista Linux e Unix
> Instrutor Linux e Open Source
> Linux+ – CompTIA Linux+ (Powered by LPI)
> SUSE CLA 11 – Certified Linux Administrator
> SUSE CLP 12 – Certified Linux Professional
> SUSE 11 Tech Espec – Technical Especialist
> LPIC-1 – Linux Professional Institute Certified Level 1
> LPIC-2 – Linux Professional Institute Certified Level 2
>
>
> ___
> lpi-examdev mailing list
> lpi-examdev@lpi.org
> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev



-- 

--
Bryan J Smith  -  http://www.linkedin.com/in/bjsmith
E-mail:  b.j.smith at ieee.org  or  me at bjsmith.me
___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-19 Thread alexbm...@gmail.com

Gentlemen, It would be interesting to insert GPO referring to samba. To: 
Relevance of NT4 domains vs. AD domains.






On 09/18/2016 01:07 PM, Bryan Smith wrote:

Well, Samba 3 and Samba 4 aren't much different.  The protocol in
Samba 4 is the same as Samba 3.

Samba 4 introduces the DC option, but not all distros include it.
E.g., Red Hat has gone the IPA route for AD Forest Trusts, instead of
allowing a Samba Server to be a DC in a native AD Forest.


On Sun, Sep 18, 2016 at 9:17 AM, G. Matthew Rice  wrote:

+1 for these changes...samba 3 should definitely go.

I know there are a lot of samba3 installs still out therebut there
shouldn't be. :)


On Sep 17, 2016 2:17 PM, "Fabian Thorns"  wrote:

Dear all,

taking a look at

   https://wiki.lpi.org/wiki/LPIC-3_300_Objectives_V1

You will notice that it's time to review the current LPIC-300 objectives
to ensure they are still up to date. Therefore I'd like you all to share
your thoughts about our current objectives with the list, including wishes
what should be changed in the next update. We have however to obey that it
will be "minor update", so we can't fundamentally turn the while exam
around.

Some things we should discuss from my point of view would be:

  * Relevance of NT4 domains vs. AD domains
  * Same for NBNS vs. DNS
  * Shift from Samba 3 to Samba 4 (which shouldn't cause too much trouble,
though)

However, I don't want to limit the discussion on these points. Just go
ahead and point out what you think. As usual, I will comment when necessary
and condense all the comments into a draft for potential updated objectives
which we will then review altogether again.

Looking forward to an interesting discussion,

Fabian


___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev


___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev





--
Alex Clemente
11 979919870
a.clementesi...@uol.com.br
alexbm...@gmail.com
Analista Linux e Unix
Instrutor Linux e Open Source
Alex Clemente
11 979919870
a.clementesi...@uol.com.br
alexbm...@gmail.com
Analista Linux e Unix
Instrutor Linux e Open Source
Linux+ – CompTIA Linux+ (Powered by LPI)
SUSE CLA 11 – Certified Linux Administrator
SUSE CLP 12 – Certified Linux Professional
SUSE 11 Tech Espec – Technical Especialist
LPIC-1 – Linux Professional Institute Certified Level 1
LPIC-2 – Linux Professional Institute Certified Level 2

___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-18 Thread mwienstroer39194
Dear Fabian,
I got the same opinion like harald, you and some others.
NT4 is not supported from Microsoft, a long time ago.
AD is the only possibility. So NT4 should go.
As Harald said, NetBios is only part of compatibilty with old systems.
But this should be very rare. WINS should be the same.

The shift from Samba 3 to 4 is very welcome.

The other topics should be okay from my point of view.
I scrolled through all of it and they seems to be okay.


Regards



Maik Wienströer


 

 

 

-Original Message-
From: Fabian Thorns 
To: This is the lpi-examdev mailing list. 
Sent: Sat, Sep 17, 2016 8:17 pm
Subject: [lpi-examdev] LPIC-300 Objective Discussion



Dear all,


taking a look at 


  https://wiki.lpi.org/wiki/LPIC-3_300_Objectives_V1


You will notice that it's time to review the current LPIC-300 objectives to 
ensure they are still up to date. Therefore I'd like you all to share your 
thoughts about our current objectives with the list, including wishes what 
should be changed in the next update. We have however to obey that it will be 
"minor update", so we can't fundamentally turn the while exam around.


Some things we should discuss from my point of view would be:


 * Relevance of NT4 domains vs. AD domains
 * Same for NBNS vs. DNS
 * Shift from Samba 3 to Samba 4 (which shouldn't cause too much trouble, 
though)


However, I don't want to limit the discussion on these points. Just go ahead 
and point out what you think. As usual, I will comment when necessary and 
condense all the comments into a draft for potential updated objectives which 
we will then review altogether again.


Looking forward to an interesting discussion,


Fabian



___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-18 Thread Bryan Smith
Well, Samba 3 and Samba 4 aren't much different.  The protocol in
Samba 4 is the same as Samba 3.

Samba 4 introduces the DC option, but not all distros include it.
E.g., Red Hat has gone the IPA route for AD Forest Trusts, instead of
allowing a Samba Server to be a DC in a native AD Forest.


On Sun, Sep 18, 2016 at 9:17 AM, G. Matthew Rice  wrote:
> +1 for these changes...samba 3 should definitely go.
>
> I know there are a lot of samba3 installs still out therebut there
> shouldn't be. :)
>
>
> On Sep 17, 2016 2:17 PM, "Fabian Thorns"  wrote:
>>
>> Dear all,
>>
>> taking a look at
>>
>>   https://wiki.lpi.org/wiki/LPIC-3_300_Objectives_V1
>>
>> You will notice that it's time to review the current LPIC-300 objectives
>> to ensure they are still up to date. Therefore I'd like you all to share
>> your thoughts about our current objectives with the list, including wishes
>> what should be changed in the next update. We have however to obey that it
>> will be "minor update", so we can't fundamentally turn the while exam
>> around.
>>
>> Some things we should discuss from my point of view would be:
>>
>>  * Relevance of NT4 domains vs. AD domains
>>  * Same for NBNS vs. DNS
>>  * Shift from Samba 3 to Samba 4 (which shouldn't cause too much trouble,
>> though)
>>
>> However, I don't want to limit the discussion on these points. Just go
>> ahead and point out what you think. As usual, I will comment when necessary
>> and condense all the comments into a draft for potential updated objectives
>> which we will then review altogether again.
>>
>> Looking forward to an interesting discussion,
>>
>> Fabian
>>
>>
>> ___
>> lpi-examdev mailing list
>> lpi-examdev@lpi.org
>> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
>
>
> ___
> lpi-examdev mailing list
> lpi-examdev@lpi.org
> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev



-- 

--
Bryan J Smith  -  http://www.linkedin.com/in/bjsmith
E-mail:  b.j.smith at ieee.org  or  me at bjsmith.me
___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev


Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-18 Thread Harald Maaßen
+1 also from me. Now, that samba4 is almost 4 years old we should shift
to that.

What about getting rid of NetBIOS and WINS? They were developed for
NetBEUI and I think it's time to for them to go! They also do not show
up in Microsoft exams any more.



Am 18.09.2016 um 15:17 schrieb G. Matthew Rice:
>
> +1 for these changes...samba 3 should definitely go.
>
> I know there are a lot of samba3 installs still out therebut there
> shouldn't be. :)
>
>
> On Sep 17, 2016 2:17 PM, "Fabian Thorns"  > wrote:
>
> Dear all,
>
> taking a look at 
>
>   https://wiki.lpi.org/wiki/LPIC-3_300_Objectives_V1
> 
>
> You will notice that it's time to review the current LPIC-300
> objectives to ensure they are still up to date. Therefore I'd like
> you all to share your thoughts about our current objectives with
> the list, including wishes what should be changed in the next
> update. We have however to obey that it will be "minor update", so
> we can't fundamentally turn the while exam around.
>
> Some things we should discuss from my point of view would be:
>
>  * Relevance of NT4 domains vs. AD domains
>  * Same for NBNS vs. DNS
>  * Shift from Samba 3 to Samba 4 (which shouldn't cause too much
> trouble, though)
>
> However, I don't want to limit the discussion on these points.
> Just go ahead and point out what you think. As usual, I will
> comment when necessary and condense all the comments into a draft
> for potential updated objectives which we will then review
> altogether again.
>
> Looking forward to an interesting discussion,
>
> Fabian
>
>
> ___
> lpi-examdev mailing list
> lpi-examdev@lpi.org 
> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
> 
>
>
>
> ___
> lpi-examdev mailing list
> lpi-examdev@lpi.org
> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

Re: [lpi-examdev] LPIC-300 Objective Discussion

2016-09-18 Thread G. Matthew Rice
+1 for these changes...samba 3 should definitely go.

I know there are a lot of samba3 installs still out therebut there
shouldn't be. :)

On Sep 17, 2016 2:17 PM, "Fabian Thorns"  wrote:

> Dear all,
>
> taking a look at
>
>   https://wiki.lpi.org/wiki/LPIC-3_300_Objectives_V1
>
> You will notice that it's time to review the current LPIC-300 objectives
> to ensure they are still up to date. Therefore I'd like you all to share
> your thoughts about our current objectives with the list, including wishes
> what should be changed in the next update. We have however to obey that it
> will be "minor update", so we can't fundamentally turn the while exam
> around.
>
> Some things we should discuss from my point of view would be:
>
>  * Relevance of NT4 domains vs. AD domains
>  * Same for NBNS vs. DNS
>  * Shift from Samba 3 to Samba 4 (which shouldn't cause too much trouble,
> though)
>
> However, I don't want to limit the discussion on these points. Just go
> ahead and point out what you think. As usual, I will comment when necessary
> and condense all the comments into a draft for potential updated objectives
> which we will then review altogether again.
>
> Looking forward to an interesting discussion,
>
> Fabian
>
>
> ___
> lpi-examdev mailing list
> lpi-examdev@lpi.org
> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
>
___
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev