Re: [Freeipa-users] EXTERNAL: Re: IPA - NIS Compatability

[Joseph, Matthew (EXP)]

Hey Nalin,

Sorry typo on my part. It does say nis-base.

-Original Message-
From: Nalin Dahyabhai [mailto:na...@redhat.com] 
Sent: Wednesday, March 27, 2013 12:57 PM
To: Joseph, Matthew (EXP)
Cc: freeipa-users@redhat.com
Subject: EXTERNAL: Re: [Freeipa-users] IPA - NIS Compatability

On Wed, Mar 27, 2013 at 11:07:44AM -0400, Joseph, Matthew (EXP) wrote:
> Here is the entry that is in dse.ldif:
> 
> Dn= nis-domain=domain.ca+nis-map=hosts.byname,CN=NIS 
> Server,cn=plugin,cn=config
> objectClass: top
> objectClass: extensibleObject
> nis-map: hosts.byname
> nis=base: cn=computers,cn=accounts,dc=domain,dc=ca
> nis-domain: domain.ca
> nis-secure: no
> creatorsName: cn=directory manager
> modifiersName: cn=directory manager
> 
> So when I run ypcat hosts it just brings up a blank entry so it is actually 
> seeing that a table should be there.
> 
> Any ideas?

Looks like you've got a typo: "nis=base" where "nis-base" was intended.

HTH,

Nalin

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

Re: [Freeipa-users] EXTERNAL: Re: IPA - NIS Compatability

[Nalin Dahyabhai]

On Wed, Mar 27, 2013 at 01:42:58PM -0400, Joseph, Matthew (EXP) wrote:
> Hey Nalin,
> 
> Sorry typo on my part. It does say nis-base.

Alright then.  The next thing to check is if the directory entries the
plugin's finding have data that the plugin expects to use to create
entries in the NIS map.

Based on your configuration:
> > nis-map: hosts.byname
> > nis=base: cn=computers,cn=accounts,dc=domain,dc=ca
> > nis-domain: domain.ca
> > nis-secure: no

And these defaults (courtesy of nisserver-plugin-defs -m hosts.byname):
  nis-filter: (&(ipHostNumber=*)(cn=*))
  nis-keys-format: %{cn}
  nis-value-format: %first("%{cn}") %{ipHostNumber} %merge(" ","%{cn}")

The plugin's looking for host entries which contain one or more of both
the 'cn' and 'ipHostNumber' attributes.  Do you have an example entry
from that area of the tree?  Does it contain those attributes?

Nalin

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

Re: [Freeipa-users] kinit seg-fault for Solaris 9

[Simo Sorce]

On Wed, 2013-03-27 at 09:56 -0700, David Redmond wrote:
> I've done 1,2,3 many times. 4 always fails.
> 
> I realize you didn't ask for the info about allow_weak_crypto. I
> included it because it seems to me that it's a telling bit of info.

Ok can you run klist -e -kt file.keytab on the keytab you get after you
run ipa-getkeytab ?

What enctypes do you see available ?

I suspect your solaris 9 kinit is choking on a request that do not
include des enctypes somehow ?

Can solaris 9 use any other encryption algorythm than des ?

Simo.

> On Wed, Mar 27, 2013 at 9:50 AM, Simo Sorce  wrote:
> I didn't ask to run ipa-getkeytab,
> can you do the following:
> 
> 1. login to a linux client
> 2. change the user password as an admin
> 3. kinit as the user (and perform the password change as it
> will be
> requested)
> 4. go to the solaris box and now try the kinit using the new
> password
> 
> Does step 4 work if you do 1,2,3 ?
> Or does it keep segfaulting ?
> 
> 
> 
> The difference when allow_weak_crypto is false is that des
> keys are not
> produced, so an AS REQ reply will return to the client with a
> list of
> encryption types that do not include des as a valid algorithm.
> 
> Maybe your kinit client is choking on that ?
> 
> You can change the default encryption types used to generate
> new
> password, (changing allow_weak_crypto is not sufficient for
> that) in
> FreeIPA by adding the desired enctypes in the
> krbDefaultEncSaltTypes
> multivalued attribute in entry named:
> cn=,cn=Kerberos,
> 
> The current defaults for new installs do *not* include DES as
> it is a
> broken algorithm for security at this point.
> 
> 
> Simo.
> 
> On Wed, 2013-03-27 at 09:36 -0700, David Redmond wrote:
> > I run the ipa-getkeytab command as the user I'm changing the
> password
> > for.
> >
> > New info: On the server, in my /etc/krb5.conf file I have
> > "allow_weak_crypto = true". If I remove that from the file,
> changing
> > the password via ipa-getkeytab no longer works. The kinit
> command on
> > the Solaris client results in a segmentation fault. When I
> put
> > "allow_weak_crypto = true" back into the krb5.conf file and
> change the
> > password via ipa-getkeytab the kinit command on the Solaris
> client
> > works normally.
> >
> > The ipa-getkeytab command must somehow be referencing
> > "allow_weak_crypto" and storing the password differently
> depending on
> > it.
> >
> > On Wed, Mar 27, 2013 at 5:51 AM, Simo Sorce
>  wrote:
> > On Wed, 2013-03-27 at 12:23 +0100, Sumit Bose wrote:
> > > >
> > > > I did (as admin@REALM user). But we hardcode
> > root/admin@REALM if
> > > this is
> > > > administrative change:
> > > >
> > > > ipapwd_chpwop():
> > > > ...
> > > > if (pwdata.changetype ==
> IPA_CHANGETYPE_NORMAL) {
> > > > principal =
> > slapi_entry_attr_get_charptr(pwdata.target,
> > > >
> > > "krbPrincipalName");
> > > > } else {
> > > > principal =
> slapi_ch_smprintf("root/admin@%s",
> > > krbcfg->realm);
> > > > }
> > > > ...
> > > >
> > > > Maybe the root cause of the crash is that we
> place there a
> > principal
> > > > (root/admin@REALM) which does not exist. But
> this is just
> > a
> > > speculation.
> > >
> > > ok, the principal is odd, and I guess this should
> be fixed,
> > but maybe
> > > Simo knows some more history here. But
> nevertheless I think
> > it is
> > > unrelated to the crash, becaus afaik this
> information is not
> > send to
> > > the
> > > client and only used for book-keeing and auditing
> on the
> > server side.
> > >
> >
> > I don't recall the root/admin story, looks odd to
> me, but
> > nothing of
> > this matter to a *client* segfaulting.
> >
> > Clients do not get access to this data this is
> purely internal
> >

Re: [Freeipa-users] kinit seg-fault for Solaris 9

[David Redmond]

I've done 1,2,3 many times. 4 always fails.

I realize you didn't ask for the info about allow_weak_crypto. I included
it because it seems to me that it's a telling bit of info.

On Wed, Mar 27, 2013 at 9:50 AM, Simo Sorce  wrote:

> I didn't ask to run ipa-getkeytab,
> can you do the following:
>
> 1. login to a linux client
> 2. change the user password as an admin
> 3. kinit as the user (and perform the password change as it will be
> requested)
> 4. go to the solaris box and now try the kinit using the new password
>
> Does step 4 work if you do 1,2,3 ?
> Or does it keep segfaulting ?
>
>
>
> The difference when allow_weak_crypto is false is that des keys are not
> produced, so an AS REQ reply will return to the client with a list of
> encryption types that do not include des as a valid algorithm.
>
> Maybe your kinit client is choking on that ?
>
> You can change the default encryption types used to generate new
> password, (changing allow_weak_crypto is not sufficient for that) in
> FreeIPA by adding the desired enctypes in the krbDefaultEncSaltTypes
> multivalued attribute in entry named:
> cn=,cn=Kerberos,
>
> The current defaults for new installs do *not* include DES as it is a
> broken algorithm for security at this point.
>
>
> Simo.
>
> On Wed, 2013-03-27 at 09:36 -0700, David Redmond wrote:
> > I run the ipa-getkeytab command as the user I'm changing the password
> > for.
> >
> > New info: On the server, in my /etc/krb5.conf file I have
> > "allow_weak_crypto = true". If I remove that from the file, changing
> > the password via ipa-getkeytab no longer works. The kinit command on
> > the Solaris client results in a segmentation fault. When I put
> > "allow_weak_crypto = true" back into the krb5.conf file and change the
> > password via ipa-getkeytab the kinit command on the Solaris client
> > works normally.
> >
> > The ipa-getkeytab command must somehow be referencing
> > "allow_weak_crypto" and storing the password differently depending on
> > it.
> >
> > On Wed, Mar 27, 2013 at 5:51 AM, Simo Sorce  wrote:
> > On Wed, 2013-03-27 at 12:23 +0100, Sumit Bose wrote:
> > > >
> > > > I did (as admin@REALM user). But we hardcode
> > root/admin@REALM if
> > > this is
> > > > administrative change:
> > > >
> > > > ipapwd_chpwop():
> > > > ...
> > > > if (pwdata.changetype == IPA_CHANGETYPE_NORMAL) {
> > > > principal =
> > slapi_entry_attr_get_charptr(pwdata.target,
> > > >
> > > "krbPrincipalName");
> > > > } else {
> > > > principal = slapi_ch_smprintf("root/admin@%s",
> > > krbcfg->realm);
> > > > }
> > > > ...
> > > >
> > > > Maybe the root cause of the crash is that we place there a
> > principal
> > > > (root/admin@REALM) which does not exist. But this is just
> > a
> > > speculation.
> > >
> > > ok, the principal is odd, and I guess this should be fixed,
> > but maybe
> > > Simo knows some more history here. But nevertheless I think
> > it is
> > > unrelated to the crash, becaus afaik this information is not
> > send to
> > > the
> > > client and only used for book-keeing and auditing on the
> > server side.
> > >
> >
> > I don't recall the root/admin story, looks odd to me, but
> > nothing of
> > this matter to a *client* segfaulting.
> >
> > Clients do not get access to this data this is purely internal
> > metadata
> > used by kadmin and the KDC.
> >
> > What I wonder is if the client is segfaulting when the
> > password is
> > expired due to a bug in handling the request to immediately
> > change the
> > password ?
> >
> > David,
> > if you kinit on a Linux machine and make sure you properly
> > change the
> > password of the user (as the user no as an admin), and then
> > kinit again
> > with the new credentials on Solaris, does it 'solve' your
> > segfault
> > issue ?
> >
> > In any case a segfault in a client command is something you
> > need to
> > report to your OS vendor, even if it is indirectly caused by
> > the server
> > it shows a potential attack vector and it is particularly
> > worrying in
> > something like kinit that may be run as root on a box.
> >
> > Simo.
> >
> > --
> > Simo Sorce * Red Hat, Inc * New York
> >
> >
>
>
> --
> 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] kinit seg-fault for Solaris 9

[Simo Sorce]

I didn't ask to run ipa-getkeytab,
can you do the following:

1. login to a linux client
2. change the user password as an admin
3. kinit as the user (and perform the password change as it will be
requested)
4. go to the solaris box and now try the kinit using the new password

Does step 4 work if you do 1,2,3 ?
Or does it keep segfaulting ?



The difference when allow_weak_crypto is false is that des keys are not
produced, so an AS REQ reply will return to the client with a list of
encryption types that do not include des as a valid algorithm.

Maybe your kinit client is choking on that ?

You can change the default encryption types used to generate new
password, (changing allow_weak_crypto is not sufficient for that) in
FreeIPA by adding the desired enctypes in the krbDefaultEncSaltTypes
multivalued attribute in entry named:
cn=,cn=Kerberos,

The current defaults for new installs do *not* include DES as it is a
broken algorithm for security at this point.


Simo.

On Wed, 2013-03-27 at 09:36 -0700, David Redmond wrote:
> I run the ipa-getkeytab command as the user I'm changing the password
> for.
> 
> New info: On the server, in my /etc/krb5.conf file I have
> "allow_weak_crypto = true". If I remove that from the file, changing
> the password via ipa-getkeytab no longer works. The kinit command on
> the Solaris client results in a segmentation fault. When I put
> "allow_weak_crypto = true" back into the krb5.conf file and change the
> password via ipa-getkeytab the kinit command on the Solaris client
> works normally.
> 
> The ipa-getkeytab command must somehow be referencing
> "allow_weak_crypto" and storing the password differently depending on
> it.
> 
> On Wed, Mar 27, 2013 at 5:51 AM, Simo Sorce  wrote:
> On Wed, 2013-03-27 at 12:23 +0100, Sumit Bose wrote:
> > >
> > > I did (as admin@REALM user). But we hardcode
> root/admin@REALM if
> > this is
> > > administrative change:
> > >
> > > ipapwd_chpwop():
> > > ...
> > > if (pwdata.changetype == IPA_CHANGETYPE_NORMAL) {
> > > principal =
> slapi_entry_attr_get_charptr(pwdata.target,
> > >
> > "krbPrincipalName");
> > > } else {
> > > principal = slapi_ch_smprintf("root/admin@%s",
> > krbcfg->realm);
> > > }
> > > ...
> > >
> > > Maybe the root cause of the crash is that we place there a
> principal
> > > (root/admin@REALM) which does not exist. But this is just
> a
> > speculation.
> >
> > ok, the principal is odd, and I guess this should be fixed,
> but maybe
> > Simo knows some more history here. But nevertheless I think
> it is
> > unrelated to the crash, becaus afaik this information is not
> send to
> > the
> > client and only used for book-keeing and auditing on the
> server side.
> >
> 
> I don't recall the root/admin story, looks odd to me, but
> nothing of
> this matter to a *client* segfaulting.
> 
> Clients do not get access to this data this is purely internal
> metadata
> used by kadmin and the KDC.
> 
> What I wonder is if the client is segfaulting when the
> password is
> expired due to a bug in handling the request to immediately
> change the
> password ?
> 
> David,
> if you kinit on a Linux machine and make sure you properly
> change the
> password of the user (as the user no as an admin), and then
> kinit again
> with the new credentials on Solaris, does it 'solve' your
> segfault
> issue ?
> 
> In any case a segfault in a client command is something you
> need to
> report to your OS vendor, even if it is indirectly caused by
> the server
> it shows a potential attack vector and it is particularly
> worrying in
> something like kinit that may be run as root on a box.
> 
> Simo.
> 
> --
> Simo Sorce * Red Hat, Inc * New York
> 
> 


-- 
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] kinit seg-fault for Solaris 9

[David Redmond]

I run the ipa-getkeytab command as the user I'm changing the password for.

New info: On the server, in my /etc/krb5.conf file I have
"allow_weak_crypto = true". If I remove that from the file, changing the
password via ipa-getkeytab no longer works. The kinit command on the
Solaris client results in a segmentation fault. When I put
"allow_weak_crypto = true" back into the krb5.conf file and change the
password via ipa-getkeytab the kinit command on the Solaris client works
normally.

The ipa-getkeytab command must somehow be referencing "allow_weak_crypto"
and storing the password differently depending on it.

On Wed, Mar 27, 2013 at 5:51 AM, Simo Sorce  wrote:

> On Wed, 2013-03-27 at 12:23 +0100, Sumit Bose wrote:
> > >
> > > I did (as admin@REALM user). But we hardcode root/admin@REALM if
> > this is
> > > administrative change:
> > >
> > > ipapwd_chpwop():
> > > ...
> > > if (pwdata.changetype == IPA_CHANGETYPE_NORMAL) {
> > > principal = slapi_entry_attr_get_charptr(pwdata.target,
> > >
> > "krbPrincipalName");
> > > } else {
> > > principal = slapi_ch_smprintf("root/admin@%s",
> > krbcfg->realm);
> > > }
> > > ...
> > >
> > > Maybe the root cause of the crash is that we place there a principal
> > > (root/admin@REALM) which does not exist. But this is just a
> > speculation.
> >
> > ok, the principal is odd, and I guess this should be fixed, but maybe
> > Simo knows some more history here. But nevertheless I think it is
> > unrelated to the crash, becaus afaik this information is not send to
> > the
> > client and only used for book-keeing and auditing on the server side.
> >
> I don't recall the root/admin story, looks odd to me, but nothing of
> this matter to a *client* segfaulting.
>
> Clients do not get access to this data this is purely internal metadata
> used by kadmin and the KDC.
>
> What I wonder is if the client is segfaulting when the password is
> expired due to a bug in handling the request to immediately change the
> password ?
>
> David,
> if you kinit on a Linux machine and make sure you properly change the
> password of the user (as the user no as an admin), and then kinit again
> with the new credentials on Solaris, does it 'solve' your segfault
> issue ?
>
> In any case a segfault in a client command is something you need to
> report to your OS vendor, even if it is indirectly caused by the server
> it shows a potential attack vector and it is particularly worrying in
> something like kinit that may be run as root on a box.
>
> 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] IPA - NIS Compatability

[Nalin Dahyabhai]

On Wed, Mar 27, 2013 at 11:07:44AM -0400, Joseph, Matthew (EXP) wrote:
> Here is the entry that is in dse.ldif:
> 
> Dn= nis-domain=domain.ca+nis-map=hosts.byname,CN=NIS 
> Server,cn=plugin,cn=config
> objectClass: top
> objectClass: extensibleObject
> nis-map: hosts.byname
> nis=base: cn=computers,cn=accounts,dc=domain,dc=ca
> nis-domain: domain.ca
> nis-secure: no
> creatorsName: cn=directory manager
> modifiersName: cn=directory manager
> 
> So when I run ypcat hosts it just brings up a blank entry so it is actually 
> seeing that a table should be there.
> 
> Any ideas?

Looks like you've got a typo: "nis=base" where "nis-base" was intended.

HTH,

Nalin

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

[Freeipa-users] IPA - NIS Compatability

[Joseph, Matthew (EXP)]

Hello,

I'm trying to point a Solaris 10 server to use IPA as it's "NIS Server".
The Solaris 10 server has no issues communicating with IPA but it can only see 
a few maps (Users, Groups).

Looking at the documentation it says you can add entries so I tried to for 
Hosts but I can't get ypcat hosts to bring up the hosts table.
Here is the entry that is in dse.ldif:

Dn= nis-domain=domain.ca+nis-map=hosts.byname,CN=NIS Server,cn=plugin,cn=config
objectClass: top
objectClass: extensibleObject
nis-map: hosts.byname
nis=base: cn=computers,cn=accounts,dc=domain,dc=ca
nis-domain: domain.ca
nis-secure: no
creatorsName: cn=directory manager
modifiersName: cn=directory manager


So when I run ypcat hosts it just brings up a blank entry so it is actually 
seeing that a table should be there.

Any ideas?

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

Re: [Freeipa-users] kinit seg-fault for Solaris 9

[Simo Sorce]

On Wed, 2013-03-27 at 12:23 +0100, Sumit Bose wrote:
> > 
> > I did (as admin@REALM user). But we hardcode root/admin@REALM if
> this is
> > administrative change:
> > 
> > ipapwd_chpwop():
> > ...
> > if (pwdata.changetype == IPA_CHANGETYPE_NORMAL) {
> > principal = slapi_entry_attr_get_charptr(pwdata.target,
> >
> "krbPrincipalName");
> > } else {
> > principal = slapi_ch_smprintf("root/admin@%s",
> krbcfg->realm);
> > }
> > ...
> > 
> > Maybe the root cause of the crash is that we place there a principal
> > (root/admin@REALM) which does not exist. But this is just a
> speculation.
> 
> ok, the principal is odd, and I guess this should be fixed, but maybe
> Simo knows some more history here. But nevertheless I think it is
> unrelated to the crash, becaus afaik this information is not send to
> the
> client and only used for book-keeing and auditing on the server side.
> 
I don't recall the root/admin story, looks odd to me, but nothing of
this matter to a *client* segfaulting.

Clients do not get access to this data this is purely internal metadata
used by kadmin and the KDC.

What I wonder is if the client is segfaulting when the password is
expired due to a bug in handling the request to immediately change the
password ?

David,
if you kinit on a Linux machine and make sure you properly change the
password of the user (as the user no as an admin), and then kinit again
with the new credentials on Solaris, does it 'solve' your segfault
issue ?

In any case a segfault in a client command is something you need to
report to your OS vendor, even if it is indirectly caused by the server
it shows a potential attack vector and it is particularly worrying in
something like kinit that may be run as root on a box.

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] kinit seg-fault for Solaris 9

[Sumit Bose]

On Wed, Mar 27, 2013 at 11:44:06AM +0100, Martin Kosek wrote:
> On 03/27/2013 11:36 AM, Sumit Bose wrote:
> > On Wed, Mar 27, 2013 at 10:44:53AM +0100, Martin Kosek wrote:
> >> On 03/27/2013 02:11 AM, David Redmond wrote:
> >>> Hi again,
> >>>
> >>> I've got a bit more information. I've found that I can successfully kinit 
> >>> on
> >>> the Solaris 9 clients if, on the server, I change the user's password by:
> >>>
> >>> ipa-getkeytab -s SERVER -p USER@REALM -k krb5.keytab -P
> >>>
> >>> This works even if I delete the resulting keytab file. However, kinit on 
> >>> the
> >>> Solaris 9 client seg-faults if I set the user's password using the web 
> >>> gui, the
> >>> 'passwd' or 'kpasswd' commands, or even the `ipa user-mod --password` 
> >>> command.
> >>>
> >>> There must be something different about how the ipa-getkeytab command 
> >>> stores
> >>> the password. Any help would be greatly appreciated.
> >>>
> >>> Thanks,
> >>> Dave
> >>> ~""~
> >>>
> >>> On Tue, Mar 26, 2013 at 4:05 PM, Rob Crittenden  >>> > wrote:
> >>>
> >>> David Redmond wrote:
> >>>
> >>> Hi,
> >>>
> >>> I've setup FreeIPA for the first time and am using it 
> >>> successfully with
> >>> Linux and Solaris 10 clients. On 8 separate Solaris 9 clients I'm
> >>> running into an issue where 'kinit USER', for any user, fails 
> >>> with a
> >>> segmentation fault after prompting for a password. On the client 
> >>> side
> >>> there are no log entries. On the server side the "Additional
> >>> pre-authentication required" entry is written to the log. When I 
> >>> execute
> >>> 'kinit -k' everything works normally. I've verified that the 
> >>> keytabs for
> >>> the Solaris 9 clients use only des-cbc-crc encryption and that
> >>> allow_weak_crypto = true is set on the server side. Running 
> >>> 'truss kinit
> >>> USER' on the Solaris 9 clients end with:
> >>> Incurred fault #6, FLTBOUNDS  %pc = 0xFF3582E4
> >>>siginfo: SIGSEGV SEGV_MAPERR addr=0x0004
> >>> Received signal #11, SIGSEGV (default)
> >>>siginfo: SIGSEGV SEGV_MAPERR addr=0x0004
> >>>
> >>> I've been fighting this for a while and have ensured that my 
> >>> Solaris 9
> >>> boxes are running the latest patches. Kerberos on the clients is 
> >>> the
> >>> standard one that comes with Solaris. I've installed no additional
> >>> kerberos components or packages.
> >>>
> >>> I'm hoping someone has seen this before or can point me in a new
> >>> direction. At this point I've pretty much reached the end of my 
> >>> rope and
> >>> am looking at using local passwords (blech!) on my Solaris 9 
> >>> clients.
> >>>
> >>>
> >>> I don't have a very helpful answer, but if memory serves my Sparc 9 
> >>> install
> >>> exhibits the same behavior. I don't have access to the latest updates
> >>> though so I assumed it was related to that.
> >>>
> >>> rob
> >>>
> >>
> >> Hello David,
> >>
> >> Interesting... I checked the difference in the user account when I change 
> >> the
> >> password with "ipa-getkeytab ... -P" and "ipa passwd" and I see that only
> >> krbPrincipalKey, krbLastPwdChange and krbExtraData changed:
> >>
> >> # diff /tmp/1 /tmp/2
> >> 41,48c41,49
> >> < krbPrincipalKey:: MIIBn...UVrnGY=
> >> ---
> >>> krbPrincipalKey:: MIIBx...xRoWtMY
> >> 50,51c51,52
> >> < krbLastPwdChange: 20130327084336Z
> >> < krbExtraData:: AAI4sVJRcm9vdC9hZG1pbkBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA==
> >> ---
> >>> krbLastPwdChange: 20130327084406Z
> >>> krbExtraData:: AAJWsVJRZmJhckBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA==
> >>
> >> I focused on krbExtraData and looked for differences, with "ipa passwd 
> >> $USER",
> >> we set principal "root/ad...@idm.lab.bos.redhat.com" (which looks strange 
> >> to
> >> me), while with ipa-getkeytab -P sets the principal in krbExtraData to
> >> "f...@idm.lab.bos.redhat.com". Simo, is this intended?
> > 
> > iirc this is the principal which changed the password the last time. Did
> > you run 'ipa passwd' and ipa-getkeytab with the same credentials?
> > 
> > bye,
> > Sumit
> 
> I did (as admin@REALM user). But we hardcode root/admin@REALM if this is
> administrative change:
> 
> ipapwd_chpwop():
> ...
> if (pwdata.changetype == IPA_CHANGETYPE_NORMAL) {
> principal = slapi_entry_attr_get_charptr(pwdata.target,
>  "krbPrincipalName");
> } else {
> principal = slapi_ch_smprintf("root/admin@%s", krbcfg->realm);
> }
> ...
> 
> Maybe the root cause of the crash is that we place there a principal
> (root/admin@REALM) which does not exist. But this is just a speculation.

ok, the principal is odd, and I guess this should be fixed, but maybe
Simo knows some more history here. But nevertheless I think it is
unrelated to the crash, becaus afaik this information is not send to the
cl

Re: [Freeipa-users] kinit seg-fault for Solaris 9

[Martin Kosek]

On 03/27/2013 11:36 AM, Sumit Bose wrote:
> On Wed, Mar 27, 2013 at 10:44:53AM +0100, Martin Kosek wrote:
>> On 03/27/2013 02:11 AM, David Redmond wrote:
>>> Hi again,
>>>
>>> I've got a bit more information. I've found that I can successfully kinit on
>>> the Solaris 9 clients if, on the server, I change the user's password by:
>>>
>>> ipa-getkeytab -s SERVER -p USER@REALM -k krb5.keytab -P
>>>
>>> This works even if I delete the resulting keytab file. However, kinit on the
>>> Solaris 9 client seg-faults if I set the user's password using the web gui, 
>>> the
>>> 'passwd' or 'kpasswd' commands, or even the `ipa user-mod --password` 
>>> command.
>>>
>>> There must be something different about how the ipa-getkeytab command stores
>>> the password. Any help would be greatly appreciated.
>>>
>>> Thanks,
>>> Dave
>>> ~""~
>>>
>>> On Tue, Mar 26, 2013 at 4:05 PM, Rob Crittenden >> > wrote:
>>>
>>> David Redmond wrote:
>>>
>>> Hi,
>>>
>>> I've setup FreeIPA for the first time and am using it successfully 
>>> with
>>> Linux and Solaris 10 clients. On 8 separate Solaris 9 clients I'm
>>> running into an issue where 'kinit USER', for any user, fails with a
>>> segmentation fault after prompting for a password. On the client 
>>> side
>>> there are no log entries. On the server side the "Additional
>>> pre-authentication required" entry is written to the log. When I 
>>> execute
>>> 'kinit -k' everything works normally. I've verified that the 
>>> keytabs for
>>> the Solaris 9 clients use only des-cbc-crc encryption and that
>>> allow_weak_crypto = true is set on the server side. Running 'truss 
>>> kinit
>>> USER' on the Solaris 9 clients end with:
>>> Incurred fault #6, FLTBOUNDS  %pc = 0xFF3582E4
>>>siginfo: SIGSEGV SEGV_MAPERR addr=0x0004
>>> Received signal #11, SIGSEGV (default)
>>>siginfo: SIGSEGV SEGV_MAPERR addr=0x0004
>>>
>>> I've been fighting this for a while and have ensured that my 
>>> Solaris 9
>>> boxes are running the latest patches. Kerberos on the clients is the
>>> standard one that comes with Solaris. I've installed no additional
>>> kerberos components or packages.
>>>
>>> I'm hoping someone has seen this before or can point me in a new
>>> direction. At this point I've pretty much reached the end of my 
>>> rope and
>>> am looking at using local passwords (blech!) on my Solaris 9 
>>> clients.
>>>
>>>
>>> I don't have a very helpful answer, but if memory serves my Sparc 9 
>>> install
>>> exhibits the same behavior. I don't have access to the latest updates
>>> though so I assumed it was related to that.
>>>
>>> rob
>>>
>>
>> Hello David,
>>
>> Interesting... I checked the difference in the user account when I change the
>> password with "ipa-getkeytab ... -P" and "ipa passwd" and I see that only
>> krbPrincipalKey, krbLastPwdChange and krbExtraData changed:
>>
>> # diff /tmp/1 /tmp/2
>> 41,48c41,49
>> < krbPrincipalKey:: MIIBn...UVrnGY=
>> ---
>>> krbPrincipalKey:: MIIBx...xRoWtMY
>> 50,51c51,52
>> < krbLastPwdChange: 20130327084336Z
>> < krbExtraData:: AAI4sVJRcm9vdC9hZG1pbkBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA==
>> ---
>>> krbLastPwdChange: 20130327084406Z
>>> krbExtraData:: AAJWsVJRZmJhckBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA==
>>
>> I focused on krbExtraData and looked for differences, with "ipa passwd 
>> $USER",
>> we set principal "root/ad...@idm.lab.bos.redhat.com" (which looks strange to
>> me), while with ipa-getkeytab -P sets the principal in krbExtraData to
>> "f...@idm.lab.bos.redhat.com". Simo, is this intended?
> 
> iirc this is the principal which changed the password the last time. Did
> you run 'ipa passwd' and ipa-getkeytab with the same credentials?
> 
> bye,
> Sumit

I did (as admin@REALM user). But we hardcode root/admin@REALM if this is
administrative change:

ipapwd_chpwop():
...
if (pwdata.changetype == IPA_CHANGETYPE_NORMAL) {
principal = slapi_entry_attr_get_charptr(pwdata.target,
 "krbPrincipalName");
} else {
principal = slapi_ch_smprintf("root/admin@%s", krbcfg->realm);
}
...

Maybe the root cause of the crash is that we place there a principal
(root/admin@REALM) which does not exist. But this is just a speculation.

Martin

> 
>>
>> If no and David is willing to test it, I can prepare a scratch build of 
>> FreeIPA
>> which would set user's principal to krbExtraData instead of root/admin@REALM.
>>
>> Martin
>>
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users

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

Re: [Freeipa-users] kinit seg-fault for Solaris 9

[Sumit Bose]

On Wed, Mar 27, 2013 at 10:44:53AM +0100, Martin Kosek wrote:
> On 03/27/2013 02:11 AM, David Redmond wrote:
> > Hi again,
> > 
> > I've got a bit more information. I've found that I can successfully kinit on
> > the Solaris 9 clients if, on the server, I change the user's password by:
> > 
> > ipa-getkeytab -s SERVER -p USER@REALM -k krb5.keytab -P
> > 
> > This works even if I delete the resulting keytab file. However, kinit on the
> > Solaris 9 client seg-faults if I set the user's password using the web gui, 
> > the
> > 'passwd' or 'kpasswd' commands, or even the `ipa user-mod --password` 
> > command.
> > 
> > There must be something different about how the ipa-getkeytab command stores
> > the password. Any help would be greatly appreciated.
> > 
> > Thanks,
> > Dave
> > ~""~
> > 
> > On Tue, Mar 26, 2013 at 4:05 PM, Rob Crittenden  > > wrote:
> > 
> > David Redmond wrote:
> > 
> > Hi,
> > 
> > I've setup FreeIPA for the first time and am using it successfully 
> > with
> > Linux and Solaris 10 clients. On 8 separate Solaris 9 clients I'm
> > running into an issue where 'kinit USER', for any user, fails with a
> > segmentation fault after prompting for a password. On the client 
> > side
> > there are no log entries. On the server side the "Additional
> > pre-authentication required" entry is written to the log. When I 
> > execute
> > 'kinit -k' everything works normally. I've verified that the 
> > keytabs for
> > the Solaris 9 clients use only des-cbc-crc encryption and that
> > allow_weak_crypto = true is set on the server side. Running 'truss 
> > kinit
> > USER' on the Solaris 9 clients end with:
> > Incurred fault #6, FLTBOUNDS  %pc = 0xFF3582E4
> >siginfo: SIGSEGV SEGV_MAPERR addr=0x0004
> > Received signal #11, SIGSEGV (default)
> >siginfo: SIGSEGV SEGV_MAPERR addr=0x0004
> > 
> > I've been fighting this for a while and have ensured that my 
> > Solaris 9
> > boxes are running the latest patches. Kerberos on the clients is the
> > standard one that comes with Solaris. I've installed no additional
> > kerberos components or packages.
> > 
> > I'm hoping someone has seen this before or can point me in a new
> > direction. At this point I've pretty much reached the end of my 
> > rope and
> > am looking at using local passwords (blech!) on my Solaris 9 
> > clients.
> > 
> > 
> > I don't have a very helpful answer, but if memory serves my Sparc 9 
> > install
> > exhibits the same behavior. I don't have access to the latest updates
> > though so I assumed it was related to that.
> > 
> > rob
> > 
> 
> Hello David,
> 
> Interesting... I checked the difference in the user account when I change the
> password with "ipa-getkeytab ... -P" and "ipa passwd" and I see that only
> krbPrincipalKey, krbLastPwdChange and krbExtraData changed:
> 
> # diff /tmp/1 /tmp/2
> 41,48c41,49
> < krbPrincipalKey:: MIIBn...UVrnGY=
> ---
> > krbPrincipalKey:: MIIBx...xRoWtMY
> 50,51c51,52
> < krbLastPwdChange: 20130327084336Z
> < krbExtraData:: AAI4sVJRcm9vdC9hZG1pbkBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA==
> ---
> > krbLastPwdChange: 20130327084406Z
> > krbExtraData:: AAJWsVJRZmJhckBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA==
> 
> I focused on krbExtraData and looked for differences, with "ipa passwd $USER",
> we set principal "root/ad...@idm.lab.bos.redhat.com" (which looks strange to
> me), while with ipa-getkeytab -P sets the principal in krbExtraData to
> "f...@idm.lab.bos.redhat.com". Simo, is this intended?

iirc this is the principal which changed the password the last time. Did
you run 'ipa passwd' and ipa-getkeytab with the same credentials?

bye,
Sumit

> 
> If no and David is willing to test it, I can prepare a scratch build of 
> FreeIPA
> which would set user's principal to krbExtraData instead of root/admin@REALM.
> 
> Martin
> 
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

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

Re: [Freeipa-users] kinit seg-fault for Solaris 9

[Martin Kosek]

On 03/27/2013 02:11 AM, David Redmond wrote:
> Hi again,
> 
> I've got a bit more information. I've found that I can successfully kinit on
> the Solaris 9 clients if, on the server, I change the user's password by:
> 
> ipa-getkeytab -s SERVER -p USER@REALM -k krb5.keytab -P
> 
> This works even if I delete the resulting keytab file. However, kinit on the
> Solaris 9 client seg-faults if I set the user's password using the web gui, 
> the
> 'passwd' or 'kpasswd' commands, or even the `ipa user-mod --password` command.
> 
> There must be something different about how the ipa-getkeytab command stores
> the password. Any help would be greatly appreciated.
> 
> Thanks,
> Dave
> ~""~
> 
> On Tue, Mar 26, 2013 at 4:05 PM, Rob Crittenden  > wrote:
> 
> David Redmond wrote:
> 
> Hi,
> 
> I've setup FreeIPA for the first time and am using it successfully 
> with
> Linux and Solaris 10 clients. On 8 separate Solaris 9 clients I'm
> running into an issue where 'kinit USER', for any user, fails with a
> segmentation fault after prompting for a password. On the client side
> there are no log entries. On the server side the "Additional
> pre-authentication required" entry is written to the log. When I 
> execute
> 'kinit -k' everything works normally. I've verified that the keytabs 
> for
> the Solaris 9 clients use only des-cbc-crc encryption and that
> allow_weak_crypto = true is set on the server side. Running 'truss 
> kinit
> USER' on the Solaris 9 clients end with:
> Incurred fault #6, FLTBOUNDS  %pc = 0xFF3582E4
>siginfo: SIGSEGV SEGV_MAPERR addr=0x0004
> Received signal #11, SIGSEGV (default)
>siginfo: SIGSEGV SEGV_MAPERR addr=0x0004
> 
> I've been fighting this for a while and have ensured that my Solaris 9
> boxes are running the latest patches. Kerberos on the clients is the
> standard one that comes with Solaris. I've installed no additional
> kerberos components or packages.
> 
> I'm hoping someone has seen this before or can point me in a new
> direction. At this point I've pretty much reached the end of my rope 
> and
> am looking at using local passwords (blech!) on my Solaris 9 clients.
> 
> 
> I don't have a very helpful answer, but if memory serves my Sparc 9 
> install
> exhibits the same behavior. I don't have access to the latest updates
> though so I assumed it was related to that.
> 
> rob
> 

Hello David,

Interesting... I checked the difference in the user account when I change the
password with "ipa-getkeytab ... -P" and "ipa passwd" and I see that only
krbPrincipalKey, krbLastPwdChange and krbExtraData changed:

# diff /tmp/1 /tmp/2
41,48c41,49
< krbPrincipalKey:: MIIBn...UVrnGY=
---
> krbPrincipalKey:: MIIBx...xRoWtMY
50,51c51,52
< krbLastPwdChange: 20130327084336Z
< krbExtraData:: AAI4sVJRcm9vdC9hZG1pbkBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA==
---
> krbLastPwdChange: 20130327084406Z
> krbExtraData:: AAJWsVJRZmJhckBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA==

I focused on krbExtraData and looked for differences, with "ipa passwd $USER",
we set principal "root/ad...@idm.lab.bos.redhat.com" (which looks strange to
me), while with ipa-getkeytab -P sets the principal in krbExtraData to
"f...@idm.lab.bos.redhat.com". Simo, is this intended?

If no and David is willing to test it, I can prepare a scratch build of FreeIPA
which would set user's principal to krbExtraData instead of root/admin@REALM.

Martin

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

[Freeipa-users] Announcing bind-dyndb-ldap version 2.6

[Petr Spacek]

The FreeIPA team is proud to announce bind-dyndb-ldap version 2.6.

It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/. 
The new version has also been built for Fedora 18 and is on its way to 
updates-testing:

https://admin.fedoraproject.org/updates/bind-dyndb-ldap-2.6-1.fc18,bind-9.9.2-9.P1.fc18

This release includes only bug fixes, no new features.

== Changes in 2.6 ==

[1] Invalid zones are automatically reloaded after each change in zone data.
https://fedorahosted.org/bind-dyndb-ldap/ticket/102

[2] Plugin periodically reconnects when KDC is unavailable.
https://fedorahosted.org/bind-dyndb-ldap/ticket/100

[3] Invalid wildcard name in update-policy no longer crashes BIND.
https://fedorahosted.org/bind-dyndb-ldap/ticket/108

[4] Crash caused by idnsAllowSyncPTR attribute in global configuration object
in LDAP was fixed.
https://fedorahosted.org/bind-dyndb-ldap/ticket/110

[5] Crash caused by invalid query/transfer policy was fixed.
https://fedorahosted.org/bind-dyndb-ldap/ticket/109

[6] Crash caused by 'zonesub' match-type in update ACL was fixed.
https://fedorahosted.org/bind-dyndb-ldap/ticket/111

[7] Support for update-policy match type 'external' was added.

[8] Various improvements related to logging.


== Upgrading ==

An server can be upgraded simply by installing updated rpms. BIND has to be 
restarted manually after the RPM installation.


Downgrading back to any 2.x version is supported.


== Feedback ==

Please provide comments, bugs and other feedback via the freeipa-users mailing
list: http://www.redhat.com/mailman/listinfo/freeipa-users

--
Petr Spacek
Software engineer
Red Hat

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

Re: [Freeipa-users] kinit seg-fault for Solaris 9

[Sumit Bose]

On Tue, Mar 26, 2013 at 07:05:20PM -0400, Rob Crittenden wrote:
> David Redmond wrote:
> >Hi,
> >
> >I've setup FreeIPA for the first time and am using it successfully with
> >Linux and Solaris 10 clients. On 8 separate Solaris 9 clients I'm
> >running into an issue where 'kinit USER', for any user, fails with a
> >segmentation fault after prompting for a password. On the client side
> >there are no log entries. On the server side the "Additional
> >pre-authentication required" entry is written to the log. When I execute
> >'kinit -k' everything works normally. I've verified that the keytabs for
> >the Solaris 9 clients use only des-cbc-crc encryption and that
> >allow_weak_crypto = true is set on the server side. Running 'truss kinit
> >USER' on the Solaris 9 clients end with:
> >Incurred fault #6, FLTBOUNDS  %pc = 0xFF3582E4
> >   siginfo: SIGSEGV SEGV_MAPERR addr=0x0004
> >Received signal #11, SIGSEGV (default)
> >   siginfo: SIGSEGV SEGV_MAPERR addr=0x0004
> >
> >I've been fighting this for a while and have ensured that my Solaris 9
> >boxes are running the latest patches. Kerberos on the clients is the
> >standard one that comes with Solaris. I've installed no additional
> >kerberos components or packages.
> >
> >I'm hoping someone has seen this before or can point me in a new
> >direction. At this point I've pretty much reached the end of my rope and
> >am looking at using local passwords (blech!) on my Solaris 9 clients.
> >
> 
> I don't have a very helpful answer, but if memory serves my Sparc 9
> install exhibits the same behavior. I don't have access to the
> latest updates though so I assumed it was related to that.

Maybe a network trace of the AS-REQ with tcpdump or wireshark would help
to identify the difference between kinit and kinit -k and indicate what
make kinit fails?

bye,
Sumit

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

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