Re: [Freeipa-users] One way trusts

[Alexander Bokovoy]

On Wed, 15 Jan 2014, Petr Spacek wrote:

On 15.1.2014 06:49, Alexander Bokovoy wrote:

On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote:



Both AD integration solutions we have (synchronization and
cross-forest domain trusts) assume having higher level access
privileges at the time integration is set up.


My problem here is that I'm too ignorable. :) There's over 15000 users
in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD
is being absorbed into the next level up the chain (Forest Service AD
is going to become a part of the overall USDA AD). Then I'm an even
smaller fish, relatively speaking.


I'm unaware of other
mechanisms that would give you the same flexibility and level of
privilege separation between the AD and IPA domains.


?? The current solution using the LDAP interface to AD (and a
metadirectory to merge "external users") provides privilege separation
and the flexibility to add external users. I don't need more; I just
need it to be less clunky. It weakens security, of course, as my AD
password is stored in various plaintext configuration files for each
application needing binding credentials to search for users in AD. I
also have an index to which files contain my password, as it forms a
"password-change-checklist" which I need to run thru every 60 days.

You got me confused on this. You cannot run FreeIPA in such mode because
FreeIPA is not a client-only solution, it is server and client solution.
If you want to stay with an approach where AD is the data source, IPA
server part will not be usable to you and what left is SSSD on the
client side.

SSSD is capable to work as an AD client.

However, if you want all your Linux machines to be enrolled to IPA, they
cannot be enrolled to AD at the same time, this will not work.


Alexander and Jakub, would it be possible to enroll a machine as IPA 
client and then manually add AD domain do SSSD configuration?


I guess that this configuration theoretically allows to use one set 
of users ("external" users) from IPA and also use another set of 
users ("internal" users) from AD at the same time. The obvious 
disadvantage is that you have to carefully type username@DOMAIN.


This naturally does 'separation' of external and internal users 
because AD would know nothing about IPA users and the other way 
around.


Could it work? I'm just theorizing ... :-)

You can setup SSSD to use multiple sources and you can setup krb5.conf
to serve multiple realms. What you cannot do is to mix and match within
the same DNS namespace over multiple Kerberos realms without being
prepared to things not working now and then.

Suppose you have example.com DNS namespace and four machines:
dc.example.com, win.example.com, lnx.example.com, and ipa.example.com.
They are AD DC, Windows machine, Linux server, and IPA master.

dc.example.com would host Active Directory and own example.com DNS
namespace, including DNS server which hosts example.com zone. Kerberos
realm for AD will be EXAMPLE.COM

ipa.example.com would host IPA master: LDAP server, KDC for IPA realm,
DNS server for example.com with IPA entries. You'd need to define
different Kerberos realm name since you'll need to have different
configurations in krb5.conf on your lnx.example.com. Let's say, it is
IPA-EXAMPLE.COM.

win.example.com is enrolled to AD. It consults dc.example.com for DNS
and Kerberos on logon. It will attempt to get Kerberos tickets to any
service in .example.com through Active Directory domain controller
dc.example.com.

lnx.example.com is enrolled to IPA. You can either manually set up
configuration to point to ipa.example.com everywhere where needed
(through /etc/hosts, /etc/krb5.conf, /etc/sssd/sssd.conf, ...) or point
/etc/resolv.conf to ipa.example.com and assume that split-brain DNS will
work when communicating with win.example.com.

lnx.example.com could be configured to have a second domain in
/etc/sssd/sssd.conf that points to dc.example.com. You need to create a
computer object for lnx.example.com in AD, you need to fetch service
key for host/lnx.example@example.com from AD, and later
maintain it refresh over time but it is possible.

The very same is needed for IPA side. I think we already had discussion
on this list how to setup SSSD with two different domains pointing to
different Kerberos realms last week but in that case there were
non-overlapping DNS namespaces for both Kerberos realms.

Now, when an SSH client (PuTTY) on win.example.com will want to connect
to lnx.example.com, AD DC on dc.example.com would issue Kerberos ticket
to service host/lnx.example@example.com based on own AD credentials.
One will be able to login with this ticket to lnx.example.com but
nothing from IPA side will apply here: sudo and HBAC rules don't know
anything about these users and authentication source.

In such situation what I question is the need for IPA deployment at all.
If all users will be coming from AD and they are not visible to IPA and
not using IPA features, wh

Re: [Freeipa-users] One way trusts

[Petr Spacek]

On 15.1.2014 06:49, Alexander Bokovoy wrote:

On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote:



Both AD integration solutions we have (synchronization and
cross-forest domain trusts) assume having higher level access
privileges at the time integration is set up.


My problem here is that I'm too ignorable. :) There's over 15000 users
in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD
is being absorbed into the next level up the chain (Forest Service AD
is going to become a part of the overall USDA AD). Then I'm an even
smaller fish, relatively speaking.


I'm unaware of other
mechanisms that would give you the same flexibility and level of
privilege separation between the AD and IPA domains.


?? The current solution using the LDAP interface to AD (and a
metadirectory to merge "external users") provides privilege separation
and the flexibility to add external users. I don't need more; I just
need it to be less clunky. It weakens security, of course, as my AD
password is stored in various plaintext configuration files for each
application needing binding credentials to search for users in AD. I
also have an index to which files contain my password, as it forms a
"password-change-checklist" which I need to run thru every 60 days.

You got me confused on this. You cannot run FreeIPA in such mode because
FreeIPA is not a client-only solution, it is server and client solution.
If you want to stay with an approach where AD is the data source, IPA
server part will not be usable to you and what left is SSSD on the
client side.

SSSD is capable to work as an AD client.

However, if you want all your Linux machines to be enrolled to IPA, they
cannot be enrolled to AD at the same time, this will not work.


Alexander and Jakub, would it be possible to enroll a machine as IPA client 
and then manually add AD domain do SSSD configuration?


I guess that this configuration theoretically allows to use one set of users 
("external" users) from IPA and also use another set of users ("internal" 
users) from AD at the same time. The obvious disadvantage is that you have to 
carefully type username@DOMAIN.


This naturally does 'separation' of external and internal users because AD 
would know nothing about IPA users and the other way around.


Could it work? I'm just theorizing ... :-)

Petr^2 Spacek


If I might try to repeat the problem back to you to see if I got it
right...the factor which requires access to the corporate AD is setting
up a Kerberos cross realm trust. This is required so that machines in
IPA can connect directly to AD for authentication. This in turn is
necessary so that identities in the AD Kerberos Realm are correctly and
consistently identified as being sourced from AD. And of course, this
requirement is necessary for services in AD to recognize users and
groups in AD.

Let me ask what is probably a series of dumb questions: What do I lose
if my FreeIPA server is set up as one of the 10 machines I can join to
the network as a regular user, and all the machines in IPA connect
directly to IPA? Could FreeIPA (current or future) be configured to
relay the credentials to AD either via Kerberos or using AD's LDAP
interface (binding as itself because it's joined to the AD domain)?  If
AD accepts the provided credentials can FreeIPA issue the user a ticket
in the FreeIPA realm? Would this look to AD like a bunch of users are
logging into the FreeIPA server machine?

FreeIPA as a server provides own Kerberos realm. AD as a server provides
its own Kerberos realm. In addition,  FreeIPA cannot be made a part of
AD forest due to implementation limitations which are not solved yet. We
choose to go with cross-realm trust in which FreeIPA and AD belong to
different forests and trust each other through cross-forest domain trust
in AD speak.

One of implementation details of Kerberos in Active Directory is the
fact that it assumes Kerberos realm is governing DNS namespace. At one
DNS namespace level there could be only one Kerberos realm. If you have
example.com DNS namespace under AD control, no machine in .example.com
can belong to another Kerberos realm -- AD will not issue tickets for
services in that realm even though it would trust it. .ipa.example.com
can be used along with .example.com but there is no way to have
foo.example.com in AD and bar.example.com in IPA and communicate over
Kerberos.

What you are talking about is living in AD namespace (both Kerberos and
DNS) and yet somehow have FreeIPA working with AD users. This is not
possible.

If you want to use Linux clients in AD environments you can use SSSD on
Linux directly connected to AD, without FreeIPA. This way, of course,
you will not get any of FreeIPA benefits like access controls through
HBAC rules and sudo rules.

Dmitri had a talk last week outlining AD integration options we have:
http://www.freeipa.org/images/1/1e/Devconf2013-linux-ad-integration-options.pdf
http://www.youtube.com/watch?v=cS6EJ1L7fRI


I know this arrang

Re: [Freeipa-users] Odd problem with SSSD and SSH keys

[Simo Sorce]

On Tue, 2014-01-14 at 06:46 -0500, Bret Wortman wrote:
> I was assuming that the key was being re-inserted by the ssh 
> authentication request, but to eliminate puppet, I just tried this sequence:
> 
> # puppet agent --disable
> # rm -f /var/lib/sss/pubconf/known_hosts
> # ls -l /var/lib/sss/pubconf/known_hosts
> # ssh zw131
> :
> : (errors about the key being incorrect)
> :
> # cat /var/lib/sss/pubconf/known_hosts
> :
> 
> it now contained the bad key again.

Just a shot in the dark.
Your log files say ' host "rs512" ', are you having reverse DNS issues ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)

[Alexander Bokovoy]

On Wed, 15 Jan 2014, Les Stott wrote:

I can confirm that the password was typed in correctly. Maybe its not
matching the account because it's the compat tree?

No, it is not matching because BIND over compat tree is only supported
with slapi-nis 0.48+ which is not RHEL 6.x feature. As Dmitri said, it
is feature available with FreeIPA 3.3.x, not 3.0.

--
/ Alexander Bokovoy

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] One way trusts

[Alexander Bokovoy]

On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote:



Both AD integration solutions we have (synchronization and
cross-forest domain trusts) assume having higher level access
privileges at the time integration is set up.


My problem here is that I'm too ignorable. :) There's over 15000 users
in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD
is being absorbed into the next level up the chain (Forest Service AD
is going to become a part of the overall USDA AD). Then I'm an even
smaller fish, relatively speaking.


I'm unaware of other
mechanisms that would give you the same flexibility and level of
privilege separation between the AD and IPA domains.


?? The current solution using the LDAP interface to AD (and a
metadirectory to merge "external users") provides privilege separation
and the flexibility to add external users. I don't need more; I just
need it to be less clunky. It weakens security, of course, as my AD
password is stored in various plaintext configuration files for each
application needing binding credentials to search for users in AD. I
also have an index to which files contain my password, as it forms a
"password-change-checklist" which I need to run thru every 60 days.

You got me confused on this. You cannot run FreeIPA in such mode because
FreeIPA is not a client-only solution, it is server and client solution.
If you want to stay with an approach where AD is the data source, IPA
server part will not be usable to you and what left is SSSD on the
client side.

SSSD is capable to work as an AD client.

However, if you want all your Linux machines to be enrolled to IPA, they
cannot be enrolled to AD at the same time, this will not work.


If I might try to repeat the problem back to you to see if I got it
right...the factor which requires access to the corporate AD is setting
up a Kerberos cross realm trust. This is required so that machines in
IPA can connect directly to AD for authentication. This in turn is
necessary so that identities in the AD Kerberos Realm are correctly and
consistently identified as being sourced from AD. And of course, this
requirement is necessary for services in AD to recognize users and
groups in AD.

Let me ask what is probably a series of dumb questions: What do I lose
if my FreeIPA server is set up as one of the 10 machines I can join to
the network as a regular user, and all the machines in IPA connect
directly to IPA? Could FreeIPA (current or future) be configured to
relay the credentials to AD either via Kerberos or using AD's LDAP
interface (binding as itself because it's joined to the AD domain)?  If
AD accepts the provided credentials can FreeIPA issue the user a ticket
in the FreeIPA realm? Would this look to AD like a bunch of users are
logging into the FreeIPA server machine?

FreeIPA as a server provides own Kerberos realm. AD as a server provides
its own Kerberos realm. In addition,  FreeIPA cannot be made a part of
AD forest due to implementation limitations which are not solved yet. We
choose to go with cross-realm trust in which FreeIPA and AD belong to
different forests and trust each other through cross-forest domain trust
in AD speak.

One of implementation details of Kerberos in Active Directory is the
fact that it assumes Kerberos realm is governing DNS namespace. At one
DNS namespace level there could be only one Kerberos realm. If you have
example.com DNS namespace under AD control, no machine in .example.com
can belong to another Kerberos realm -- AD will not issue tickets for
services in that realm even though it would trust it. .ipa.example.com
can be used along with .example.com but there is no way to have
foo.example.com in AD and bar.example.com in IPA and communicate over
Kerberos.

What you are talking about is living in AD namespace (both Kerberos and
DNS) and yet somehow have FreeIPA working with AD users. This is not
possible.

If you want to use Linux clients in AD environments you can use SSSD on
Linux directly connected to AD, without FreeIPA. This way, of course,
you will not get any of FreeIPA benefits like access controls through
HBAC rules and sudo rules.

Dmitri had a talk last week outlining AD integration options we have:
http://www.freeipa.org/images/1/1e/Devconf2013-linux-ad-integration-options.pdf
http://www.youtube.com/watch?v=cS6EJ1L7fRI


I know this arrangement would sacrifice access to any of the AD
services by AD-users-on-the-IPA network. That's fine. If it's
technically feasible, tho, it gives me one server that can authenticate
both "corporate users" and "external users", and a central
administration point for the external network. It also plainly
differentiates between corporate users logged in on the corporate
network, and corporate users logged in on the "external network". I'd
consider that a good thing. Finally, if this is possible, it seems to
me that this stands a chance of reducing the number of places my
password is stored in plaintext.

I wish it could be so simple...

--
/ 

Re: [Freeipa-users] sudo log errors

[Simo Sorce]

On Tue, 2014-01-14 at 11:34 -0500, Dmitri Pal wrote:
> On 01/14/2014 06:17 AM, Natxo Asenjo wrote:
> > hi,
> >
> > after using sudo from ipa extensively I needed to configure a local
> > user to also use sudo.
> >
> > This is for monitoring, we use nagios.
> >
> > It works but now I have lots of error messages in /var/log/messages
> > like this one:
> >
> > sudo: GSSAPI Error: Unspecified GSS failure.  Minor code may provide
> > more information (Credentials cache file '/tmp/krb5cc_0' not found)
> >
> > Well, yes, obviously the nagios local user does not have a kerberos
> > ticket. Why the error?
> >
> > I modified /etc/sudoers to allow the nagios user to not use a tty:
> >
> > Defaults:nagios !requiretty
> >
> > And have added nagios config files for sudo in /etc/sudoers.d/
> >
> > nagios  ALL=NOPASSWD: /usr/lib/nagios/plugins/check_logfiles
> >
> > In /etc/nsswitch.conf, sudo looks like this:
> >
> > sudoers:files ldap
> >
> > Is there anything else I can do or do I just have to live with the
> > error on syslog?

> I wonder if putting this user into the local sssd provider would silence
> it... Just a thought...

Probably not, the question is, why is sudo trying to use roots kerberos
credentials ?

On what platform are you ? With sudo-sssd integration you shouldn't use
directly ldap anymore.

However if you need, what you can do is to have a cronjob generate the 
/tmp/krb5cc_0 ccache from the machine keytab. This will silence the
error, although it will turn into a full bind and search of data in
LDAP. Not sure which you prefer.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)

[Les Stott]

I can confirm that the password was typed in correctly. Maybe its not matching 
the account because it's the compat tree?

Also, each authentication tries multiple bind combinations, 3 or 4 different 
combinations show up in the logs for 1 authentication attempt.

>From the ILO help.."iLO attempts to contact the directory service by 
>distinguished name, and then applies the search contexts in order until 
>successful."

I'm beginning to think this is too hardwould hate to have to fall back to 
AD instead for central auth for ILO.

Regards,

Les

From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, 15 January 2014 2:13 PM
To: Les Stott; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)

On 01/14/2014 07:57 PM, Les Stott wrote:
Still no joy. Although I don't profess to be a schema changing expert.

Compat plugin was already enabled. Ipa version is 3.0.0-37.el6

So I modified /etc/dirsrv/slapd-MYDOMAIN-COM/dse.ldif...

Under
dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
I set the following...
schema-compat-entry-attribute: cn=%{cn}
schema-compat-entry-rdn: cn=%{cn}

Left the rest as default.
When I ldapsearch against the compat tree, I see it working the way I want 
(i.e. dn starts with cn instead of uid).
ldapsearch -x -b "cn=compat,dc=mydomain,dc=com" "cn=Les Stott"
# Les Stott, users, compat, mydomain.com
dn: cn=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com

ILO Search context was set as: cn=users,cn=compat,dc=mydomain,dc=com


So it looks good, but when I test from ILO it fails still.
Try..
Les Stott
...It cant bind

[14/Jan/2014:21:52:31 -0500] conn=47 op=0 BIND dn="CN=Les 
Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2
[14/Jan/2014:21:52:31 -0500] conn=47 op=0 RESULT err=49 tag=97 nentries=0 
etime=0
[14/Jan/2014:21:52:31 -0500] conn=47 op=1 UNBIND
[14/Jan/2014:21:52:31 -0500] conn=48 op=0 BIND dn="Les Stott" authzid="(null)", 
invalid bind dn
[14/Jan/2014:21:52:31 -0500] conn=48 op=0 RESULT err=34 tag=97 nentries=0 
etime=0
[14/Jan/2014:21:52:31 -0500] conn=48 op=1 BIND dn="CN=Les 
Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2
[14/Jan/2014:21:52:31 -0500] conn=48 op=1 RESULT err=49 tag=97 nentries=0 
etime=0
[14/Jan/2014:21:52:31 -0500] conn=48 op=2 UNBIND
[14/Jan/2014:21:52:31 -0500] conn=50 op=0 BIND dn="CN=Les 
Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2
[14/Jan/2014:21:52:31 -0500] conn=50 op=0 RESULT err=49 tag=97 nentries=0 
etime=0
[14/Jan/2014:21:52:31 -0500] conn=50 op=1 UNBIND


Is it just not supporting to bind against the compat tree in 3.0.0.37? or am I 
doing something wrong?

Not sure, but err=49 means wrong password, and err=34 means invalid DN ("Les 
Stott" is not a DN).



Regards,

Les


From: Dmitri Pal [mailto:d...@redhat.com]
Sent: Wednesday, 15 January 2014 8:36 AM
To: Les Stott
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)

On 01/14/2014 04:01 PM, Les Stott wrote:
I had seen that thread... 
https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html

all it says is...

On 11/05/2013 02:51 PM, KodaK wrote:
If I use the whole connection string:

uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com

I can authenticate.
Which i can do successfully, but its not great to have to tell everyone your 
username for ilo is uid=blah,cn=users,cn=accounts..etc

There is also mentioned in that thread...

"The HP iLO documentation doesn't list using the uid value as a supported form 
of specifying the login.  You can use the CN value or the full DN.  They say 
that "DOMAIN\user" and "user domain" forms are also accepted, but that likely 
only works against Active Directory."

CN doesn't work. full DN does.

I don't see any reference to a workaround via compat plugin in that thread.

Have you got any more info on the compat workaround?

You can create a compat tree using compat plugin of IPA. It is used for NIS, 
support of Solaris clients and for AD trusts in latest IPA.
As a simple test you can enable the plugin:

ipa-compat-manage enable



That will expose the tree on the cn=compat hive but using 2307 schema.

You can then change the configuration of the plugin to use uid value instead of 
CN in this view, i.e expose CN as uid.

Then you can point your HP ILO to that tree.



AFAIU in the past it was not possible because we did not allow bind against 
compat tree but now we allow it so it should work with the latest IPA 3.3.x 
bits.



Details on how to change compat configuration can be found in the plugin 
configuration here:

https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc



I am not sure that would 100% work but IMO worth a shot.






Thanks,

Les

From: freeipa-users-boun...@redhat.com 
[freeipa-users-boun...@redhat.com

Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)

[Rich Megginson]

On 01/14/2014 07:57 PM, Les Stott wrote:


Still no joy. Although I don't profess to be a schema changing expert.

Compat plugin was already enabled. Ipa version is 3.0.0-37.el6

So I modified /etc/dirsrv/slapd-MYDOMAIN-COM/dse.ldif...

Under

dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config

I set the following...

schema-compat-entry-attribute: cn=%{cn}

schema-compat-entry-rdn: cn=%{cn}

Left the rest as default.

When I ldapsearch against the compat tree, I see it working the way I 
want (i.e. dn starts with cn instead of uid).


ldapsearch -x -b "cn=compat,dc=mydomain,dc=com" "cn=Les Stott"

# Les Stott, users, compat, mydomain.com

dn: cn=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com

ILO Search context was set as: cn=users,cn=compat,dc=mydomain,dc=com

So it looks good, but when I test from ILO it fails still.

Try..

Les Stott

...It cant bind

[14/Jan/2014:21:52:31 -0500] conn=47 op=0 BIND dn="CN=Les 
Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2


[14/Jan/2014:21:52:31 -0500] conn=47 op=0 RESULT err=49 tag=97 
nentries=0 etime=0


[14/Jan/2014:21:52:31 -0500] conn=47 op=1 UNBIND

[14/Jan/2014:21:52:31 -0500] conn=48 op=0 BIND dn="Les Stott" 
authzid="(null)", invalid bind dn


[14/Jan/2014:21:52:31 -0500] conn=48 op=0 RESULT err=34 tag=97 
nentries=0 etime=0


[14/Jan/2014:21:52:31 -0500] conn=48 op=1 BIND dn="CN=Les 
Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2


[14/Jan/2014:21:52:31 -0500] conn=48 op=1 RESULT err=49 tag=97 
nentries=0 etime=0


[14/Jan/2014:21:52:31 -0500] conn=48 op=2 UNBIND

[14/Jan/2014:21:52:31 -0500] conn=50 op=0 BIND dn="CN=Les 
Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2


[14/Jan/2014:21:52:31 -0500] conn=50 op=0 RESULT err=49 tag=97 
nentries=0 etime=0


[14/Jan/2014:21:52:31 -0500] conn=50 op=1 UNBIND

Is it just not supporting to bind against the compat tree in 3.0.0.37? 
or am I doing something wrong?




Not sure, but err=49 means wrong password, and err=34 means invalid DN 
("Les Stott" is not a DN).



Regards,

Les

*From:*Dmitri Pal [mailto:d...@redhat.com]
*Sent:* Wednesday, 15 January 2014 8:36 AM
*To:* Les Stott
*Cc:* freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] HP ILO Authentication via LDAP (or even 
kerberos)


On 01/14/2014 04:01 PM, Les Stott wrote:

I had seen that thread... 
https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html


all it says is...

On 11/05/2013 02:51 PM, KodaK wrote:

If I use the whole connection string:

uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com

I can authenticate.

Which i can do successfully, but its not great to have to tell 
everyone your username for ilo is uid=blah,cn=users,cn=accounts..etc


There is also mentioned in that thread...

"The HP iLO documentation doesn't list using the uid value as a 
supported form of specifying the login.  You can use the CN value or 
the full DN.  They say that "DOMAIN\user" and "user domain" forms are 
also accepted, but that likely only works against Active Directory."


CN doesn't work. full DN does.

I don't see any reference to a workaround via compat plugin in that 
thread.


Have you got any more info on the compat workaround?


You can create a compat tree using compat plugin of IPA. It is used 
for NIS, support of Solaris clients and for AD trusts in latest IPA.

As a simple test you can enable the plugin:

ipa-compat-manage enable
  
That will expose the tree on the cn=compat hive but using 2307 schema.

You can then change the configuration of the plugin to use uid value instead of 
CN in this view, i.e expose CN as uid.
Then you can point your HP ILO to that tree.
  
AFAIU in the past it was not possible because we did not allow bind against compat tree but now we allow it so it should work with the latest IPA 3.3.x bits.
  
Details on how to change compat configuration can be found in the plugin configuration here:

https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc
  
I am not sure that would 100% work but IMO worth a shot.
  





Thanks,

Les



*From:*freeipa-users-boun...@redhat.com 
 
[freeipa-users-boun...@redhat.com 
] on behalf of Dmitri Pal 
[d...@redhat.com ]

*Sent:* Wednesday, January 15, 2014 3:30 AM
*To:* freeipa-users@redhat.com 
*Subject:* Re: [Freeipa-users] HP ILO Authentication via LDAP (or even 
kerberos)


On 01/13/2014 10:44 PM, Les Stott wrote:

Been banging my head against the wall on this one for a few days, 
trying to get a workable configuration for HP ILO to authenticate via 
FreeIPA.


I have a standard rhel6 environment (64 bit 6.4) with freeipa server 
(ipa-3.0.0-37.el6).


The following works for me..

HP ILO4 Firmware 1.22

Default Directory Schema

Directory Server Address: fqdn_of_myfreeipaserver

Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)

[Les Stott]

Still no joy. Although I don't profess to be a schema changing expert.

Compat plugin was already enabled. Ipa version is 3.0.0-37.el6

So I modified /etc/dirsrv/slapd-MYDOMAIN-COM/dse.ldif...

Under
dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
I set the following...
schema-compat-entry-attribute: cn=%{cn}
schema-compat-entry-rdn: cn=%{cn}

Left the rest as default.
When I ldapsearch against the compat tree, I see it working the way I want 
(i.e. dn starts with cn instead of uid).
ldapsearch -x -b "cn=compat,dc=mydomain,dc=com" "cn=Les Stott"
# Les Stott, users, compat, mydomain.com
dn: cn=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com

ILO Search context was set as: cn=users,cn=compat,dc=mydomain,dc=com


So it looks good, but when I test from ILO it fails still.
Try..
Les Stott
...It cant bind

[14/Jan/2014:21:52:31 -0500] conn=47 op=0 BIND dn="CN=Les 
Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2
[14/Jan/2014:21:52:31 -0500] conn=47 op=0 RESULT err=49 tag=97 nentries=0 
etime=0
[14/Jan/2014:21:52:31 -0500] conn=47 op=1 UNBIND
[14/Jan/2014:21:52:31 -0500] conn=48 op=0 BIND dn="Les Stott" authzid="(null)", 
invalid bind dn
[14/Jan/2014:21:52:31 -0500] conn=48 op=0 RESULT err=34 tag=97 nentries=0 
etime=0
[14/Jan/2014:21:52:31 -0500] conn=48 op=1 BIND dn="CN=Les 
Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2
[14/Jan/2014:21:52:31 -0500] conn=48 op=1 RESULT err=49 tag=97 nentries=0 
etime=0
[14/Jan/2014:21:52:31 -0500] conn=48 op=2 UNBIND
[14/Jan/2014:21:52:31 -0500] conn=50 op=0 BIND dn="CN=Les 
Stott,cn=users,cn=compat,dc=mydomain,dc=com" method=128 version=2
[14/Jan/2014:21:52:31 -0500] conn=50 op=0 RESULT err=49 tag=97 nentries=0 
etime=0
[14/Jan/2014:21:52:31 -0500] conn=50 op=1 UNBIND


Is it just not supporting to bind against the compat tree in 3.0.0.37? or am I 
doing something wrong?

Regards,

Les


From: Dmitri Pal [mailto:d...@redhat.com]
Sent: Wednesday, 15 January 2014 8:36 AM
To: Les Stott
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)

On 01/14/2014 04:01 PM, Les Stott wrote:
I had seen that thread... 
https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html

all it says is...

On 11/05/2013 02:51 PM, KodaK wrote:
If I use the whole connection string:

uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com

I can authenticate.
Which i can do successfully, but its not great to have to tell everyone your 
username for ilo is uid=blah,cn=users,cn=accounts..etc

There is also mentioned in that thread...

"The HP iLO documentation doesn't list using the uid value as a supported form 
of specifying the login.  You can use the CN value or the full DN.  They say 
that "DOMAIN\user" and "user domain" forms are also accepted, but that likely 
only works against Active Directory."

CN doesn't work. full DN does.

I don't see any reference to a workaround via compat plugin in that thread.

Have you got any more info on the compat workaround?

You can create a compat tree using compat plugin of IPA. It is used for NIS, 
support of Solaris clients and for AD trusts in latest IPA.
As a simple test you can enable the plugin:

ipa-compat-manage enable



That will expose the tree on the cn=compat hive but using 2307 schema.

You can then change the configuration of the plugin to use uid value instead of 
CN in this view, i.e expose CN as uid.

Then you can point your HP ILO to that tree.



AFAIU in the past it was not possible because we did not allow bind against 
compat tree but now we allow it so it should work with the latest IPA 3.3.x 
bits.



Details on how to change compat configuration can be found in the plugin 
configuration here:

https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc



I am not sure that would 100% work but IMO worth a shot.





Thanks,

Les

From: freeipa-users-boun...@redhat.com 
[freeipa-users-boun...@redhat.com] on 
behalf of Dmitri Pal [d...@redhat.com]
Sent: Wednesday, January 15, 2014 3:30 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)
On 01/13/2014 10:44 PM, Les Stott wrote:
Been banging my head against the wall on this one for a few days, trying to get 
a workable configuration for HP ILO to authenticate via FreeIPA.

I have a standard rhel6 environment (64 bit 6.4) with freeipa server 
(ipa-3.0.0-37.el6).

The following works for me..

HP ILO4 Firmware 1.22
Default Directory Schema
Directory Server Address: fqdn_of_myfreeipaserver
Directory Server LDAP Port: 636
Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com
Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com

but only if I login with my full dn

Username: uid=less,cn=users,cn=accounts,dc=

Re: [Freeipa-users] One way trusts

[Dmitri Pal]

On 01/14/2014 05:23 PM, Nordgren, Bryce L -FS wrote:
>> Both AD integration solutions we have (synchronization and
>> cross-forest domain trusts) assume having higher level access
>> privileges at the time integration is set up.
> My problem here is that I'm too ignorable. :) There's over 15000 users in our 
> AD; I'm in Montana, the admins are in DC. Worse, our agency's AD is being 
> absorbed into the next level up the chain (Forest Service AD is going to 
> become a part of the overall USDA AD). Then I'm an even smaller fish, 
> relatively speaking.
>
>> I'm unaware of other
>> mechanisms that would give you the same flexibility and level of
>> privilege separation between the AD and IPA domains.
> ?? The current solution using the LDAP interface to AD (and a metadirectory 
> to merge "external users") provides privilege separation and the flexibility 
> to add external users. I don't need more; I just need it to be less clunky. 
> It weakens security, of course, as my AD password is stored in various 
> plaintext configuration files for each application needing binding 
> credentials to search for users in AD. I also have an index to which files 
> contain my password, as it forms a "password-change-checklist" which I need 
> to run thru every 60 days.
>
> If I might try to repeat the problem back to you to see if I got it 
> right...the factor which requires access to the corporate AD is setting up a 
> Kerberos cross realm trust. This is required so that machines in IPA can 
> connect directly to AD for authentication. This in turn is necessary so that 
> identities in the AD Kerberos Realm are correctly and consistently identified 
> as being sourced from AD. And of course, this requirement is necessary for 
> services in AD to recognize users and groups in AD.
>
> Let me ask what is probably a series of dumb questions: What do I lose if my 
> FreeIPA server is set up as one of the 10 machines I can join to the network 
> as a regular user, and all the machines in IPA connect directly to IPA? Could 
> FreeIPA (current or future) be configured to relay the credentials to AD 
> either via Kerberos or using AD's LDAP interface (binding as itself because 
> it's joined to the AD domain)?  If AD accepts the provided credentials can 
> FreeIPA issue the user a ticket in the FreeIPA realm? Would this look to AD 
> like a bunch of users are logging into the FreeIPA server machine?
>
> I know this arrangement would sacrifice access to any of the AD services by 
> AD-users-on-the-IPA network. That's fine. If it's technically feasible, tho, 
> it gives me one server that can authenticate both "corporate users" and 
> "external users", and a central administration point for the external 
> network. It also plainly differentiates between corporate users logged in on 
> the corporate network, and corporate users logged in on the "external 
> network". I'd consider that a good thing. Finally, if this is possible, it 
> seems to me that this stands a chance of reducing the number of places my 
> password is stored in plaintext.
>
> Bryce
>
You might be able to do one of the following hacks. I am saying hack
because no one tried to do it and it might not work and hit some bugs
and issues.

1) Use pam proxy capability. If you bind to IPA DS via LDAP you can
configure users to authenticate using pam proxy feature of DS and via
pam point to AD. This has limitation that it works only for LDAP binds
but not for kerberos so your clients would be deprived off SSO.
Alternatively you can separate external and internal users. Internal
users would be able to do LDAP only while external users since they
would be stored in IPA would be able to do both. AFAIU this is not what
you want.
2) IPA in 3.3 uses compat tree to present AD data to legacy clients and
allow bind to that tree. This is just LDAP so has similar limitations. I
suspect it would also rely on the presence of trust to be able to bind
to AD but I am not sure. Alexander, CCed would have more details to
share for this case.
3) Finally the grand hack that actually might work. IPA 3.3 and 3.4 that
is being worked on have OTP support. You will setup winsync to sync AD
users (one way from AD), you will make sure that these users can't be
modified in IPA via permissions and ACIs so that you do not get into the
situation when users become different in IPA and AD. Since you own IPA
you will have full control so this part is really up to you. When users
are synced in you will add a way of setting additional attributes for
the synced in users. I am not sure if this can be done without adding a
DS or Winsync plugin but I think it would not be a lot of code for you
to do (may be there is a trick that I do not know that might be done to
avoid writing a plugin, see below). As a result the synced in users will
have following attributes set:
**ipatokenRadiusConfigLink - this attribute should point to a RADIUS
server configuration object. There will be one such object (see below).
All

Re: [Freeipa-users] One way trusts

[Nordgren, Bryce L -FS]

> Both AD integration solutions we have (synchronization and
> cross-forest domain trusts) assume having higher level access
> privileges at the time integration is set up.

My problem here is that I'm too ignorable. :) There's over 15000 users in our 
AD; I'm in Montana, the admins are in DC. Worse, our agency's AD is being 
absorbed into the next level up the chain (Forest Service AD is going to become 
a part of the overall USDA AD). Then I'm an even smaller fish, relatively 
speaking.

> I'm unaware of other
> mechanisms that would give you the same flexibility and level of
> privilege separation between the AD and IPA domains.

?? The current solution using the LDAP interface to AD (and a metadirectory to 
merge "external users") provides privilege separation and the flexibility to 
add external users. I don't need more; I just need it to be less clunky. It 
weakens security, of course, as my AD password is stored in various plaintext 
configuration files for each application needing binding credentials to search 
for users in AD. I also have an index to which files contain my password, as it 
forms a "password-change-checklist" which I need to run thru every 60 days.

If I might try to repeat the problem back to you to see if I got it right...the 
factor which requires access to the corporate AD is setting up a Kerberos cross 
realm trust. This is required so that machines in IPA can connect directly to 
AD for authentication. This in turn is necessary so that identities in the AD 
Kerberos Realm are correctly and consistently identified as being sourced from 
AD. And of course, this requirement is necessary for services in AD to 
recognize users and groups in AD.

Let me ask what is probably a series of dumb questions: What do I lose if my 
FreeIPA server is set up as one of the 10 machines I can join to the network as 
a regular user, and all the machines in IPA connect directly to IPA? Could 
FreeIPA (current or future) be configured to relay the credentials to AD either 
via Kerberos or using AD's LDAP interface (binding as itself because it's 
joined to the AD domain)?  If AD accepts the provided credentials can FreeIPA 
issue the user a ticket in the FreeIPA realm? Would this look to AD like a 
bunch of users are logging into the FreeIPA server machine?

I know this arrangement would sacrifice access to any of the AD services by 
AD-users-on-the-IPA network. That's fine. If it's technically feasible, tho, it 
gives me one server that can authenticate both "corporate users" and "external 
users", and a central administration point for the external network. It also 
plainly differentiates between corporate users logged in on the corporate 
network, and corporate users logged in on the "external network". I'd consider 
that a good thing. Finally, if this is possible, it seems to me that this 
stands a chance of reducing the number of places my password is stored in 
plaintext.

Bryce






This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)

[Dmitri Pal]

On 01/14/2014 04:01 PM, Les Stott wrote:
> I had seen that thread...
> https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html
>
> all it says is...
>
> On 11/05/2013 02:51 PM, KodaK wrote:
>> If I use the whole connection string:
>>
>> uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com
>>
>> I can authenticate.
> Which i can do successfully, but its not great to have to tell
> everyone your username for ilo is uid=blah,cn=users,cn=accounts..etc
>
> There is also mentioned in that thread...
>
> "The HP iLO documentation doesn't list using the uid value as a
> supported form of specifying the login.  You can use the CN value or
> the full DN.  They say that "DOMAIN\user" and "user domain" forms are
> also accepted, but that likely only works against Active Directory."
>
> CN doesn't work. full DN does.
>
> I don't see any reference to a workaround via compat plugin in that
> thread.
>
> Have you got any more info on the compat workaround?
>

You can create a compat tree using compat plugin of IPA. It is used for
NIS, support of Solaris clients and for AD trusts in latest IPA.
As a simple test you can enable the plugin:

ipa-compat-manage enable

That will expose the tree on the cn=compat hive but using 2307 schema.
You can then change the configuration of the plugin to use uid value instead of 
CN in this view, i.e expose CN as uid.
Then you can point your HP ILO to that tree.

AFAIU in the past it was not possible because we did not allow bind against 
compat tree but now we allow it so it should work with the latest IPA 3.3.x 
bits.

Details on how to change compat configuration can be found in the plugin 
configuration here:
https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc

I am not sure that would 100% work but IMO worth a shot.




> Thanks,
>
> Les
>
> 
> *From:* freeipa-users-boun...@redhat.com
> [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal
> [d...@redhat.com]
> *Sent:* Wednesday, January 15, 2014 3:30 AM
> *To:* freeipa-users@redhat.com
> *Subject:* Re: [Freeipa-users] HP ILO Authentication via LDAP (or even
> kerberos)
>
> On 01/13/2014 10:44 PM, Les Stott wrote:
>>
>> Been banging my head against the wall on this one for a few days,
>> trying to get a workable configuration for HP ILO to authenticate via
>> FreeIPA.
>>
>>  
>>
>> I have a standard rhel6 environment (64 bit 6.4) with freeipa server
>> (ipa-3.0.0-37.el6).
>>
>>  
>>
>> The following works for me……
>>
>>  
>>
>> HP ILO4 Firmware 1.22
>>
>> Default Directory Schema
>>
>> Directory Server Address: fqdn_of_myfreeipaserver
>>
>> Directory Server LDAP Port: 636
>>
>> Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com
>>
>> Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com
>>
>>  
>>
>> ….but only if I login with my full dn….
>>
>>  
>>
>> Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com
>>
>>  
>>
>> The test settings button in the ILO works only with the full dn.
>>
>>  
>>
>> It doesn’t work if I use the uid (less), or the cn (Les Stott).
>>
>>  
>>
>> I can then login to ILO with ….
>>
>> Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com
>>
>>  
>>
>> If I try to login with the cn, Les Stott I see an error in the logs…
>>
>>  
>>
>> [13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c,
>> line 473]: Failed to retrieve entry "CN=Les
>> Stott,cn=users,cn=accounts,dc=mydomain,dc=com": 32
>>
>>  
>>
>> I’ve read a lot of things about getting this to work. Apparently
>> there are issues with HP ILO requiring the username in cn format but
>> its in uid format in freeipa. You should also be able to login with
>> your cn, but that doesn’t work.
>>
>>  
>>
>> I had a crack at trying Kerberos authentication as well, but it
>> doesn’t work and errors with “Additional Pre-authentication required”.
>>
>>  
>>
>> Has anyone successfully been able to get HP ILO to work with FreeIPA
>> such that you can login with just the username (i.e. “less”) or the
>> CN (i.e. “Les Stott”)?
>>
>>  
>>
>> Are schema changes required?
>>
>>  
>>
>> Alternatively has anyone been able to get HP ILO to work with
>> Kerberos auth to FreeIPA?
>>
>>  
>>
>> Any help would be greatly appreciated.
>>
>>  
>>
>> Regards,
>>
>>  
>>
>> Les
>>
>>  
>>
>>  
>>
>>
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
> Have you searched freeipa-users archives? The issue sounds familiar
> and I vaguely recalled there was a workaround.
> This is the thread
> https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html
>
> I think you can use compat plugin on the IPA to expose the tree in the
> way HP ILO expects.
> -- 
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> ---
> Looking to ca

Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)

[Les Stott]

I had seen that thread... 
https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html

all it says is...

On 11/05/2013 02:51 PM, KodaK wrote:
If I use the whole connection string:

uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com

I can authenticate.
Which i can do successfully, but its not great to have to tell everyone your 
username for ilo is uid=blah,cn=users,cn=accounts..etc

There is also mentioned in that thread...

"The HP iLO documentation doesn't list using the uid value as a supported form 
of specifying the login.  You can use the CN value or the full DN.  They say 
that "DOMAIN\user" and "user domain" forms are also accepted, but that likely 
only works against Active Directory."

CN doesn't work. full DN does.

I don't see any reference to a workaround via compat plugin in that thread.

Have you got any more info on the compat workaround?

Thanks,

Les


From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on 
behalf of Dmitri Pal [d...@redhat.com]
Sent: Wednesday, January 15, 2014 3:30 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)

On 01/13/2014 10:44 PM, Les Stott wrote:
Been banging my head against the wall on this one for a few days, trying to get 
a workable configuration for HP ILO to authenticate via FreeIPA.

I have a standard rhel6 environment (64 bit 6.4) with freeipa server 
(ipa-3.0.0-37.el6).

The following works for me……

HP ILO4 Firmware 1.22
Default Directory Schema
Directory Server Address: fqdn_of_myfreeipaserver
Directory Server LDAP Port: 636
Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com
Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com

….but only if I login with my full dn….

Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com

The test settings button in the ILO works only with the full dn.

It doesn’t work if I use the uid (less), or the cn (Les Stott).

I can then login to ILO with ….
Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com

If I try to login with the cn, Les Stott I see an error in the logs…

[13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c, line 
473]: Failed to retrieve entry "CN=Les 
Stott,cn=users,cn=accounts,dc=mydomain,dc=com": 32

I’ve read a lot of things about getting this to work. Apparently there are 
issues with HP ILO requiring the username in cn format but its in uid format in 
freeipa. You should also be able to login with your cn, but that doesn’t work.

I had a crack at trying Kerberos authentication as well, but it doesn’t work 
and errors with “Additional Pre-authentication required”.

Has anyone successfully been able to get HP ILO to work with FreeIPA such that 
you can login with just the username (i.e. “less”) or the CN (i.e. “Les Stott”)?

Are schema changes required?

Alternatively has anyone been able to get HP ILO to work with Kerberos auth to 
FreeIPA?

Any help would be greatly appreciated.

Regards,

Les





___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Have you searched freeipa-users archives? The issue sounds familiar and I 
vaguely recalled there was a workaround.
This is the thread 
https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html

I think you can use compat plugin on the IPA to expose the tree in the way HP 
ILO expects.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] sudo log errors

[Dmitri Pal]

On 01/14/2014 06:17 AM, Natxo Asenjo wrote:
> hi,
>
> after using sudo from ipa extensively I needed to configure a local
> user to also use sudo.
>
> This is for monitoring, we use nagios.
>
> It works but now I have lots of error messages in /var/log/messages
> like this one:
>
> sudo: GSSAPI Error: Unspecified GSS failure.  Minor code may provide
> more information (Credentials cache file '/tmp/krb5cc_0' not found)
>
> Well, yes, obviously the nagios local user does not have a kerberos
> ticket. Why the error?
>
> I modified /etc/sudoers to allow the nagios user to not use a tty:
>
> Defaults:nagios !requiretty
>
> And have added nagios config files for sudo in /etc/sudoers.d/
>
> nagios  ALL=NOPASSWD: /usr/lib/nagios/plugins/check_logfiles
>
> In /etc/nsswitch.conf, sudo looks like this:
>
> sudoers:files ldap
>
> Is there anything else I can do or do I just have to live with the
> error on syslog?
>
> TIA,
> --
> Groeten,
> natxo
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

I wonder if putting this user into the local sssd provider would silence
it... Just a thought...

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)

[Dmitri Pal]

On 01/13/2014 10:44 PM, Les Stott wrote:
>
> Been banging my head against the wall on this one for a few days,
> trying to get a workable configuration for HP ILO to authenticate via
> FreeIPA.
>
>  
>
> I have a standard rhel6 environment (64 bit 6.4) with freeipa server
> (ipa-3.0.0-37.el6).
>
>  
>
> The following works for me..
>
>  
>
> HP ILO4 Firmware 1.22
>
> Default Directory Schema
>
> Directory Server Address: fqdn_of_myfreeipaserver
>
> Directory Server LDAP Port: 636
>
> Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com
>
> Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com
>
>  
>
> but only if I login with my full dn
>
>  
>
> Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com
>
>  
>
> The test settings button in the ILO works only with the full dn.
>
>  
>
> It doesn't work if I use the uid (less), or the cn (Les Stott).
>
>  
>
> I can then login to ILO with 
>
> Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com
>
>  
>
> If I try to login with the cn, Les Stott I see an error in the logs...
>
>  
>
> [13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c,
> line 473]: Failed to retrieve entry "CN=Les
> Stott,cn=users,cn=accounts,dc=mydomain,dc=com": 32
>
>  
>
> I've read a lot of things about getting this to work. Apparently there
> are issues with HP ILO requiring the username in cn format but its in
> uid format in freeipa. You should also be able to login with your cn,
> but that doesn't work.
>
>  
>
> I had a crack at trying Kerberos authentication as well, but it
> doesn't work and errors with "Additional Pre-authentication required".
>
>  
>
> Has anyone successfully been able to get HP ILO to work with FreeIPA
> such that you can login with just the username (i.e. "less") or the CN
> (i.e. "Les Stott")?
>
>  
>
> Are schema changes required?
>
>  
>
> Alternatively has anyone been able to get HP ILO to work with Kerberos
> auth to FreeIPA?
>
>  
>
> Any help would be greatly appreciated.
>
>  
>
> Regards,
>
>  
>
> Les
>
>  
>
>  
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
Have you searched freeipa-users archives? The issue sounds familiar and
I vaguely recalled there was a workaround.
This is the thread
https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html

I think you can use compat plugin on the IPA to expose the tree in the
way HP ILO expects.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] One way trusts

[Dmitri Pal]

On 01/13/2014 11:50 PM, Alexander Bokovoy wrote:
> Hi,
>
> On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote:
>> Hi Dimitri,
>>
>>> Just to be sure I understand.  You have internal users - they are in
>>> AD. You have external users - they are in LDAP.  You merge two
>>> directories and you want to replace this setup with IPA.
>>
>> Yes.
>>
>>> It seems that to support your use case you would need to make the
>>> external users be IPA users and make AD and IPA trust each other.
>>
>> I think I concur about migrating my external users into IPA and making
>> IPA trust AD. I may be ignorant of some AD nuance, but I do not see why
>> AD needs to trust IPA. AD does not need to trust my LDAP clients
>> currently.
> IPA needs to be able to look up users and groups in AD. To do so, it
> uses Kerberos authentication against AD's Global Catalog services with
> own credentials (per each IPA host). We are using cross-realm
> Kerberos trust here, AD DC trusts cross-realm TGT issued by IPA KDC and
> vice versa, so IPA hosts can bind as their own identity (host/...) to
> AD.
>
> Since we don't implement fully all services needed to grant privileges
> beyond read-only in AD, these binds to AD Global Catalog become
> read-only. They are still required. An alternative would have been to
> always keep an account in AD for each IPA host that needs to query user
> and group identities from AD. We decided to go with the cross-realm
> Kerberos trust instead since it gives better way of privilege separation.
> Cross-realm Kerberos trust is known as cross-forest domain trust in AD
> speak since there are more protocol layers than Kerberos involved (SMB
> protocol, in particular, is used to set up and verify trust
> relationship).
>
> Once we implement AD GC service, AD admins will be able to subject IPA
> users/hosts to further limit their access to other AD services beyond
> simple read-only access to AD LDAP and SMB services. As result, in
> future more fine-grained privilege and security separation between AD
> and IPA will be possible.
>
>>
>>> Also if external users do not authenticate using Kerberos (for example
>>> they always use a special portal) then it does not matter what trust
>>> is between AD and IPA because those users will not have kerberos
>>> tickets that are leveraged in SSO in trust case.
>>
>> I want to be able to point either an LDAP or a Kerberos client at IPA,
>> and have it authenticate my "enterprise" and "external" users for me.
>> I'm not going to tangle with SSO at the moment. Right now, we're just
>> establishing an identity store.
> That is what provided by IPA's AD trusts. IPA machines can resolve
> identities of the users and groups in AD and can authenticate those
> users on logons, subject to HBAC policies.
>
>>> IPA can trust AD. Formally it is a mutual trust but in reality IPA
>>> does not have global catalog support for users in IPA to be able to
>>> access the resources in AD.
>>
>> In many of the tutorials/HOWTOs, I see that there is a requirement to
>> provide credentials having the permission to add a computer to the
>> domain, or being a member of an AD administration group. I'm a lowly
>> standard "User" in the AD. I don't know if that means I can add a
>> computer to the domain or not. I know I lack the ability to edit AD
>> entries that aren't mine, so I really need a solution that does not
>> require creating a trust relationship inside AD.
> Both AD integration solutions we have (synchronization and cross-forest
> domain trusts) assume having higher level access privileges at the time
> integration is set up. I'm unaware of other mechanisms that would give
> you the same flexibility and level of privilege separation between the
> AD and IPA domains. Having a standard 'User' account in AD only entitles
> you to join up to 10 machines in AD. These machine will become a part of
> AD domain and are subject of their policies which are quite extended by
> default. Cross-forest domain trusts, on the other hand, are subject to
> inter-domain trust relationship policies which are better constrained.
>
> One could try to fiddle with AD-joined machine accounts to represent IPA
> hosts but it is very much uncharted territory since there will be no
> integration whatsoever on any of IPA features (access controls to IPA
> services, ID allocation, etc) and everything will need to be set up and
> maintained manually, including periodical refreshes of the machine
> accounts. In addition, Kerberos authentication will simply not work as
> AD has certain assumption over DNS namespace mapping to Kerberos realms.
>
>
>> Is there a way for me to comment out the AD->IPA trust creation, or
>> would that break the IPA->AD trust?
> The latter, since AD->IPA part of the trust is used to query AD users
> and groups. In other words, it is used to provide the key resources
> needed to operate IPA->AD trust part.
>
>
The shorter answer is: to setup any integration you need to ask AD admin
to help you out to setup t

Re: [Freeipa-users] Sudo policy not working with group of servers

[Rob Crittenden]

Dimitar Georgievski wrote:

Hi,

I've been trying to create a simple sudo policy, that would grant
certain privileges to a group of users on a group of hosts. The policy
would not work unless I specify the hosts individually in the *Sudo
Rule* definition page under *Access this hos*t section.

I am using FreeIPA v3.0 and SSSD v1.9.2 on CentOS 6.5


You need to set the NIS domain name on the client machine:

# domainname example.com

Then it should work. You can test with getent netgroup some_hostgroup

rob

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo policy not working with group of servers

[Martin Kosek]

On 01/14/2014 04:27 PM, Dimitar Georgievski wrote:
> Hi,
> 
> I've been trying to create a simple sudo policy, that would grant certain
> privileges to a group of users on a group of hosts. The policy would not
> work unless I specify the hosts individually in the *Sudo Rule* definition
> page under  *Access this hos*t section.
> 
> I am using FreeIPA v3.0 and SSSD v1.9.2 on CentOS 6.5
> 
> Thanks,
> 
> Dimitar

Hello Dimitar,

I would recommend starting investigation by following this article:
http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups

Martin

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] Sudo policy not working with group of servers

[Dimitar Georgievski]

Hi,

I've been trying to create a simple sudo policy, that would grant certain
privileges to a group of users on a group of hosts. The policy would not
work unless I specify the hosts individually in the *Sudo Rule* definition
page under  *Access this hos*t section.

I am using FreeIPA v3.0 and SSSD v1.9.2 on CentOS 6.5

Thanks,

Dimitar
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Odd problem with SSSD and SSH keys

[Bret Wortman]

I was assuming that the key was being re-inserted by the ssh 
authentication request, but to eliminate puppet, I just tried this sequence:


# puppet agent --disable
# rm -f /var/lib/sss/pubconf/known_hosts
# ls -l /var/lib/sss/pubconf/known_hosts
# ssh zw131
:
: (errors about the key being incorrect)
:
# cat /var/lib/sss/pubconf/known_hosts
:

it now contained the bad key again.


On 01/13/2014 02:52 PM, Dmitri Pal wrote:

On 01/13/2014 02:44 PM, Bret Wortman wrote:
They're definitely different. I deleted the one in the file, then 
tried again. It put the bad key back in the file. I blew the whole 
file away and the same thing happened. Where is this key coming from 
if not from IPA?


Puppet?




On 01/13/2014 02:36 PM, Rob Crittenden wrote:

Bret Wortman wrote:
I've got a strange situation where some of my workstations are 
reporting

difficulty when sshing to remote systems, but there's no pattern I can
discern. One user's machine can't get to system A, but I can, though I
can't ssh to his workstation directly.

Here's the kind of thing I see when doing ssh -vvv:

debug1: Server host key: RSA 
2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab

debug3: load_hostkeys: loading entries for host "rs512" from file
"/root/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug3: load_hostkeys: loading entries for host "rs512" from file
"/var/lib/sss/pubconf/known_hosts"
debug3: load_hostkeys: found key type RSA in file
/var/lib/sss/pubconf/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
@@
@   WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone coudl be eavesdropping on you right now (man-in-the-middle 
attack)!

It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this 
message.

Offending RSA key in /var/lib/sss/pubconf/known_hosts:2
RSA host key for zw131 has changed and you have requested strict 
checking.

Host key verification failed.
#

We haven't changed the host key; the public key files are dated 
October
23 of last year. Our configuration files for SSSD and SSH are 
managed by

Puppet, so they are consistent from system to system. That said, I did
compare a system that could remote to rs512 to one that could not and
found no differences. Here are the files:

/etc/sssd/sssd.conf:
[domain/spx.net]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = foo.net
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = zw129.foo.net
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49
ldap_tls_cacert = /etc/ipa/ca.crt
[domain/.spx.net]
cache_credentials = True
krb5_store_password_if_offline = True
krb5_realm = FOO.NET
ipa_domain = .foo.net
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49
ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net
dns_discovery_domain = .spx.net
[sssd]
services = nss, pam, ssh
config_file_version = 2

domains = .spx.net, spx.net
[nss]

[pam]

[sudo]

[autofs]

[ssh]

Is there anything else relevant that I should be looking at?


You might compare the value of the key in IPA to what is in 
/var/lib/sss/pubconf/known_hosts


rob






___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users




smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Odd problem with SSSD and SSH keys

[Bret Wortman]

The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the 
host in question. It should not have had any connectivity issues; it's 
co-located with several of our IPA masters.


I'd be happy to run sss_ssh_knownhostsproxy manually but haven't been 
able to locate the proxy command to use via Google yet. Any guidance?



On 01/14/2014 05:43 AM, Jan Cholasta wrote:

On 13.1.2014 22:18, Jakub Hrozek wrote:

On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote:

They're definitely different. I deleted the one in the file, then
tried again. It put the bad key back in the file. I blew the whole
file away and the same thing happened. Where is this key coming from
if not from IPA?


Can you try running sss_ssh_knownhostsproxy manually to see what key
does it return?

The keys are propagated to the file from the sssd database. If the 
client
was offline, the client could use stale records. Can you verify the 
client

has no connectivity issues?

Honza (CC-ed) might have some more hints.



Compare the public key in /etc/ssh/ssh_host_rsa_key.pub on the host 
with the public key for that host in IPA. If they do not match, the 
host key was changed after IPA client was installed and the host 
record in IPA must be manually updated with the new key.


Honza






smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] sudo log errors

[Natxo Asenjo]

hi,

after using sudo from ipa extensively I needed to configure a local
user to also use sudo.

This is for monitoring, we use nagios.

It works but now I have lots of error messages in /var/log/messages
like this one:

sudo: GSSAPI Error: Unspecified GSS failure.  Minor code may provide
more information (Credentials cache file '/tmp/krb5cc_0' not found)

Well, yes, obviously the nagios local user does not have a kerberos
ticket. Why the error?

I modified /etc/sudoers to allow the nagios user to not use a tty:

Defaults:nagios !requiretty

And have added nagios config files for sudo in /etc/sudoers.d/

nagios  ALL=NOPASSWD: /usr/lib/nagios/plugins/check_logfiles

In /etc/nsswitch.conf, sudo looks like this:

sudoers:files ldap

Is there anything else I can do or do I just have to live with the
error on syslog?

TIA,
--
Groeten,
natxo

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Odd problem with SSSD and SSH keys

[Jan Cholasta]

On 13.1.2014 22:18, Jakub Hrozek wrote:

On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote:

They're definitely different. I deleted the one in the file, then
tried again. It put the bad key back in the file. I blew the whole
file away and the same thing happened. Where is this key coming from
if not from IPA?


Can you try running sss_ssh_knownhostsproxy manually to see what key
does it return?

The keys are propagated to the file from the sssd database. If the client
was offline, the client could use stale records. Can you verify the client
has no connectivity issues?

Honza (CC-ed) might have some more hints.



Compare the public key in /etc/ssh/ssh_host_rsa_key.pub on the host with 
the public key for that host in IPA. If they do not match, the host key 
was changed after IPA client was installed and the host record in IPA 
must be manually updated with the new key.


Honza

--
Jan Cholasta

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users