[Freeipa-users] auth to pther providers still using freeipa

[Andrew Meyer via FreeIPA-users]

My company is wanting to use FreeIPA for everything.  However we also utilize 
other external services that have their own auth system but can support oauth, 
or gsuite/facebook etc etc.  Is this possible w/ FreeIPA?
Also,Searching through google I found this - Ipsilon.  Would you recommend I 
use that?
  
|  
|   |  
Ipsilon
 By Ipsilon Project Ipsilon identity provider project homepage  |  |

  |

 

Thank you!___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Problems setting up replica on Raspberry Pi 3B (ARM)

[Jonathan Vaughn via FreeIPA-users]

I've been just using the packages from Fedora. I can build it potentially
but I don't have a cross build environment set up at the moment. From
experience I'd want to do that first because building anything on the Pi
usually takes ages.

I'd been "redacting" the hostnames but I'll stop bothering since it looks
like we're getting far enough into the weeds now that the difference in
string lengths after "redacting" might actually be a red herring.

(gdb) p *agmt
$1 = {hostname = 0x1ef9be0 "ipa-12.creatuity.internal", port = 389,
transport_flags = 0, binddn = 0x1e8f650 "", creds = 0x1e8f7a0, bindmethod =
3, replarea = 0x1ef9480,
  frac_attrs = 0x1ef99c0, frac_attrs_total = 0x1ef9a40,
frac_attr_total_defined = 1, schedule = 0x1a7f0c0, auto_initialize = 502,
dn = 0x1ef8d00, rdn = 0x1ef8c20,
  long_name = 0x1a7f100 "agmt=\"cn=meToipa-12.creatuity.internal\"
(ipa-12:5)", protocol = 0x19c2930, changecounters = 0x186d180,
num_changecounters = 0,
  max_changecounters = 256, last_update_start_time = 1526500697,
last_update_end_time = 1526500697,
  last_update_status = "Error (0) Replica acquired successfully:
Incremental update succeeded", '\000' ,
update_in_progress = 0, is_enabled = 1,
  last_init_start_time = 0, last_init_end_time = 0, last_init_status =
'\000' , lock = 0x1ee3740, consumerRUV = 0x1f14e50,
  consumerSchemaCSN = 0x317c520, consumerRID = 4, tmpConsumerRID = 0,
timeout = 120, stop_in_progress = 0, busywaittime = 0, pausetime = 0, priv
= 0x0,
  attrs_to_strip = 0x1ef9ba0, agreement_type = 0, protocol_timeout =
0x1e8f5f0, maxcsn = 0x0, flowControlWindow = 1000, flowControlPause = 2000,
ignoreMissingChange = 0,
  attr_lock = 0x1ef9c20, WaitForAsyncResults = 100}
(gdb) p *agmt->replarea
$2 = {flag = 15 '\017', udn = 0x1efce80 "dc=creatuity,dc=internal", dn =
0x1ef9460 "dc=creatuity,dc=internal", ndn = 0x1ef8ec0
"dc=creatuity,dc=internal", ndn_len = 24}
(gdb) p *agmt->rdn
$3 = {flag = 0 '\000', rdn = 0x19c2840 "cn=meToipa-12.creatuity.internal",
rdns = 0x0, butcheredupto = -1, nrdn = 0x0, all_rdns = 0x0, all_nrdns = 0x0}

[root@ipa-11 ~]# grep -r PRId64 /usr/include/*
/usr/include/inttypes.h:# define PRId64 __PRI64_PREFIX "d"
[root@ipa-11 ~]# grep -r PRIu16 /usr/include/*
/usr/include/inttypes.h:# define PRIu16 "u"



On Wed, May 16, 2018 at 2:55 PM, Mark Reynolds  wrote:

>
>
> On 05/16/2018 03:43 PM, Jonathan Vaughn wrote:
>
> The installed version of 389* is 1.3.7.10-1.fc27 for armv7hl, which
> appears to be the latest available version.
>
>
> Perhaps something is off with the inttypes on Raspberry.  Are you building
> this yourself on Raspberry?  Can we make code changes and compile/install
> them?
>
> Before we do that though, in gdb can you run these commands in the same
> gdb frame:
>
> (gdb) p *agmt->replarea
> (gdb) p *agmt->rdn
>
>
> Then do:
>
> # grep -r PRId64 /usr/include/*
> # grep -r PRIu16 /usr/include/*
>
>
> So if you can compile the source, then change this line in
> ldap/servers/plugins/replication/repl5_agmt.c:3036, but don't do this yet
> until you get me the info I just requested.
>
> From:
>
> agmt->maxcsn = slapi_ch_smprintf("%s;%s;%s;%" PRId64 ";%"
> PRIu16 ";%s", slapi_sdn_get_dn(agmt->replarea),
>
> slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)), agmt->hostname,
>  agmt->port,
> agmt->consumerRID, maxcsn);
>
> To:
>
> agmt->maxcsn = slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
> slapi_sdn_get_dn(agmt->replarea),
>
> slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)), agmt->hostname,
>  (long)agmt->port,
> (int)agmt->consumerRID, maxcsn);
>
>
> Thanks,
> Mark
>
>
> On Wed, May 16, 2018 at 2:38 PM, Jonathan Vaughn 
> wrote:
>
>> (gdb) up
>> #1  0xb6926b40 in cvt_s (flags=0, prec=, width=0, str=0x4
>> , ss=)
>> at ../../.././nspr/pr/src/io/prprf.c:374
>> 374 slen = strlen(str);
>> (gdb) up
>> #2  dosprintf (ss=ss@entry=0x9e06e4bc, fmt=0xb34b0df2 "", 
>> fmt@entry=0xb34da770
>>  "\360\317p\002", ap=...) at ../../.././nspr/pr/src/io/prpr
>> f.c:1018
>> 1018rv = cvt_s(ss, u.s, width, prec, flags);
>> (gdb) up
>> #3  0xb6926c8c in PR_vsmprintf (fmt=fmt@entry=0xb34da770 
>> "\360\317p\002", ap=..., ap@entry=...) at ../../.././nspr/pr/src/io/prpr
>> f.c:1184
>> 1184rv = dosprintf(, fmt, ap);
>> (gdb) up
>> #4  0xb6de9d18 in slapi_ch_smprintf (fmt=0xb34b0de0 "%s;%s;%s;%ld;%d;%s")
>> at ldap/servers/slapd/ch_malloc.c:331
>> 331 p = PR_vsmprintf(fmt, ap);
>> (gdb) up
>> #5  0xb34625a4 in agmt_update_maxcsn (r=r@entry=0x2737810,
>> sdn=0x38d9a40, sdn@entry=0x10, op=, mods=0x10, 
>> mods@entry=0x27d0100,
>> csn=csn@entry=0x38de350)
>> at ldap/servers/plugins/replication/repl5_agmt.c:3036
>> 3036agmt->maxcsn = 
>> slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
>> slapi_sdn_get_dn(agmt->replarea),
>> (gdb) p *agmt
>> $1 = {hostname 

[Freeipa-users] Re: Problems setting up replica on Raspberry Pi 3B (ARM)

[Mark Reynolds via FreeIPA-users]

On 05/16/2018 03:43 PM, Jonathan Vaughn wrote:
> The installed version of 389* is 1.3.7.10-1.fc27 for armv7hl, which
> appears to be the latest available version.

Perhaps something is off with the inttypes on Raspberry.  Are you
building this yourself on Raspberry?  Can we make code changes and
compile/install them?

Before we do that though, in gdb can you run these commands in the same
gdb frame:

(gdb) p *agmt->replarea
(gdb) p *agmt->rdn


Then do:

# grep -r PRId64 /usr/include/*
# grep -r PRIu16 /usr/include/*


So if you can compile the source, then change this line in
ldap/servers/plugins/replication/repl5_agmt.c:3036, but don't do this
yet until you get me the info I just requested.

From:

    agmt->maxcsn = slapi_ch_smprintf("%s;%s;%s;%" PRId64
";%" PRIu16 ";%s", slapi_sdn_get_dn(agmt->replarea),

slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)), agmt->hostname,
 agmt->port,
agmt->consumerRID, maxcsn);

To:

    agmt->maxcsn = slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
slapi_sdn_get_dn(agmt->replarea),

slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)), agmt->hostname,
 (long)agmt->port,
(int)agmt->consumerRID, maxcsn);


Thanks,
Mark
>
> On Wed, May 16, 2018 at 2:38 PM, Jonathan Vaughn
> > wrote:
>
> (gdb) up
> #1  0xb6926b40 in cvt_s (flags=0, prec=, width=0,
> str=0x4 ,
> ss=)
>     at ../../.././nspr/pr/src/io/prprf.c:374
> 374             slen = strlen(str);
> (gdb) up
> #2  dosprintf (ss=ss@entry=0x9e06e4bc, fmt=0xb34b0df2 "",
> fmt@entry=0xb34da770  "\360\317p\002", ap=...) at
> ../../.././nspr/pr/src/io/prprf.c:1018
> 1018                rv = cvt_s(ss, u.s, width, prec, flags);
> (gdb) up
> #3  0xb6926c8c in PR_vsmprintf (fmt=fmt@entry=0xb34da770
>  "\360\317p\002", ap=..., ap@entry=...) at
> ../../.././nspr/pr/src/io/prprf.c:1184
> 1184        rv = dosprintf(, fmt, ap);
> (gdb) up
> #4  0xb6de9d18 in slapi_ch_smprintf (fmt=0xb34b0de0
> "%s;%s;%s;%ld;%d;%s") at ldap/servers/slapd/ch_malloc.c:331
> 331         p = PR_vsmprintf(fmt, ap);
> (gdb) up
> #5  0xb34625a4 in agmt_update_maxcsn (r=r@entry=0x2737810,
> sdn=0x38d9a40, sdn@entry=0x10, op=, mods=0x10,
> mods@entry=0x27d0100, csn=csn@entry=0x38de350)
>     at ldap/servers/plugins/replication/repl5_agmt.c:3036
> 3036                    agmt->maxcsn =
> slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
> slapi_sdn_get_dn(agmt->replarea),
> (gdb) p *agmt
> $1 = {hostname = 0x2757be0 "ipa-12.company.internal", port = 389,
> transport_flags = 0, binddn = 0x26ed650 "", creds = 0x26ed7a0,
> bindmethod = 3, replarea = 0x2757480,
>   frac_attrs = 0x27579c0, frac_attrs_total = 0x2757a40,
> frac_attr_total_defined = 1, schedule = 0x22dd0c0, auto_initialize
> = 502, dn = 0x2756d00, rdn = 0x2756c20,
>   long_name = 0x22dd100 "agmt=\"cn=meToipa-12.company.internal\"
> (ipa-12:5)", protocol = 0x2220930, changecounters = 0x20cb180,
> num_changecounters = 0,
>   max_changecounters = 256, last_update_start_time = 1526499214,
> last_update_end_time = 1526499214,
>   last_update_status = "Error (0) Replica acquired successfully:
> Incremental update succeeded", '\000' ,
> update_in_progress = 0, is_enabled = 1,
>   last_init_start_time = 0, last_init_end_time = 0,
> last_init_status = '\000' , lock = 0x2741740,
> consumerRUV = 0x2772e50,
>   consumerSchemaCSN = 0x39da520, consumerRID = 4, tmpConsumerRID =
> 0, timeout = 120, stop_in_progress = 0, busywaittime = 0,
> pausetime = 0, priv = 0x0,
>   attrs_to_strip = 0x2757ba0, agreement_type = 0, protocol_timeout
> = 0x26ed5f0, maxcsn = 0x0, flowControlWindow = 1000,
> flowControlPause = 2000, ignoreMissingChange = 0,
>   attr_lock = 0x2757c20, WaitForAsyncResults = 100}
>
>
> On Tue, May 15, 2018 at 5:36 PM, Mark Reynolds
> > wrote:
>
> This looks really familiar and I thought it was fixed.  It
> should have been fixed in 1.3.7.10-1
> (https://pagure.io/389-ds-base/issue/49618
> ).   In your debug
> session go "up" into agmt_maxcsn_update() and do:
>
> (gdb) p *agmt
>
> Then send us that output please.
>
> Thanks,
> Mark
>
>
> On 05/15/2018 05:29 PM, Jonathan Vaughn via FreeIPA-users wrote:
>> Here is a backtrace from live gdb after the segfault. Looks
>> like things went wrong somewhere during in the replication
>> code ?
>>
>> Thread 36 "ns-slapd" received signal SIGSEGV, Segmentation fault.
>> [Switching to 

[Freeipa-users] Re: Problems setting up replica on Raspberry Pi 3B (ARM)

[Jonathan Vaughn via FreeIPA-users]

The installed version of 389* is 1.3.7.10-1.fc27 for armv7hl, which appears
to be the latest available version.

On Wed, May 16, 2018 at 2:38 PM, Jonathan Vaughn 
wrote:

> (gdb) up
> #1  0xb6926b40 in cvt_s (flags=0, prec=, width=0, str=0x4
> , ss=)
> at ../../.././nspr/pr/src/io/prprf.c:374
> 374 slen = strlen(str);
> (gdb) up
> #2  dosprintf (ss=ss@entry=0x9e06e4bc, fmt=0xb34b0df2 "", fmt@entry=0xb34da770
>  "\360\317p\002", ap=...) at ../../.././nspr/pr/src/io/
> prprf.c:1018
> 1018rv = cvt_s(ss, u.s, width, prec, flags);
> (gdb) up
> #3  0xb6926c8c in PR_vsmprintf (fmt=fmt@entry=0xb34da770 
> "\360\317p\002", ap=..., ap@entry=...) at ../../.././nspr/pr/src/io/
> prprf.c:1184
> 1184rv = dosprintf(, fmt, ap);
> (gdb) up
> #4  0xb6de9d18 in slapi_ch_smprintf (fmt=0xb34b0de0 "%s;%s;%s;%ld;%d;%s")
> at ldap/servers/slapd/ch_malloc.c:331
> 331 p = PR_vsmprintf(fmt, ap);
> (gdb) up
> #5  0xb34625a4 in agmt_update_maxcsn (r=r@entry=0x2737810, sdn=0x38d9a40,
> sdn@entry=0x10, op=, mods=0x10, mods@entry=0x27d0100,
> csn=csn@entry=0x38de350)
> at ldap/servers/plugins/replication/repl5_agmt.c:3036
> 3036agmt->maxcsn = slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
> slapi_sdn_get_dn(agmt->replarea),
> (gdb) p *agmt
> $1 = {hostname = 0x2757be0 "ipa-12.company.internal", port = 389,
> transport_flags = 0, binddn = 0x26ed650 "", creds = 0x26ed7a0, bindmethod =
> 3, replarea = 0x2757480,
>   frac_attrs = 0x27579c0, frac_attrs_total = 0x2757a40,
> frac_attr_total_defined = 1, schedule = 0x22dd0c0, auto_initialize = 502,
> dn = 0x2756d00, rdn = 0x2756c20,
>   long_name = 0x22dd100 "agmt=\"cn=meToipa-12.company.internal\"
> (ipa-12:5)", protocol = 0x2220930, changecounters = 0x20cb180,
> num_changecounters = 0,
>   max_changecounters = 256, last_update_start_time = 1526499214,
> last_update_end_time = 1526499214,
>   last_update_status = "Error (0) Replica acquired successfully:
> Incremental update succeeded", '\000' ,
> update_in_progress = 0, is_enabled = 1,
>   last_init_start_time = 0, last_init_end_time = 0, last_init_status =
> '\000' , lock = 0x2741740, consumerRUV = 0x2772e50,
>   consumerSchemaCSN = 0x39da520, consumerRID = 4, tmpConsumerRID = 0,
> timeout = 120, stop_in_progress = 0, busywaittime = 0, pausetime = 0, priv
> = 0x0,
>   attrs_to_strip = 0x2757ba0, agreement_type = 0, protocol_timeout =
> 0x26ed5f0, maxcsn = 0x0, flowControlWindow = 1000, flowControlPause = 2000,
> ignoreMissingChange = 0,
>   attr_lock = 0x2757c20, WaitForAsyncResults = 100}
>
>
> On Tue, May 15, 2018 at 5:36 PM, Mark Reynolds 
> wrote:
>
>> This looks really familiar and I thought it was fixed.  It should have
>> been fixed in 1.3.7.10-1 (https://pagure.io/389-ds-base/issue/49618).
>> In your debug session go "up" into agmt_maxcsn_update() and do:
>>
>> (gdb) p *agmt
>>
>> Then send us that output please.
>>
>> Thanks,
>> Mark
>>
>>
>> On 05/15/2018 05:29 PM, Jonathan Vaughn via FreeIPA-users wrote:
>>
>> Here is a backtrace from live gdb after the segfault. Looks like things
>> went wrong somewhere during in the replication code ?
>>
>> Thread 36 "ns-slapd" received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x9e0bc280 (LWP 4662)]
>> strlen () at ../sysdeps/arm/armv6t2/strlen.S:142
>> 142 ldrddata1a, data1b, [src]
>> (gdb) bt
>> #0  0xb6728f2e in strlen () at ../sysdeps/arm/armv6t2/strlen.S:142
>> #1  0xb6973b40 in cvt_s (flags=0, prec=, width=0, str=0x4
>> , ss=)
>> at ../../.././nspr/pr/src/io/prprf.c:374
>> #2  0xb6973b40 in dosprintf (ss=ss@entry=0x9e0bb4bc, fmt=0xb34fddf2 "",
>> fmt@entry=0xb3527770  "\360\357\305\002", ap=...)
>> at ../../.././nspr/pr/src/io/prprf.c:1018
>> #3  0xb6973c8c in PR_vsmprintf (fmt=fmt@entry=0xb3527770 
>> "\360\357\305\002", ap=..., ap@entry=...) at
>> ../../.././nspr/pr/src/io/prprf.c:1184
>> #4  0xb6e36d18 in slapi_ch_smprintf (fmt=0xb34fdde0 "%s;%s;%s;%ld;%d;%s")
>> at ldap/servers/slapd/ch_malloc.c:331
>> #5  0xb34af5a4 in agmt_update_maxcsn (r=r@entry=0x2c89810,
>> sdn=0x3e2bac0, sdn@entry=0x10, op=, mods=0x10, 
>> mods@entry=0x3eec100,
>> csn=csn@entry=0x3e30220)
>> at ldap/servers/plugins/replication/repl5_agmt.c:3036
>> #6  0xb34bd424 in write_changelog_and_ruv (pb=pb@entry=0x2cb54a0) at
>> ldap/servers/plugins/replication/repl5_plugins.c:1124
>> #7  0xb34be7ec in multimaster_be_betxnpostop_add (pb=0x2cb54a0) at
>> ldap/servers/plugins/replication/repl5_plugins.c:855
>> #8  0xb34be880 in multimaster_mmr_postop (pb=, flags=560)
>> at ldap/servers/plugins/replication/repl5_plugins.c:616
>> #9  0xb6e8fcf0 in plugin_call_mmr_plugin_postop (pb=pb@entry=0x2cb54a0,
>> e=e@entry=0x0, flags=flags@entry=560) at ldap/servers/slapd/plugin_mmr.
>> c:65
>> #10 0xb35ba870 in ldbm_back_add (pb=0x2cb54a0) at
>> ldap/servers/slapd/back-ldbm/ldbm_add.c:1218
>> #11 0xb6e2ce4c in op_shared_add (pb=pb@entry=0x2cb54a0) at
>> 

[Freeipa-users] Re: Problems setting up replica on Raspberry Pi 3B (ARM)

[Jonathan Vaughn via FreeIPA-users]

(gdb) up
#1  0xb6926b40 in cvt_s (flags=0, prec=, width=0, str=0x4
, ss=)
at ../../.././nspr/pr/src/io/prprf.c:374
374 slen = strlen(str);
(gdb) up
#2  dosprintf (ss=ss@entry=0x9e06e4bc, fmt=0xb34b0df2 "", fmt@entry=0xb34da770
 "\360\317p\002", ap=...) at
../../.././nspr/pr/src/io/prprf.c:1018
1018rv = cvt_s(ss, u.s, width, prec, flags);
(gdb) up
#3  0xb6926c8c in PR_vsmprintf (fmt=fmt@entry=0xb34da770 
"\360\317p\002", ap=..., ap@entry=...) at
../../.././nspr/pr/src/io/prprf.c:1184
1184rv = dosprintf(, fmt, ap);
(gdb) up
#4  0xb6de9d18 in slapi_ch_smprintf (fmt=0xb34b0de0 "%s;%s;%s;%ld;%d;%s")
at ldap/servers/slapd/ch_malloc.c:331
331 p = PR_vsmprintf(fmt, ap);
(gdb) up
#5  0xb34625a4 in agmt_update_maxcsn (r=r@entry=0x2737810, sdn=0x38d9a40,
sdn@entry=0x10, op=, mods=0x10, mods@entry=0x27d0100,
csn=csn@entry=0x38de350)
at ldap/servers/plugins/replication/repl5_agmt.c:3036
3036agmt->maxcsn =
slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s", slapi_sdn_get_dn(agmt->replarea),
(gdb) p *agmt
$1 = {hostname = 0x2757be0 "ipa-12.company.internal", port = 389,
transport_flags = 0, binddn = 0x26ed650 "", creds = 0x26ed7a0, bindmethod =
3, replarea = 0x2757480,
  frac_attrs = 0x27579c0, frac_attrs_total = 0x2757a40,
frac_attr_total_defined = 1, schedule = 0x22dd0c0, auto_initialize = 502,
dn = 0x2756d00, rdn = 0x2756c20,
  long_name = 0x22dd100 "agmt=\"cn=meToipa-12.company.internal\"
(ipa-12:5)", protocol = 0x2220930, changecounters = 0x20cb180,
num_changecounters = 0,
  max_changecounters = 256, last_update_start_time = 1526499214,
last_update_end_time = 1526499214,
  last_update_status = "Error (0) Replica acquired successfully:
Incremental update succeeded", '\000' ,
update_in_progress = 0, is_enabled = 1,
  last_init_start_time = 0, last_init_end_time = 0, last_init_status =
'\000' , lock = 0x2741740, consumerRUV = 0x2772e50,
  consumerSchemaCSN = 0x39da520, consumerRID = 4, tmpConsumerRID = 0,
timeout = 120, stop_in_progress = 0, busywaittime = 0, pausetime = 0, priv
= 0x0,
  attrs_to_strip = 0x2757ba0, agreement_type = 0, protocol_timeout =
0x26ed5f0, maxcsn = 0x0, flowControlWindow = 1000, flowControlPause = 2000,
ignoreMissingChange = 0,
  attr_lock = 0x2757c20, WaitForAsyncResults = 100}


On Tue, May 15, 2018 at 5:36 PM, Mark Reynolds  wrote:

> This looks really familiar and I thought it was fixed.  It should have
> been fixed in 1.3.7.10-1 (https://pagure.io/389-ds-base/issue/49618).
> In your debug session go "up" into agmt_maxcsn_update() and do:
>
> (gdb) p *agmt
>
> Then send us that output please.
>
> Thanks,
> Mark
>
>
> On 05/15/2018 05:29 PM, Jonathan Vaughn via FreeIPA-users wrote:
>
> Here is a backtrace from live gdb after the segfault. Looks like things
> went wrong somewhere during in the replication code ?
>
> Thread 36 "ns-slapd" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x9e0bc280 (LWP 4662)]
> strlen () at ../sysdeps/arm/armv6t2/strlen.S:142
> 142 ldrddata1a, data1b, [src]
> (gdb) bt
> #0  0xb6728f2e in strlen () at ../sysdeps/arm/armv6t2/strlen.S:142
> #1  0xb6973b40 in cvt_s (flags=0, prec=, width=0, str=0x4
> , ss=)
> at ../../.././nspr/pr/src/io/prprf.c:374
> #2  0xb6973b40 in dosprintf (ss=ss@entry=0x9e0bb4bc, fmt=0xb34fddf2 "",
> fmt@entry=0xb3527770  "\360\357\305\002", ap=...)
> at ../../.././nspr/pr/src/io/prprf.c:1018
> #3  0xb6973c8c in PR_vsmprintf (fmt=fmt@entry=0xb3527770 
> "\360\357\305\002", ap=..., ap@entry=...) at ../../.././nspr/pr/src/io/
> prprf.c:1184
> #4  0xb6e36d18 in slapi_ch_smprintf (fmt=0xb34fdde0 "%s;%s;%s;%ld;%d;%s")
> at ldap/servers/slapd/ch_malloc.c:331
> #5  0xb34af5a4 in agmt_update_maxcsn (r=r@entry=0x2c89810, sdn=0x3e2bac0,
> sdn@entry=0x10, op=, mods=0x10, mods@entry=0x3eec100,
> csn=csn@entry=0x3e30220)
> at ldap/servers/plugins/replication/repl5_agmt.c:3036
> #6  0xb34bd424 in write_changelog_and_ruv (pb=pb@entry=0x2cb54a0) at
> ldap/servers/plugins/replication/repl5_plugins.c:1124
> #7  0xb34be7ec in multimaster_be_betxnpostop_add (pb=0x2cb54a0) at
> ldap/servers/plugins/replication/repl5_plugins.c:855
> #8  0xb34be880 in multimaster_mmr_postop (pb=, flags=560)
> at ldap/servers/plugins/replication/repl5_plugins.c:616
> #9  0xb6e8fcf0 in plugin_call_mmr_plugin_postop (pb=pb@entry=0x2cb54a0,
> e=e@entry=0x0, flags=flags@entry=560) at ldap/servers/slapd/plugin_mmr.
> c:65
> #10 0xb35ba870 in ldbm_back_add (pb=0x2cb54a0) at
> ldap/servers/slapd/back-ldbm/ldbm_add.c:1218
> #11 0xb6e2ce4c in op_shared_add (pb=pb@entry=0x2cb54a0) at
> ldap/servers/slapd/add.c:679
> #12 0xb6e2d35c in add_internal_pb (pb=pb@entry=0x2cb54a0) at
> ldap/servers/slapd/add.c:407
> #13 0xb6e2e0f8 in slapi_add_internal_pb (pb=pb@entry=0x2cb54a0) at
> ldap/servers/slapd/add.c:332
> #14 0xb368db50 in ipa_topo_util_segment_write (tconf=tconf@entry=0x2cb5860,
> tsegm=tsegm@entry=0x3f2d9a0) at topology_util.c:1251
> #15 0xb368e01c in 

[Freeipa-users] Re: Integrations with non-linux environments

[Jeffrey Parker via FreeIPA-users]

I did that and it seemed to be better, could see the users, browse the tree, 
etc, but when logging in as one of the FreeIPA users the login just fails like 
before.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: LDAP encryption errors

[Rob Crittenden via FreeIPA-users]

Per Qvindesland via FreeIPA-users wrote:
> Hi Alexander 
> 
> Here is the object we are trying to change the password with:
> dn: uid=tes...@jisc3.ac.uk
> ,cn=users,cn=accounts,dc=jisc,dc=ac,dc=uk
> changetype: add
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: inetuser
> objectClass: posixaccount
> objectClass: krbprincipalaux
> objectClass: krbticketpolicyaux
> objectClass: krbPrincipalName
> objectClass: ipaobject
> objectClass: ipasshuser
> objectClass: ipaSshGroupOfPubKeys
> objectClass: mepOriginEntry
> objectClass: eduPerson
> uid: tes...@jisc3.ac.uk 
> givenName: NULL
> sn: NULL
> cn: wnQ6gpxNEbYDP4e0xSi42QvNLR4=
> displayName: displayName not set
> ou: Local
> eduPersonAffiliation: affiliate
> mail: tes...@jisc3.ac.uk 
> userPassword: e1NIQX1rYjBwdk45WkpLVGpmMHdiMGJqYm5LSk10Vnk7
> loginshell: /bin/sh
> homedirectory: /home/tes...@jisc3.ac.uk 
> gidnumber: 109214
> uidnumber: 109214

You added krbPrincipalName as an objectclass. That doesn't exist and I'm
at a loss to how you were able to add it at all.

You need to add:

krbPrincipalname: tester@REALM

and drop the bogus objectclass.

rob
> 
> Is there anything you can suggest?
> 
> Regards
> Per
> 
> 
> 
> 
>> On 11 May 2018, at 10:31, Alexander Bokovoy via FreeIPA-users
>> > > wrote:
>>
>> On pe, 11 touko 2018, Per Qvindesland via FreeIPA-users wrote:
>>> Hi All
>>>
>>> We’re getting the following entries in the error logs
>>>
>>> [10/May/2018:15:37:18.628665013 +0100] - ERR -
>>> ipapwd_encrypt_encode_key - [file encoding.c, line 143]: no
>>> krbPrincipalName present in this entry
>>> [10/May/2018:15:37:18.630473873 +0100] - ERR - ipapwd_gen_hashes -
>>> [file encoding.c, line 234]: key encryption/encoding failed
>>>
>>> Is this related to the failed binds? is there any ways of turning on
>>> debug logging
>> You have or are trying to add an object in LDAP that is not a Kerberos
>> principal, yet somehow
>> object classes imply it should be a Kerberos principal.
>> You'd need to show the object or explain what are you doing.
>>
>>>
>>> The connection string is  $ds = ldap_connect($hostport, $port); then
>>> we are setting some connection options: ldap_set_option($ds,
>>> LDAP_OPT_PROTOCOL_VERSION, 3);
>>>   ldap_set_option($ds, LDAP_OPT_REFERRALS, 0); Then binding using
>>> admin credential:$result = ldap_bind($ds, $rdn, $pass)
>>>
>>> We can connect to freeipa but we are suspecting that we might be
>>> using the wrong encryption  {SHA} in plain text then results in err
>>> 19 which results in operations error.
>> No, this is not about connection to ldap but rather adding an LDAP
>> object or attempting to modify a password on existing object.
>>
>>
>> -- 
>> / Alexander Bokovoy
>> Sr. Principal Software Engineer
>> Security / Identity Management Engineering
>> Red Hat Limited, Finland
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> 
>> To unsubscribe send an email to
>> freeipa-users-le...@lists.fedorahosted.org
>> 
> 
> 
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Update Zanata ipa.pot

[Levin Stanislav via FreeIPA-users]

Thank you for a kindly support.

We'll improve Russian status ;-)


16.05.2018 17:17, Alexander Bokovoy via FreeIPA-users пишет:
> On ke, 16 touko 2018, Alexander Bokovoy via FreeIPA-users wrote:
>> On ke, 16 touko 2018, Levin Stanislav via FreeIPA-users wrote:
>>> Dear Dev Team,
>>>
>>> I've checked PR 1926 (Update 4.7 translations) - Russian part.
>>>
>>>
>>> According to Zanata
>>> (https://fedora.zanata.org/iteration/view/freeipa/master/languages/ru?dswid=7474#)
>>>  
>>>
>>> progress is ~99%.
>>>
>>> But actually there are missing translations.
>>>
>>>
>>> The reason - ipa.pot file is slightly outdated:
>>>
>>> /"Project-Id-Version: freeipa 4.5.90.dev201709011157+git5dcb0e6fc\n"//
>>> //"POT-Creation-Date: 2017-09-01 13:58+0200\n"./
>>>
>>> /
>>> /
>>>
>>> According to release page https://www.freeipa.org/page/Release
>>>

    Push source documents to Zanata server

 !!! This should be done periodically *weeks* and *months* before
 release to give time to translators

>>> /
>>> /
>>>
>>> Please somebody push an updated ipa.pot to Zanata or tell me who can do
>>> it ( i'll contact with ).
>> Rob was updating it yesterday but I'm not sure how that ended up, may be
>> he wasn't able to push to Zanata yet.
>>
>> Don't worry, we are at 4.6.90.pre2 right now and current coverage for
>> Russian language is very good even with old pot file:
>>
>> ru.po: 4168 translated messages, 96 untranslated messages.
>>
>> Hopefully, we'll get Zanata updated this week and you'll have few more
>> weeks before 4.7 release to complete the translation.
> We updated translation table in Zanata:
>
>    Ukrainian  uk    97.17%
>    Russian    ru    96.44%
>    French fr    53.6%
>    Chinese (China)    zh-CN 35.78%
>    Spanish    es    21.07%
>    German de    10.51%
>    Slovak sk    5.53%
>    Polish pl    3.47%
>



signature.asc
Description: OpenPGP digital signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Update Zanata ipa.pot

[Alexander Bokovoy via FreeIPA-users]

On ke, 16 touko 2018, Alexander Bokovoy via FreeIPA-users wrote:

On ke, 16 touko 2018, Levin Stanislav via FreeIPA-users wrote:

Dear Dev Team,

I've checked PR 1926 (Update 4.7 translations) - Russian part.


According to Zanata
(https://fedora.zanata.org/iteration/view/freeipa/master/languages/ru?dswid=7474#)
 
progress is ~99%.

But actually there are missing translations.


The reason - ipa.pot file is slightly outdated:

/"Project-Id-Version: freeipa 4.5.90.dev201709011157+git5dcb0e6fc\n"//
//"POT-Creation-Date: 2017-09-01 13:58+0200\n"./

/
/

According to release page https://www.freeipa.org/page/Release



   Push source documents to Zanata server

!!! This should be done periodically *weeks* and *months* before
release to give time to translators


/
/

Please somebody push an updated ipa.pot to Zanata or tell me who can do
it ( i'll contact with ).

Rob was updating it yesterday but I'm not sure how that ended up, may be
he wasn't able to push to Zanata yet.

Don't worry, we are at 4.6.90.pre2 right now and current coverage for
Russian language is very good even with old pot file:

ru.po: 4168 translated messages, 96 untranslated messages.

Hopefully, we'll get Zanata updated this week and you'll have few more
weeks before 4.7 release to complete the translation.

We updated translation table in Zanata:

   Ukrainian  uk97.17%
   Russianru96.44%
   French fr53.6%
   Chinese (China)zh-CN 35.78%
   Spanishes21.07%
   German de10.51%
   Slovak sk5.53%
   Polish pl3.47%

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Update Zanata ipa.pot

[Rob Crittenden via FreeIPA-users]

Alexander Bokovoy via FreeIPA-users wrote:
> On ke, 16 touko 2018, Levin Stanislav via FreeIPA-users wrote:
>> Dear Dev Team,
>>
>> I've checked PR 1926 (Update 4.7 translations) - Russian part.
>>
>>
>> According to Zanata
>> (https://fedora.zanata.org/iteration/view/freeipa/master/languages/ru?dswid=7474#)
>>  
>>
>> progress is ~99%.
>>
>> But actually there are missing translations.
>>
>>
>> The reason - ipa.pot file is slightly outdated:
>>
>> /"Project-Id-Version: freeipa 4.5.90.dev201709011157+git5dcb0e6fc\n"//
>> //"POT-Creation-Date: 2017-09-01 13:58+0200\n"./
>>
>> /
>> /
>>
>> According to release page https://www.freeipa.org/page/Release
>>
>>>
>>>     Push source documents to Zanata server
>>>
>>> !!! This should be done periodically *weeks* and *months* before
>>> release to give time to translators
>>>
>> /
>> /
>>
>> Please somebody push an updated ipa.pot to Zanata or tell me who can do
>> it ( i'll contact with ).
> Rob was updating it yesterday but I'm not sure how that ended up, may be
> he wasn't able to push to Zanata yet.
> 
> Don't worry, we are at 4.6.90.pre2 right now and current coverage for
> Russian language is very good even with old pot file:
> 
> ru.po: 4168 translated messages, 96 untranslated messages.
> 
> Hopefully, we'll get Zanata updated this week and you'll have few more
> weeks before 4.7 release to complete the translation.
> 

I just finished updating it.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Dir Mgr passwd won't change?

[Kat via FreeIPA-users]

Hi -

Have a replica I did not install CA on. Want to add it. I had lost the 
Directory Manager password, so I followed procedure to change it by 
editing dse.ldif and replacing the rootpw, but no matter what I do I 
keep getting:


[root@ipa-rep2 ~]# ipa-ca-install
Directory Manager (existing master) password:

Directory Manager password is invalid

Scratching my head - has the procedure for changing the Dir Mgr password 
changed? I used:


http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html

Any ideas?
-K
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Announcing FreeIPA v4.6.90.pre2 release

[Rob Crittenden via FreeIPA-users]

The FreeIPA team would like to announce FreeIPA 4.6.90.pre2 release!

It can be downloaded from http://www.freeipa.org/page/Downloads. Builds
for Fedora 28 and rawhide will be available in the Fedora repositories.

== Highlights in 4.6.90.pre2 ==

The major new features of this release are:
* Switch from using mod_nss for the Apache TLS engine to using mod_ssl.
Upgrading will move the certificates and keys from /etc/httpd/alias to
/var/lib/ipa/certs/.
* Switch time client and server from ntp to chrony.
* Switch from using authconfig to authselect to configure the PAM stack.
* Kerberos clients can now use SPAKE to strengthen their handshake with
  a FreeIPA KDC based on elliptic curve cryptography. See IETF draft
  draft-ietf-kitten-krb-spake-preauth-05 and relevant portions of
  krb5.conf(5) and kdc.conf(5) for details. SPAKE is enabled for new IPA
  servers and clients by default.
* Thanks to our translation volunteers, FreeIPA 4.6.90.pre2 sees a major
  update for Chinese, French, Russian, and Ukrainian languages.

=== Known Issues ===

=== Bug fixes ===
FreeIPA 4.6.90.pre2 is a preview release for the features delivered as a
part of 4.7.0.

There are more than 70 bug-fixes details of which can be seen ina
the list of resolved tickets below.

== Upgrading ==

Upgrade instructions are available on [[Upgrade]] page.

== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users
mailing
list
(https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/)
or #freeipa channel on Freenode.


== Resolved tickets ==
* 7530 external CA replica installation fails with CA_UNREACHABLE
* 7529 AVC denials and errors for IPA server installed on Fedora28
* 7524 ipa-client-install fails because of missing file
/usr/share/ipa/freeipa.template
* 7523 external CA installation: step two reports self-signed configuration
* 7520 ipa certmap-match throwing "ipa: ERROR: an internal error has
occurred"
* 7519 Adding SSH keys for AD users as I created overrides
* 7518 Improve Custodia client and key distribution handling
* 7515 ipa-advise config-server-for-smart-card-auth refers to nss.conf
despite the migration to ssl.conf
* 7514 Allow to create Kerberos services without a corresponding host object
* 7513 Allow Kerberos services to be members of IPA groups
* 7512 Missing dependency for freeipa-client: python3-augeas
* 7510 validate_selinuxuser does not allow a period in selinux user
identifier
* 7508 Trust tests for Posix support are failing with Assertion Error
None on Windows Server 2016
* 7507 ui_tests: extend test_user suite
* 7505 WebUI tests: Extend netgroup tests
* 7503 multiple occurrences of profileId in certprofile causes incorrect
behaviour
* 7499 Integration tests dns_location in regards of check NTP records
failing
* 7498 [F28] CA replica fails with could not find certificate named
"caSigningCert cert-pki-ca"
* 7496 csrgen fails if subject base contains lower-case attribute names
* 7490 installutils.set_directive doesn't handle debian ssl.conf properly
* 7489 Test test_caless_TestCertInstall is failing in nightly
* 7488 Set nsds5ReplicaReleaseTimeout on all replicas and databases
* 7486 Allow hosts to delete their own services
* 7485 Extending webui user group test
* 7484 Load ipaclient.csrgen on demand to speed up CLI
* 7478 [F28] ipa-backup fails with "Failed to execute authconfig command"
* 7474 ipa-server-install --uninstall on replica fails with
"NoOptionError: No option 'ldap_uri' in section: 'global'"
* 7473 ERROR: No valid Negotiate header in server response
* 7470 TestBasicADTrust.test_ipauser_authentication is failing with
error "Confidentiality required"
* 7469 ipa-replica-prepare fail with "stat: path should be string,
bytes, os.PathLike or integer, not NoneType"
* 7468 test_host.py::test_host::test_crud is failing in nightly tests
* 7466 [F28] Replica installs fails with CA_REJECTED caused by ACIError
* 7463 test_webui: add user life-cycles tests
* 7461 Hardening of topology plugin to prevent erronous deletion of a
replica agreement
* 7459 [RFE] replica-install: warn when only one CA exists in topology
* 7458  ui_tests: extend test_hostgroup.py suite
* 7456 ipa otptoken-add should use LDAP Whoami call
* 7454 Upgrade from F27 to F28 produces an error while updating
ipa.conf.template
* 7450 "This entry already exists" error when upgrading on IPA 4.5
* 7442 Replication agreement status incorrectly checked
* 7441 ui_tests: extend test_service.py suite
* 7436 ipa: Please log something after restarting the KDC
* 7427 User Administrator doesn't have enough privileges to edit
homeDirectory attribute
* 7426 DogtagInstance.backup_config creates backup with wrong owner
* 7425 ipa-server-install with different IP fails on /usr/sbin/pkispawn
-s CA
* 7424 Improve Realm Domains doc text
* 7421 Store HTTPD private keys encrypted
* 7415 CA installer need to check availability of port 8080
* 7410 ipa-replica-install --add-agents option doesn't install
trust-agent on replica
* 

[Freeipa-users] Re: some basic questions about FreeIPA

[Udo Rader via FreeIPA-users]

On Mon, 2018-05-14 at 14:50 +0200, dbisc...@hrz.uni-kassel.de wrote:
> Udo,
> 
> On Fri, 11 May 2018, Udo Rader via FreeIPA-users wrote:
> 
> > But what about DHCP and DNS? I understand that FreeIPA's backbone
> > is the 
> > 389 DS. I guess migrating our DHCP DIT into 389 is doable, but
> > what 
> > about administration of those entries? Can this be done by FreeIPA?
> > 
> > Regarding DHCP, all I found were some older documents describing 
> > intentions to implement it [1], but I'm uncertain if that ever
> > happened.
> > 
> > Regarding DNS, I am aware that FreeIPA comes with bind, but if
> > possible, 
> > I'd really like to stay with PowerDNS. Is that possible? And if
> > not, how 
> > tightly integrated is bind into FreeIPA? One mandatory requirement
> > is 
> > that we need to have multiple, geographically distributed
> > nameservers 
> > that hold various amounts of DNS data (currently determined by
> > LDAP 
> > filters). I of course understand that bind is perfectly capable of
> > doing 
> > this, but depending on the level of integration between FreeIPA
> > and 
> > bind, I'm not exactly sure how "easy" this can be done.
> 
> our IPA-Installation is completely separated from both our DHCP- and 
> DNS-Servers, that are maintained using Netdot [1]. All I needed to do
> was 
> to add a certain set of DNS-entries to our DNS zone files. Those
> entries 
> can be displayed with
> 
> ---
> ipa dns-update-system-records --dry-run
> ---
> 
> [1] https://github.com/cvicente/Netdot

Danke Daniel! 

this look very promising, I'll look into Netdot (never heard of it
before).

-- 
Udo Rader, GF/CEO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

signature.asc
Description: This is a digitally signed message part
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Update Zanata ipa.pot

[Alexander Bokovoy via FreeIPA-users]

On ke, 16 touko 2018, Levin Stanislav via FreeIPA-users wrote:

Dear Dev Team,

I've checked PR 1926 (Update 4.7 translations) - Russian part.


According to Zanata
(https://fedora.zanata.org/iteration/view/freeipa/master/languages/ru?dswid=7474#)
 
progress is ~99%.

But actually there are missing translations.


The reason - ipa.pot file is slightly outdated:

/"Project-Id-Version: freeipa 4.5.90.dev201709011157+git5dcb0e6fc\n"//
//"POT-Creation-Date: 2017-09-01 13:58+0200\n"./

/
/

According to release page https://www.freeipa.org/page/Release



Push source documents to Zanata server

!!! This should be done periodically *weeks* and *months* before
release to give time to translators


/
/

Please somebody push an updated ipa.pot to Zanata or tell me who can do
it ( i'll contact with ).

Rob was updating it yesterday but I'm not sure how that ended up, may be
he wasn't able to push to Zanata yet.

Don't worry, we are at 4.6.90.pre2 right now and current coverage for
Russian language is very good even with old pot file:

ru.po: 4168 translated messages, 96 untranslated messages.

Hopefully, we'll get Zanata updated this week and you'll have few more
weeks before 4.7 release to complete the translation.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Update Zanata ipa.pot

[Levin Stanislav via FreeIPA-users]

Dear Dev Team,

I've checked PR 1926 (Update 4.7 translations) - Russian part.


According to Zanata
(https://fedora.zanata.org/iteration/view/freeipa/master/languages/ru?dswid=7474#)
 
progress is ~99%.

But actually there are missing translations.


The reason - ipa.pot file is slightly outdated:

/"Project-Id-Version: freeipa 4.5.90.dev201709011157+git5dcb0e6fc\n"//
//"POT-Creation-Date: 2017-09-01 13:58+0200\n"./

/
/

According to release page https://www.freeipa.org/page/Release

>
> Push source documents to Zanata server
>
> !!! This should be done periodically *weeks* and *months* before
> release to give time to translators
>
/
/

Please somebody push an updated ipa.pot to Zanata or tell me who can do
it ( i'll contact with ).

Thank you in advance.




signature.asc
Description: OpenPGP digital signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] ipa-client-install - sssd.conf

[Ronald Wimmer via FreeIPA-users]

Hi,

is there a way to configure parameters in sssd.conf when calling 
ipa-client-install? It would be very helpful to be able to specify these 
parameters:


[sssd]
default_domain_suffix = SOMEDOMAIN

[nss]
homedir_substring = /home
default_shell = /bin/bash

default_shell is the most important one as AD users have /bin/sh as 
their default shell.


Regards,
Ronald
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: LDAP encryption errors

[Per Qvindesland via FreeIPA-users]

Hi Alexander 

Here is the object we are trying to change the password with:
dn: uid=tes...@jisc3.ac.uk 
,cn=users,cn=accounts,dc=jisc,dc=ac,dc=uk
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: krbPrincipalName
objectClass: ipaobject
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
objectClass: eduPerson
uid: tes...@jisc3.ac.uk 
givenName: NULL
sn: NULL
cn: wnQ6gpxNEbYDP4e0xSi42QvNLR4=
displayName: displayName not set
ou: Local
eduPersonAffiliation: affiliate
mail: tes...@jisc3.ac.uk 
userPassword: e1NIQX1rYjBwdk45WkpLVGpmMHdiMGJqYm5LSk10Vnk7
loginshell: /bin/sh
homedirectory: /home/tes...@jisc3.ac.uk 
gidnumber: 109214
uidnumber: 109214

Is there anything you can suggest?

Regards
Per




> On 11 May 2018, at 10:31, Alexander Bokovoy via FreeIPA-users 
>  wrote:
> 
> On pe, 11 touko 2018, Per Qvindesland via FreeIPA-users wrote:
>> Hi All
>> 
>> We’re getting the following entries in the error logs
>> 
>> [10/May/2018:15:37:18.628665013 +0100] - ERR - ipapwd_encrypt_encode_key - 
>> [file encoding.c, line 143]: no krbPrincipalName present in this entry
>> [10/May/2018:15:37:18.630473873 +0100] - ERR - ipapwd_gen_hashes - [file 
>> encoding.c, line 234]: key encryption/encoding failed
>> 
>> Is this related to the failed binds? is there any ways of turning on debug 
>> logging
> You have or are trying to add an object in LDAP that is not a Kerberos 
> principal, yet somehow
> object classes imply it should be a Kerberos principal. 
> You'd need to show the object or explain what are you doing.
> 
>> 
>> The connection string is  $ds = ldap_connect($hostport, $port); then we are 
>> setting some connection options: ldap_set_option($ds, 
>> LDAP_OPT_PROTOCOL_VERSION, 3);
>>   ldap_set_option($ds, LDAP_OPT_REFERRALS, 0); Then binding using admin 
>> credential:$result = ldap_bind($ds, $rdn, $pass)
>> 
>> We can connect to freeipa but we are suspecting that we might be using the 
>> wrong encryption  {SHA} in plain text then results in err 19 which results 
>> in operations error.
> No, this is not about connection to ldap but rather adding an LDAP
> object or attempting to modify a password on existing object.
> 
> 
> -- 
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org