From amessina at messinet.com  Sat Mar  1 10:18:11 2014
From: amessina at messinet.com (Anthony Messina)
Date: Sat, 01 Mar 2014 04:18:11 -0600
Subject: [Freeipa-users] WARNING: Do not upgrade FreeIPA deployments to
	Fedora 20 final (yet)
In-Reply-To: <81614488.131679.1387708947601.JavaMail.root@redhat.com>
References: <20131217091434.GW21264@redhat.com>
	<81614488.131679.1387708947601.JavaMail.root@redhat.com>
Message-ID: <3420623.9DfvCDMCbu@linux-ws1.messinet.com>

On Sunday, December 22, 2013 05:42:27 AM Alexander Bokovoy wrote:
> Hi,
> 
> an update on the issue of upgrading Fedora 19 to Fedora 20 for FreeIPA
> deployments.
> 
> An updated 389-ds-base package, 1.3.2.9-1.fc20 is in updates-testing
> repository.  Updated slapi-nis package, 0.52-1.fc20, is in updates-testing
> as well.
> 
> I've tested that using fedora-upgrade tool to upgrade from Fedora 19 to
> Fedora 20 does work if you have updates-testing repository enabled and that
> FreeIPA is continuing to work afterwards.
> 
> I've initiated move of 389-ds-base to updates stable repository. Once it
> reach out there,  I'll lift a warning on freeipa.org and publish a final
> update.
> 
> Happy holidays!
> 
> ----- Original Message -----
> 
> > From: "Alexander Bokovoy" <abokovoy at redhat.com>
> > To: freeipa-users at redhat.com
> > Sent: Tuesday, December 17, 2013 11:14:34 AM
> > Subject: [Freeipa-users] WARNING: Do not upgrade FreeIPA deployments
> > to       Fedora 20 final (yet)>
> > 
> >
> > Greetings!
> >
> > 
> >
> > As many of you are aware, Fedora Project releases Fedora 20 today,
> > Tuesday, December 17th. This post serves as a warning against upgrading
> > your FreeIPA deployments to Fedora 20 using release images. Please check
> > Fedora 20 Common Bugs page https://fedoraproject.org/wiki/Common_F20_bugs
> > for the complete list of issues.
> >
> > 
> >
> > FreeIPA relies heavily on 389-ds Directory Server. Fedora 20 introduces
> > new version series of 389-ds, 1.3.2.x. Along with multiple enhancements,
> > unfortunately, few bugs went into the version currently available in
> > Fedora 20 stable tree. These bugs are causing crashes under certain
> > conditions and we don't recommend updating your existing configurations
> > due to these consequences.
> >
> > 
> >
> > As an update to the Fedora 20 Common Bugs page, over last night fellow
> > developers from 389-ds and slapi-nis projects have fixed
> > https://bugzilla.redhat.com/show_bug.cgi?id=1043546 and
> > https://bugzilla.redhat.com/show_bug.cgi?id=1041732 but there will be
> > some delay before the builds featuring the fixes will  appear in Fedora
> > 20 updates repository. Remaining bugs are under investigation.
> >
> > 
> >
> > I'll post an update note once we'll get remaining issues fixed and
> > packages
> > pushed to Fedora 20 updates repository.
> >
> > 
> >
> > --
> > / Alexander Bokovoy

I've been waiting patiently for F20 to "settle" before upgrading my two VM 
installations of FreeIPA:

ipa1 (original master)
ipa2 (clone)

I'm considering doing a "yum upgrade" this weekend and was wondering if any 
users had found any "gotchas"?  One that I can think of is the addition of the 
following in F20's default /etc/krb5.conf:

[libdefaults]
  ...
  default_ccache_name = KEYRING:persistent:%{uid}
  ...

I've seen on some of my freshly installed F20 FreeIPA clients that this option 
is no longer present after ipa-client-install.  On those clients, I've 
manually added it post client install and things seem to work OK with the 
exception of SELinux errors reported here:

https://bugzilla.redhat.com/show_bug.cgi?id=1001703

Should I place this option in /etc/krb5.conf on the masters before/after the 
yum upgrade (or at all)?

Should I run "ipactl stop" prior to running the yum upgrade?

Of note, I'm considering the "yum upgrade" option rather than creating F20 
replicas of F19 masters due to:

https://fedorahosted.org/pki/ticket/816
https://fedorahosted.org/389/ticket/47721

Any guidance is appreciated.  Thanks, and have a good weekend.

-A

-- 
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140301/55b4d0ba/attachment.sig>

From bpk678 at gmail.com  Sat Mar  1 22:20:35 2014
From: bpk678 at gmail.com (Brendan Kearney)
Date: Sat, 01 Mar 2014 17:20:35 -0500
Subject: [Freeipa-users] best practices for subdomains
Message-ID: <1393712435.17594.6.camel@desktop.bpk2.com>

i am using bind-dyndb-ldap outside of freeipa, and want to create
_tcp.my-domain.com and _udp.my-domain.com subdomains.  i have tried, but
seem to come up short and nslookup fails for the records i try to create
in the subdomains.  some googling and searching in the wiki have not
provided me with much go on.  below is an attempt at _tcp.my-domain.com

dn: idnsName=_tcp.my-domain.com.,cn=dns,dc=my-domain,dc=com
dnsttl: 3600
idnsallowdynupdate: FALSE
idnsallowsyncptr: FALSE
idnsname: _tcp.my-domain.com.
idnssoaexpire: 604800
idnssoaminimum: 86400
idnssoamname: server.my-domain.com.
idnssoarefresh: 10800
idnssoaretry: 900
idnssoarname: root.server.my-domain.com.
idnssoaserial: 1
idnsupdatepolicy: grant MY-DOMAIN.COM krb5-self * A;
idnszoneactive: TRUE
nsrecord: server.my-domain.com.
objectclass: top
objectclass: idnsZone
objectclass: idnsRecord

what is the correct way to create a subdomain?

thank you,

brendan



From pspacek at redhat.com  Mon Mar  3 08:33:36 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Mon, 03 Mar 2014 09:33:36 +0100
Subject: [Freeipa-users] best practices for subdomains
In-Reply-To: <1393712435.17594.6.camel@desktop.bpk2.com>
References: <1393712435.17594.6.camel@desktop.bpk2.com>
Message-ID: <53143E60.1000502@redhat.com>

On 1.3.2014 23:20, Brendan Kearney wrote:
> i am using bind-dyndb-ldap outside of freeipa, and want to create
> _tcp.my-domain.com and _udp.my-domain.com subdomains.  i have tried, but
> seem to come up short and nslookup fails for the records i try to create
> in the subdomains.  some googling and searching in the wiki have not
> provided me with much go on.  below is an attempt at _tcp.my-domain.com
>
> dn: idnsName=_tcp.my-domain.com.,cn=dns,dc=my-domain,dc=com
> dnsttl: 3600
> idnsallowdynupdate: FALSE
> idnsallowsyncptr: FALSE
> idnsname: _tcp.my-domain.com.
> idnssoaexpire: 604800
> idnssoaminimum: 86400
> idnssoamname: server.my-domain.com.
> idnssoarefresh: 10800
> idnssoaretry: 900
> idnssoarname: root.server.my-domain.com.
> idnssoaserial: 1
> idnsupdatepolicy: grant MY-DOMAIN.COM krb5-self * A;
> idnszoneactive: TRUE
> nsrecord: server.my-domain.com.
> objectclass: top
> objectclass: idnsZone
> objectclass: idnsRecord
>
> what is the correct way to create a subdomain?

First of all, do you really want to create *subdomains* for _tcp and _udp or 
do you just need to create couple records like _ldap._tcp in a existing 
domain? It is very unusual to create separate subdomains for _tcp and _udp.

I'm attaching small snippet which shows how to add _ldap._tcp SRV record to 
existing domain ipa.example.

Please be so kind and send us information mentioned on
https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting#a3.Whatweneedtoknow

We would like to know how users use bind-dyndb-ldap, which LDAP server is used 
outside FreeIPA and so on.

Have a nice day!

-- 
Petr^2 Spacek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipa.example.ldif
Type: text/x-ldif
Size: 1013 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140303/b60388b2/attachment.bin>

From lagern at lafayette.edu  Mon Mar  3 13:50:54 2014
From: lagern at lafayette.edu (Lager, Nathan T.)
Date: Mon, 3 Mar 2014 08:50:54 -0500 (EST)
Subject: [Freeipa-users] Cert auto-renew probem.
In-Reply-To: <442720232.6543669.1393854406205.JavaMail.zimbra@lafayette.edu>
Message-ID: <1564912029.6544592.1393854654906.JavaMail.zimbra@lafayette.edu>

Today i found that i was unable to authenticate to FreeIPA. 

I logged into my IPA master, and found that the cert had expired.  Which has never been a problem in the past. 

I did some googling, and found a few others with similar problems. but none quite matched the issue i'm seeing. 

The issue is this: 
[root at caroline0 PROD ~]# ipa-getcert list
Number of certificates and requests being tracked: 8.
Request ID '20120203213023':
	status: CA_UNREACHABLE
	ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction.  Peer certificate cannot be authenticated with known CA certificates).
	stuck: yes
	key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-SYSTEMS-LAFAYETTE-EDU',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-SYSTEMS-LAFAYETTE-EDU//pwdfile.txt'
	certificate: type=NSSDB,location='/etc/dirsrv/slapd-SYSTEMS-LAFAYETTE-EDU',nickname='Server-Cert',token='NSS Certificate DB'
	CA: IPA
	issuer: CN=Certificate Authority,O=SYSTEMS.LAFAYETTE.EDU
	subject: CN=caroline0.lafayette.edu,O=SYSTEMS.LAFAYETTE.EDU
	expires: 2014-02-03 21:30:22 UTC
	eku: id-kp-serverAuth,id-kp-clientAuth
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes
Request ID '20120203213048':
	status: CA_UNREACHABLE
	ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction.  Peer certificate cannot be authenticated with known CA certificates).
	stuck: yes
	key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'
	certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB'
	CA: IPA
	issuer: CN=Certificate Authority,O=SYSTEMS.LAFAYETTE.EDU
	subject: CN=caroline0.lafayette.edu,O=SYSTEMS.LAFAYETTE.EDU
	expires: 2014-02-03 21:30:47 UTC
	eku: id-kp-serverAuth,id-kp-clientAuth
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes
Request ID '20120203213112':
	status: CA_UNREACHABLE
	ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction.  Peer certificate cannot be authenticated with known CA certificates).
	stuck: yes
	key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
	certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'
	CA: IPA
	issuer: CN=Certificate Authority,O=SYSTEMS.LAFAYETTE.EDU
	subject: CN=caroline0.lafayette.edu,O=SYSTEMS.LAFAYETTE.EDU
	expires: 2014-02-03 21:31:11 UTC
	eku: id-kp-serverAuth,id-kp-clientAuth
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes

Now, if i understand FreeIPA, the CA is FreeIPA itself, isnt it?  If so, how could it be unreachable?  

What else might I be able to try to get past this? 

Thanks! 





From sdainard at miovision.com  Mon Mar  3 19:01:52 2014
From: sdainard at miovision.com (Steve Dainard)
Date: Mon, 3 Mar 2014 14:01:52 -0500
Subject: [Freeipa-users] Sudo denied on first attempt,
	allowed on second attempt
In-Reply-To: <20140224155559.GA13087@hendrix.redhat.com>
References: <CAHnsdUusKMwHCDVCX74Q7hu8-cozCLEpd_52M=R8b5PKZLmGbw@mail.gmail.com>
	<1295498130.15161889.1393256779057.JavaMail.zimbra@redhat.com>
	<20140224155559.GA13087@hendrix.redhat.com>
Message-ID: <CAHnsdUvqGtfSobB_wYfDtejB6mW-EEvD0TVvus_tbxVtf9M0oA@mail.gmail.com>

Hi Jakub, id info from earlier response:

>         Very interesting, my IPA group membership in ad_admins isn't
>         shown by
>         that command on first run (new login)
>
>         sdainard-admin at miovision.corp@__ubu1310:~$ id sdainard-admin
>         uid=799002462(sdainard-admin at __miovision.corp)
>         gid=799002462(sdainard-admin at __miovision.corp)
>         groups=799002462(sdainard-__admin at miovision.corp),__
799001380(accounting-share-__access at miovision.corp),__
799001417(protected-share-__access at miovision.corp),__799000519(enterprise
>         admins at miovision.corp),__799001416(hr-share-access at __
miovision.corp),799000512(__domain
>         admins at miovision.corp),__799000513(domain
>         users at miovision.corp),__799002464(it -
>         admins at miovision.corp),__799002469(kloperators at __
miovision.corp),799002468(__kladmins at miovision.corp)
>
>         sdainard-admin at miovision.corp@__ubu1310:~$ sudo su
>         [sudo] password for sdainard-admin at miovision.corp:
>         sdainard-admin at miovision.corp is not allowed to run sudo on
ubu1310.
>            This incident will be reported.
>
>         But after attempting the sudo command my groups do contain the IPA
>         groups admins,ad_admins:
>
>         sdainard-admin at miovision.corp@__ubu1310:~$ id sdainard-admin
>         uid=799002462(sdainard-admin at __miovision.corp)
>         gid=799002462(sdainard-admin at __miovision.corp)
>         groups=799002462(sdainard-__admin at miovision.corp),__
799001380(accounting-share-__access at miovision.corp),__
799001417(protected-share-__access at miovision.corp),__799000519(enterprise
>         admins at miovision.corp),__799001416(hr-share-access at __
miovision.corp),799000512(__domain
>         admins at miovision.corp),__799000513(domain
>         users at miovision.corp),__799002464(it -
>         admins at miovision.corp),__799002469(kloperators at __
miovision.corp),799002468(__kladmins at miovision.corp),*__
1768200000(admins),1768200004(__ad_admins)*
>

*Steve Dainard *
IT Infrastructure Manager
Miovision <http://miovision.com/> | *Rethink Traffic*

*Blog <http://miovision.com/blog>  |  **LinkedIn
<https://www.linkedin.com/company/miovision-technologies>  |  Twitter
<https://twitter.com/miovision>  |  Facebook
<https://www.facebook.com/miovision>*
------------------------------
 Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON,
Canada | N2C 1L3
This e-mail may contain information that is privileged or confidential. If
you are not the intended recipient, please delete the e-mail and any
attachments and notify us immediately.


On Mon, Feb 24, 2014 at 10:55 AM, Jakub Hrozek <jhrozek at redhat.com> wrote:

> On Mon, Feb 24, 2014 at 10:46:19AM -0500, Pavel Brezina wrote:
> > Hi,
> > I wasn't able to reproduce with membership setup exactly like this. I
> > have already seen similar problem once, unfortunately the user stopped
> > responding before we could reach the root cause. I think it is correct
> > from the sudo point of view, what is problematic here is missing group
> > membership.
> >
> > It seems that membership of trusted user is not resolved correctly.
> > Sumit, Jakub, do you have any ideas?
>
> Did you verify if "id" prints the expected groups for the user in question
> after he logs in? I think we need to first verify if the memberships are
> stored correctly to the cache..
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140303/5bfeabab/attachment.htm>

From amessina at messinet.com  Mon Mar  3 20:54:56 2014
From: amessina at messinet.com (Anthony Messina)
Date: Mon, 03 Mar 2014 14:54:56 -0600
Subject: [Freeipa-users] F19 -> F20 yum upgrade success report (WAS: Re:
	WARNING: Do not upgrade FreeIPA deployments to Fedora 20
	final (yet))
In-Reply-To: <3420623.9DfvCDMCbu@linux-ws1.messinet.com>
References: <20131217091434.GW21264@redhat.com>
	<81614488.131679.1387708947601.JavaMail.root@redhat.com>
	<3420623.9DfvCDMCbu@linux-ws1.messinet.com>
Message-ID: <4052016.7n8uHLVFPi@linux-ws1.messinet.com>

On Saturday, March 01, 2014 04:18:11 AM Anthony Messina wrote:
> I've been waiting patiently for F20 to "settle" before upgrading my two VM 
> installations of FreeIPA:
> 
> ipa1 (original master)
> ipa2 (clone)
> 
> I'm considering doing a "yum upgrade" this weekend and was wondering if any 
> users had found any "gotchas"?  One that I can think of is the addition of
> the following in F20's default /etc/krb5.conf:
> 
> [libdefaults]
>   ...
>   default_ccache_name = KEYRING:persistent:%{uid}
>   ...
> 
> I've seen on some of my freshly installed F20 FreeIPA clients that this
> option  is no longer present after ipa-client-install.  On those clients,
> I've manually added it post client install and things seem to work OK with
> the exception of SELinux errors reported here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1001703
> 
> Should I place this option in /etc/krb5.conf on the masters before/after
> the  yum upgrade (or at all)?
> 
> Should I run "ipactl stop" prior to running the yum upgrade?
> 
> Of note, I'm considering the "yum upgrade" option rather than creating F20 
> replicas of F19 masters due to:
> 
> https://fedorahosted.org/pki/ticket/816
> https://fedorahosted.org/389/ticket/47721
> 
> Any guidance is appreciated.  Thanks, and have a good weekend.
> 
> -A

I can report to the list that I've upgraded my ipa1 and ipa2 machines from F19 
to F20 via "yum upgrade" in SELinux permissive mode and things went 
swimmingly.

As far as my concerns above, I added the following to /etc/krb5.conf after the 
upgrade, but before the reboot:

default_ccache_name = KEYRING:persistent:%{uid}

And I did not issue "ipactl stop" prior to the upgrade.

The only post-upgrade issue I am seeing is invalid characters passed to dirsrv 
queries when using FreeIPA web interface:

https://fedorahosted.org/freeipa/ticket/4214

Thanks again to the FreeIPA team!

-A

-- 
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140303/dc569cf9/attachment.sig>

From bpk678 at gmail.com  Mon Mar  3 21:57:35 2014
From: bpk678 at gmail.com (Brendan Kearney)
Date: Mon, 03 Mar 2014 16:57:35 -0500
Subject: [Freeipa-users] best practices for subdomains
In-Reply-To: <53143E60.1000502@redhat.com>
References: <1393712435.17594.6.camel@desktop.bpk2.com>
	<53143E60.1000502@redhat.com>
Message-ID: <1393883855.11276.20.camel@desktop.bpk2.com>

On Mon, 2014-03-03 at 09:33 +0100, Petr Spacek wrote:
> On 1.3.2014 23:20, Brendan Kearney wrote:
> > i am using bind-dyndb-ldap outside of freeipa, and want to create
> > _tcp.my-domain.com and _udp.my-domain.com subdomains.  i have tried, but
> > seem to come up short and nslookup fails for the records i try to create
> > in the subdomains.  some googling and searching in the wiki have not
> > provided me with much go on.  below is an attempt at _tcp.my-domain.com
> >
> > dn: idnsName=_tcp.my-domain.com.,cn=dns,dc=my-domain,dc=com
> > dnsttl: 3600
> > idnsallowdynupdate: FALSE
> > idnsallowsyncptr: FALSE
> > idnsname: _tcp.my-domain.com.
> > idnssoaexpire: 604800
> > idnssoaminimum: 86400
> > idnssoamname: server.my-domain.com.
> > idnssoarefresh: 10800
> > idnssoaretry: 900
> > idnssoarname: root.server.my-domain.com.
> > idnssoaserial: 1
> > idnsupdatepolicy: grant MY-DOMAIN.COM krb5-self * A;
> > idnszoneactive: TRUE
> > nsrecord: server.my-domain.com.
> > objectclass: top
> > objectclass: idnsZone
> > objectclass: idnsRecord
> >
> > what is the correct way to create a subdomain?
> 
> First of all, do you really want to create *subdomains* for _tcp and _udp or 
> do you just need to create couple records like _ldap._tcp in a existing 
> domain? It is very unusual to create separate subdomains for _tcp and _udp.
> 
> I'm attaching small snippet which shows how to add _ldap._tcp SRV record to 
> existing domain ipa.example.
> 
> Please be so kind and send us information mentioned on
> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting#a3.Whatweneedtoknow
> 
> We would like to know how users use bind-dyndb-ldap, which LDAP server is used 
> outside FreeIPA and so on.
> 
> Have a nice day!
> 
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

What distribution you use? Fedora
Which distribution version you use? Fedora 20, with latest updates
Which architecture you use? x86_64 on a qemu VM

What plugin version you use? bind-dyndb-ldap-3.5-1.fc20.x86_64
Do you use bind-dyndb-ldap as part of ?FreeIPA installation? no, using
openldap-servers-2.4.39-2.fc20.x86_64
Which version of ?BIND you use? bind-9.9.4-11.P2.fc20.x86_64

Please provide dynamic-db section from configuration
file /etc/named.conf
dynamic-db "my-domain.com" {
       	library "ldap.so";
        arg "uri ldap://127.0.0.1/";
       	arg "base cn=dns,dc=my-domain,dc=com";
        arg "auth_method simple";
	arg "bind_dn cn=Manager,dc=my-domain,dc=com";
	arg "password *****";
	arg "psearch no";
	// arg "serial_autoincrement yes";
	arg "sync_ptr yes";
	arg "dyn_update yes";
	arg "connections 2";
        arg "cache_ttl 300";
	arg "verbose_checks yes";
};

Do you have some other text based or ?DLZ zones configured? no
Do you have some global forwarders configured in BIND configuration
file? no

Do you have some settings in global configuration object in LDAP?
dn: cn=dns,dc=my-domain,dc=com
cn: dns
idnspersistentsearch: FALSE
idnszonerefresh: 30
objectclass: top
objectclass: nsContainer
objectclass: idnsConfigObject

without a doubt i want to use subdomains (or subzones, if that the
correct term) for _tcp and _udp.  kerberos, kerberos-adm,
kerberos-master, kpasswd, ldap, nfs4, wpad and ntp are the SRV records i
want to manage, and having them in the regular forward zone  is not as
clean, neat and organized as i want to be.  also, i may want to have
forward subdomains (sub.my-domain.com, for example, with
testhost.sub.my-domain.com as an A record).

the example included in the package did have a similar example on how to
put a SRV into the zone, but again, i want to manage those records with
a subdomain (or subzone, if that is the correct term).



From sdainard at miovision.com  Mon Mar  3 22:35:48 2014
From: sdainard at miovision.com (Steve Dainard)
Date: Mon, 3 Mar 2014 17:35:48 -0500
Subject: [Freeipa-users] Sudo denied on first attempt,
	allowed on second attempt
In-Reply-To: <CAHnsdUvqGtfSobB_wYfDtejB6mW-EEvD0TVvus_tbxVtf9M0oA@mail.gmail.com>
References: <CAHnsdUusKMwHCDVCX74Q7hu8-cozCLEpd_52M=R8b5PKZLmGbw@mail.gmail.com>
	<1295498130.15161889.1393256779057.JavaMail.zimbra@redhat.com>
	<20140224155559.GA13087@hendrix.redhat.com>
	<CAHnsdUvqGtfSobB_wYfDtejB6mW-EEvD0TVvus_tbxVtf9M0oA@mail.gmail.com>
Message-ID: <CAHnsdUtrCn2z6q98La0QKFLCLBewb_9PGPTTAgXhswpPAWeMfA@mail.gmail.com>

Sumit,

Unfortunately 1.11.1 is the only version available for Ubuntu 13.10.

I've also had the same problem with an updated version of Fedora 20, so I
don't think its specific to this package version.

*Steve Dainard *
IT Infrastructure Manager
Miovision <http://miovision.com/> | *Rethink Traffic*

*Blog <http://miovision.com/blog>  |  **LinkedIn
<https://www.linkedin.com/company/miovision-technologies>  |  Twitter
<https://twitter.com/miovision>  |  Facebook
<https://www.facebook.com/miovision>*
------------------------------
 Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON,
Canada | N2C 1L3
This e-mail may contain information that is privileged or confidential. If
you are not the intended recipient, please delete the e-mail and any
attachments and notify us immediately.


On Mon, Mar 3, 2014 at 2:01 PM, Steve Dainard <sdainard at miovision.com>wrote:

> Hi Jakub, id info from earlier response:
>
> >         Very interesting, my IPA group membership in ad_admins isn't
> >         shown by
> >         that command on first run (new login)
> >
> >         sdainard-admin at miovision.corp@__ubu1310:~$ id sdainard-admin
> >         uid=799002462(sdainard-admin at __miovision.corp)
> >         gid=799002462(sdainard-admin at __miovision.corp)
> >         groups=799002462(sdainard-__admin at miovision.corp),__
> 799001380(accounting-share-__access at miovision.corp),__
> 799001417(protected-share-__access at miovision.corp),__799000519(enterprise
> >         admins at miovision.corp),__799001416(hr-share-access at __
> miovision.corp),799000512(__domain
> >         admins at miovision.corp),__799000513(domain
> >         users at miovision.corp),__799002464(it -
> >         admins at miovision.corp),__799002469(kloperators at __
> miovision.corp),799002468(__kladmins at miovision.corp)
> >
> >         sdainard-admin at miovision.corp@__ubu1310:~$ sudo su
> >         [sudo] password for sdainard-admin at miovision.corp:
> >         sdainard-admin at miovision.corp is not allowed to run sudo on
> ubu1310.
> >            This incident will be reported.
> >
> >         But after attempting the sudo command my groups do contain the
> IPA
> >         groups admins,ad_admins:
> >
> >         sdainard-admin at miovision.corp@__ubu1310:~$ id sdainard-admin
> >         uid=799002462(sdainard-admin at __miovision.corp)
> >         gid=799002462(sdainard-admin at __miovision.corp)
> >         groups=799002462(sdainard-__admin at miovision.corp),__
> 799001380(accounting-share-__access at miovision.corp),__
> 799001417(protected-share-__access at miovision.corp),__799000519(enterprise
> >         admins at miovision.corp),__799001416(hr-share-access at __
> miovision.corp),799000512(__domain
> >         admins at miovision.corp),__799000513(domain
> >         users at miovision.corp),__799002464(it -
> >         admins at miovision.corp),__799002469(kloperators at __
> miovision.corp),799002468(__kladmins at miovision.corp),*__
> 1768200000(admins),1768200004(__ad_admins)*
> >
>
> *Steve Dainard *
> IT Infrastructure Manager
> Miovision <http://miovision.com/> | *Rethink Traffic*
>
> *Blog <http://miovision.com/blog>  |  **LinkedIn
> <https://www.linkedin.com/company/miovision-technologies>  |  Twitter
> <https://twitter.com/miovision>  |  Facebook
> <https://www.facebook.com/miovision>*
> ------------------------------
>  Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener,
> ON, Canada | N2C 1L3
> This e-mail may contain information that is privileged or confidential. If
> you are not the intended recipient, please delete the e-mail and any
> attachments and notify us immediately.
>
>
> On Mon, Feb 24, 2014 at 10:55 AM, Jakub Hrozek <jhrozek at redhat.com> wrote:
>
>> On Mon, Feb 24, 2014 at 10:46:19AM -0500, Pavel Brezina wrote:
>> > Hi,
>> > I wasn't able to reproduce with membership setup exactly like this. I
>> > have already seen similar problem once, unfortunately the user stopped
>> > responding before we could reach the root cause. I think it is correct
>> > from the sudo point of view, what is problematic here is missing group
>> > membership.
>> >
>> > It seems that membership of trusted user is not resolved correctly.
>> > Sumit, Jakub, do you have any ideas?
>>
>> Did you verify if "id" prints the expected groups for the user in question
>> after he logs in? I think we need to first verify if the memberships are
>> stored correctly to the cache..
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140303/aa88cc07/attachment.htm>

From dpal at redhat.com  Mon Mar  3 23:18:27 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 03 Mar 2014 18:18:27 -0500
Subject: [Freeipa-users] Cert auto-renew probem.
In-Reply-To: <1564912029.6544592.1393854654906.JavaMail.zimbra@lafayette.edu>
References: <1564912029.6544592.1393854654906.JavaMail.zimbra@lafayette.edu>
Message-ID: <53150DC3.10903@redhat.com>

On 03/03/2014 08:50 AM, Lager, Nathan T. wrote:
> Today i found that i was unable to authenticate to FreeIPA.
>
> I logged into my IPA master, and found that the cert had expired.  Which has never been a problem in the past.
>
> I did some googling, and found a few others with similar problems. but none quite matched the issue i'm seeing.
>
> The issue is this:
> [root at caroline0 PROD ~]# ipa-getcert list
> Number of certificates and requests being tracked: 8.
> Request ID '20120203213023':
> 	status: CA_UNREACHABLE
> 	ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction.  Peer certificate cannot be authenticated with known CA certificates).
> 	stuck: yes
> 	key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-SYSTEMS-LAFAYETTE-EDU',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-SYSTEMS-LAFAYETTE-EDU//pwdfile.txt'
> 	certificate: type=NSSDB,location='/etc/dirsrv/slapd-SYSTEMS-LAFAYETTE-EDU',nickname='Server-Cert',token='NSS Certificate DB'
> 	CA: IPA
> 	issuer: CN=Certificate Authority,O=SYSTEMS.LAFAYETTE.EDU
> 	subject: CN=caroline0.lafayette.edu,O=SYSTEMS.LAFAYETTE.EDU
> 	expires: 2014-02-03 21:30:22 UTC
> 	eku: id-kp-serverAuth,id-kp-clientAuth
> 	pre-save command:
> 	post-save command:
> 	track: yes
> 	auto-renew: yes
> Request ID '20120203213048':
> 	status: CA_UNREACHABLE
> 	ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction.  Peer certificate cannot be authenticated with known CA certificates).
> 	stuck: yes
> 	key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'
> 	certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB'
> 	CA: IPA
> 	issuer: CN=Certificate Authority,O=SYSTEMS.LAFAYETTE.EDU
> 	subject: CN=caroline0.lafayette.edu,O=SYSTEMS.LAFAYETTE.EDU
> 	expires: 2014-02-03 21:30:47 UTC
> 	eku: id-kp-serverAuth,id-kp-clientAuth
> 	pre-save command:
> 	post-save command:
> 	track: yes
> 	auto-renew: yes
> Request ID '20120203213112':
> 	status: CA_UNREACHABLE
> 	ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction.  Peer certificate cannot be authenticated with known CA certificates).
> 	stuck: yes
> 	key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> 	certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'
> 	CA: IPA
> 	issuer: CN=Certificate Authority,O=SYSTEMS.LAFAYETTE.EDU
> 	subject: CN=caroline0.lafayette.edu,O=SYSTEMS.LAFAYETTE.EDU
> 	expires: 2014-02-03 21:31:11 UTC
> 	eku: id-kp-serverAuth,id-kp-clientAuth
> 	pre-save command:
> 	post-save command:
> 	track: yes
> 	auto-renew: yes
>
> Now, if i understand FreeIPA, the CA is FreeIPA itself, isnt it?  If so, how could it be unreachable?
>
> What else might I be able to try to get past this?
>
> Thanks!
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

Seems like your certificates have expired.
The best would be to set the time back and restart the services 
everything should come up again.
There have been some bugs with the cert rotation and restart.
I suggest you check the mail threads regarding making sure that you have 
the fixed version and that certificates are rotated.
Sorry for the situation.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From treydock at gmail.com  Tue Mar  4 00:42:35 2014
From: treydock at gmail.com (Trey Dockendorf)
Date: Mon, 3 Mar 2014 18:42:35 -0600
Subject: [Freeipa-users] Using external KDC
Message-ID: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>

Is it possible with FreeIPA to use an external KDC or pass some or all
authentication to an external KDC?  The KDC at our University may give
me a one way trust if I describe my implementation plan for FreeIPA.
Currently I use 389DS with PAM pass through using untrusted pam_krb5.
I'd like to fully utilize FreeIPA without managing passwords since all
my users already have University accounts.  I just want to manage
authorization for my systems, not authentication.

Thanks
- Trey



From simo at redhat.com  Tue Mar  4 00:47:34 2014
From: simo at redhat.com (Simo Sorce)
Date: Mon, 03 Mar 2014 19:47:34 -0500
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
Message-ID: <1393894054.22047.59.camel@willson.li.ssimo.org>

On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
> Is it possible with FreeIPA to use an external KDC or pass some or all
> authentication to an external KDC?  The KDC at our University may give
> me a one way trust if I describe my implementation plan for FreeIPA.
> Currently I use 389DS with PAM pass through using untrusted pam_krb5.
> I'd like to fully utilize FreeIPA without managing passwords since all
> my users already have University accounts.  I just want to manage
> authorization for my systems, not authentication.

You could set up a kerberos trust manually but at the moment we do not
support it in the code or the utilities.

SSSD in particular will have no place to find identity information if
all you have is a kerberos trust, you'd need also an external identity
store to point to, but there is no builtin code in SSSD to link the 2
domain at this point.

We are planning on working on IPA-to-IPA trust, and possibly
IPA-to-*other* so any requirements you can throw at us will be made part
of the consideration and planning to add this kind of functionality in
the future.

NM B HTH,
Simo.

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



From dpal at redhat.com  Tue Mar  4 01:29:32 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 03 Mar 2014 20:29:32 -0500
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <1393894054.22047.59.camel@willson.li.ssimo.org>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
Message-ID: <53152C7C.9070304@redhat.com>

On 03/03/2014 07:47 PM, Simo Sorce wrote:
> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
>> Is it possible with FreeIPA to use an external KDC or pass some or all
>> authentication to an external KDC?  The KDC at our University may give
>> me a one way trust if I describe my implementation plan for FreeIPA.
>> Currently I use 389DS with PAM pass through using untrusted pam_krb5.
>> I'd like to fully utilize FreeIPA without managing passwords since all
>> my users already have University accounts.  I just want to manage
>> authorization for my systems, not authentication.
> You could set up a kerberos trust manually but at the moment we do not
> support it in the code or the utilities.
>
> SSSD in particular will have no place to find identity information if
> all you have is a kerberos trust, you'd need also an external identity
> store to point to, but there is no builtin code in SSSD to link the 2
> domain at this point.
>
> We are planning on working on IPA-to-IPA trust, and possibly
> IPA-to-*other* so any requirements you can throw at us will be made part
> of the consideration and planning to add this kind of functionality in
> the future.
>
> NM B HTH,
> Simo.
>
Can you describe your workflows because I have some idea in mind?
Would you be OK if your accounts would be in IPA but the authentication 
would be proxied out?

The idea is that you can use OTP RADIUS capability to proxy passwords to 
your main KDC.

client ---OTP---> IPA ---> OTP Proxy ---> RADIUS ---> Your KDC

Disclaimer: that would defeat the purpose of Kerberos and the password 
will be sent over the wire but it seems that you are already in this setup.

Would you be interested to give it a try?
Would require latest SSSD and kerberos library on the client though but 
would work with LDAP binds too.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From pspacek at redhat.com  Tue Mar  4 09:30:16 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Tue, 04 Mar 2014 10:30:16 +0100
Subject: [Freeipa-users] best practices for subdomains
In-Reply-To: <1393883855.11276.20.camel@desktop.bpk2.com>
References: <1393712435.17594.6.camel@desktop.bpk2.com>	
	<53143E60.1000502@redhat.com>
	<1393883855.11276.20.camel@desktop.bpk2.com>
Message-ID: <53159D28.1050309@redhat.com>

On 3.3.2014 22:57, Brendan Kearney wrote:
> On Mon, 2014-03-03 at 09:33 +0100, Petr Spacek wrote:
>> On 1.3.2014 23:20, Brendan Kearney wrote:
>>> i am using bind-dyndb-ldap outside of freeipa, and want to create
>>> _tcp.my-domain.com and _udp.my-domain.com subdomains.  i have tried, but
>>> seem to come up short and nslookup fails for the records i try to create
>>> in the subdomains.  some googling and searching in the wiki have not
>>> provided me with much go on.  below is an attempt at _tcp.my-domain.com
>>>
>>> dn: idnsName=_tcp.my-domain.com.,cn=dns,dc=my-domain,dc=com
>>> dnsttl: 3600
>>> idnsallowdynupdate: FALSE
>>> idnsallowsyncptr: FALSE
>>> idnsname: _tcp.my-domain.com.
>>> idnssoaexpire: 604800
>>> idnssoaminimum: 86400
>>> idnssoamname: server.my-domain.com.
>>> idnssoarefresh: 10800
>>> idnssoaretry: 900
>>> idnssoarname: root.server.my-domain.com.
>>> idnssoaserial: 1
>>> idnsupdatepolicy: grant MY-DOMAIN.COM krb5-self * A;
>>> idnszoneactive: TRUE
>>> nsrecord: server.my-domain.com.
>>> objectclass: top
>>> objectclass: idnsZone
>>> objectclass: idnsRecord
>>>
>>> what is the correct way to create a subdomain?
>>
>> First of all, do you really want to create *subdomains* for _tcp and _udp or
>> do you just need to create couple records like _ldap._tcp in a existing
>> domain? It is very unusual to create separate subdomains for _tcp and _udp.
>>
>> I'm attaching small snippet which shows how to add _ldap._tcp SRV record to
>> existing domain ipa.example.
>>
>> Please be so kind and send us information mentioned on
>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting#a3.Whatweneedtoknow
>>
>> We would like to know how users use bind-dyndb-ldap, which LDAP server is used
>> outside FreeIPA and so on.
>>
>> Have a nice day!
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
> What distribution you use? Fedora
> Which distribution version you use? Fedora 20, with latest updates
> Which architecture you use? x86_64 on a qemu VM
>
> What plugin version you use? bind-dyndb-ldap-3.5-1.fc20.x86_64
> Do you use bind-dyndb-ldap as part of ?FreeIPA installation? no, using
> openldap-servers-2.4.39-2.fc20.x86_64
> Which version of ?BIND you use? bind-9.9.4-11.P2.fc20.x86_64
>
> Please provide dynamic-db section from configuration
> file /etc/named.conf
> dynamic-db "my-domain.com" {
>         	library "ldap.so";
>          arg "uri ldap://127.0.0.1/";
>         	arg "base cn=dns,dc=my-domain,dc=com";
>          arg "auth_method simple";
> 	arg "bind_dn cn=Manager,dc=my-domain,dc=com";
> 	arg "password *****";
> 	arg "psearch no";
> 	// arg "serial_autoincrement yes";
> 	arg "sync_ptr yes";
> 	arg "dyn_update yes";
> 	arg "connections 2";
>          arg "cache_ttl 300";
> 	arg "verbose_checks yes";
> };
>
> Do you have some other text based or ?DLZ zones configured? no
> Do you have some global forwarders configured in BIND configuration
> file? no
>
> Do you have some settings in global configuration object in LDAP?
> dn: cn=dns,dc=my-domain,dc=com
> cn: dns
> idnspersistentsearch: FALSE
> idnszonerefresh: 30
> objectclass: top
> objectclass: nsContainer
> objectclass: idnsConfigObject
>
> without a doubt i want to use subdomains (or subzones, if that the
> correct term) for _tcp and _udp.  kerberos, kerberos-adm,
> kerberos-master, kpasswd, ldap, nfs4, wpad and ntp are the SRV records i
> want to manage, and having them in the regular forward zone  is not as
> clean, neat and organized as i want to be.  also, i may want to have
> forward subdomains (sub.my-domain.com, for example, with
> testhost.sub.my-domain.com as an A record).

Please see attached LDIFs.

_udp.example.com.ldif adds new zone _udp.example.com and one SRV records into it.

example.com.ldif adds *required* delegation from parent zone example.com to 
_udp.example.com.

Please do not forget that NS records have to be valid (i.e. have to point to 
an existing A/AAAA records) so edit them as appropriate.

Delegation via NS records from parent zone is *required* by DNS standards, 
never omit them. (It could work for a while without them but things will fail 
as soon as you try to debug something, direct client to use more than 1 DNS 
server etc.)

Note that you have to create a separate zone *and required delegation* for 
each separate sub-tree, i.e. even for _kerberos name in example.com etc.

I have warned you :-) Have a nice day!

-- 
Petr^2 Spacek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.com.ldif
Type: text/x-ldif
Size: 746 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140304/24f19196/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _udp.example.com.ldif
Type: text/x-ldif
Size: 781 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140304/24f19196/attachment-0001.bin>

From jhrozek at redhat.com  Tue Mar  4 09:53:20 2014
From: jhrozek at redhat.com (Jakub Hrozek)
Date: Tue, 4 Mar 2014 10:53:20 +0100
Subject: [Freeipa-users] Sudo denied on first attempt,
 allowed on second attempt
In-Reply-To: <CAHnsdUvqGtfSobB_wYfDtejB6mW-EEvD0TVvus_tbxVtf9M0oA@mail.gmail.com>
References: <CAHnsdUusKMwHCDVCX74Q7hu8-cozCLEpd_52M=R8b5PKZLmGbw@mail.gmail.com>
	<1295498130.15161889.1393256779057.JavaMail.zimbra@redhat.com>
	<20140224155559.GA13087@hendrix.redhat.com>
	<CAHnsdUvqGtfSobB_wYfDtejB6mW-EEvD0TVvus_tbxVtf9M0oA@mail.gmail.com>
Message-ID: <20140304095320.GD4261@hendrix>

On Mon, Mar 03, 2014 at 02:01:52PM -0500, Steve Dainard wrote:
> Hi Jakub, id info from earlier response:
> 
> >         Very interesting, my IPA group membership in ad_admins isn't
> >         shown by
> >         that command on first run (new login)
> >
> >         sdainard-admin at miovision.corp@__ubu1310:~$ id sdainard-admin
> >         uid=799002462(sdainard-admin at __miovision.corp)
> >         gid=799002462(sdainard-admin at __miovision.corp)
> >         groups=799002462(sdainard-__admin at miovision.corp),__
> 799001380(accounting-share-__access at miovision.corp),__
> 799001417(protected-share-__access at miovision.corp),__799000519(enterprise
> >         admins at miovision.corp),__799001416(hr-share-access at __
> miovision.corp),799000512(__domain
> >         admins at miovision.corp),__799000513(domain
> >         users at miovision.corp),__799002464(it -
> >         admins at miovision.corp),__799002469(kloperators at __
> miovision.corp),799002468(__kladmins at miovision.corp)
> >
> >         sdainard-admin at miovision.corp@__ubu1310:~$ sudo su
> >         [sudo] password for sdainard-admin at miovision.corp:
> >         sdainard-admin at miovision.corp is not allowed to run sudo on
> ubu1310.
> >            This incident will be reported.
> >
> >         But after attempting the sudo command my groups do contain the IPA
> >         groups admins,ad_admins:
> >
> >         sdainard-admin at miovision.corp@__ubu1310:~$ id sdainard-admin
> >         uid=799002462(sdainard-admin at __miovision.corp)
> >         gid=799002462(sdainard-admin at __miovision.corp)
> >         groups=799002462(sdainard-__admin at miovision.corp),__
> 799001380(accounting-share-__access at miovision.corp),__
> 799001417(protected-share-__access at miovision.corp),__799000519(enterprise
> >         admins at miovision.corp),__799001416(hr-share-access at __
> miovision.corp),799000512(__domain
> >         admins at miovision.corp),__799000513(domain
> >         users at miovision.corp),__799002464(it -
> >         admins at miovision.corp),__799002469(kloperators at __
> miovision.corp),799002468(__kladmins at miovision.corp),*__
> 1768200000(admins),1768200004(__ad_admins)*
> >

Interesting, I would have thought that both sudo and id after login
yield the same information. Can you send the SSSD logs? Feel free to
send them privately.



From pspacek at redhat.com  Tue Mar  4 13:11:25 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Tue, 04 Mar 2014 14:11:25 +0100
Subject: [Freeipa-users] bind-dyndb-ldap 4.1 upgrade
In-Reply-To: <53159D28.1050309@redhat.com>
References: <1393712435.17594.6.camel@desktop.bpk2.com>		<53143E60.1000502@redhat.com>	<1393883855.11276.20.camel@desktop.bpk2.com>
	<53159D28.1050309@redhat.com>
Message-ID: <5315D0FD.7030606@redhat.com>

Hello,

On 3.3.2014 22:57, Brendan Kearney wrote:
 > Which distribution version you use? Fedora 20, with latest updates
 > What plugin version you use? bind-dyndb-ldap-3.5-1.fc20.x86_64

Please make sure that you read and follow
https://www.redhat.com/archives/freeipa-interest/2014-February/msg00001.html
before you upgrade bind-dyndb-ldap to version 4.x.

The bind-dyndb-ldap 4.1 is being pushed to Fedora-updates repo right now.

I will comment on your configuration in-line:
> Do you use bind-dyndb-ldap as part of ?FreeIPA installation? no, using
> openldap-servers-2.4.39-2.fc20.x86_64
Please make sure that syncrepl provider is configured on your LDAP server. 
Syncrepl support on server side is *required* from version 4.0.

> Please provide dynamic-db section from configuration
> file /etc/named.conf
> dynamic-db "my-domain.com" {
>              library "ldap.so";
>           arg "uri ldap://127.0.0.1/";
>              arg "base cn=dns,dc=my-domain,dc=com";
>           arg "auth_method simple";
>      arg "bind_dn cn=Manager,dc=my-domain,dc=com";
>      arg "password *****";
>      arg "psearch no";
This option was removed (replaced by mandatory syncrepl).

>      // arg "serial_autoincrement yes";
This feature is now mandatory so the option was removed. Please make sure that 
bind-dyndb-ldap has write access to the configured sub-tree.

>      arg "sync_ptr yes";
>      arg "dyn_update yes";
>      arg "connections 2";
>           arg "cache_ttl 300";
This option was removed (replaced by mandatory syncrepl).

>      arg "verbose_checks yes";
> };

I hope this helps to prevent surprise after upgrade.

Let us know if you encounter any problems!

-- 
Petr^2 Spacek



From bpk678 at gmail.com  Tue Mar  4 13:26:07 2014
From: bpk678 at gmail.com (Brendan Kearney)
Date: Tue, 04 Mar 2014 08:26:07 -0500
Subject: [Freeipa-users] bind-dyndb-ldap 4.1 upgrade
In-Reply-To: <5315D0FD.7030606@redhat.com>
References: <1393712435.17594.6.camel@desktop.bpk2.com>
	<53143E60.1000502@redhat.com>	<1393883855.11276.20.camel@desktop.bpk2.com>
	<53159D28.1050309@redhat.com> <5315D0FD.7030606@redhat.com>
Message-ID: <1393939567.2586.2.camel@desktop.bpk2.com>

On Tue, 2014-03-04 at 14:11 +0100, Petr Spacek wrote:
> Hello,
> 
> On 3.3.2014 22:57, Brendan Kearney wrote:
>  > Which distribution version you use? Fedora 20, with latest updates
>  > What plugin version you use? bind-dyndb-ldap-3.5-1.fc20.x86_64
> 
> Please make sure that you read and follow
> https://www.redhat.com/archives/freeipa-interest/2014-February/msg00001.html
> before you upgrade bind-dyndb-ldap to version 4.x.
> 
> The bind-dyndb-ldap 4.1 is being pushed to Fedora-updates repo right now.
> 
> I will comment on your configuration in-line:
> > Do you use bind-dyndb-ldap as part of ?FreeIPA installation? no, using
> > openldap-servers-2.4.39-2.fc20.x86_64
> Please make sure that syncrepl provider is configured on your LDAP server. 
> Syncrepl support on server side is *required* from version 4.0.
> 
> > Please provide dynamic-db section from configuration
> > file /etc/named.conf
> > dynamic-db "my-domain.com" {
> >              library "ldap.so";
> >           arg "uri ldap://127.0.0.1/";
> >              arg "base cn=dns,dc=my-domain,dc=com";
> >           arg "auth_method simple";
> >      arg "bind_dn cn=Manager,dc=my-domain,dc=com";
> >      arg "password *****";
> >      arg "psearch no";
> This option was removed (replaced by mandatory syncrepl).
> 
> >      // arg "serial_autoincrement yes";
> This feature is now mandatory so the option was removed. Please make sure that 
> bind-dyndb-ldap has write access to the configured sub-tree.
> 
> >      arg "sync_ptr yes";
> >      arg "dyn_update yes";
> >      arg "connections 2";
> >           arg "cache_ttl 300";
> This option was removed (replaced by mandatory syncrepl).
> 
> >      arg "verbose_checks yes";
> > };
> 
> I hope this helps to prevent surprise after upgrade.
> 
> Let us know if you encounter any problems!
> 

syncrepl is configured and i am using it for N-Way Multi Master
Replication between 2 hosts.  are there specific configs i need to
add/change for the bind-dyndb-ldap piece?



From pspacek at redhat.com  Tue Mar  4 13:38:37 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Tue, 04 Mar 2014 14:38:37 +0100
Subject: [Freeipa-users] bind-dyndb-ldap 4.1 upgrade
In-Reply-To: <1393939567.2586.2.camel@desktop.bpk2.com>
References: <1393712435.17594.6.camel@desktop.bpk2.com>			<53143E60.1000502@redhat.com>	<1393883855.11276.20.camel@desktop.bpk2.com>	
	<53159D28.1050309@redhat.com> <5315D0FD.7030606@redhat.com>
	<1393939567.2586.2.camel@desktop.bpk2.com>
Message-ID: <5315D75D.4090509@redhat.com>

On 4.3.2014 14:26, Brendan Kearney wrote:
> On Tue, 2014-03-04 at 14:11 +0100, Petr Spacek wrote:
>> Hello,
>>
>> On 3.3.2014 22:57, Brendan Kearney wrote:
>>   > Which distribution version you use? Fedora 20, with latest updates
>>   > What plugin version you use? bind-dyndb-ldap-3.5-1.fc20.x86_64
>>
>> Please make sure that you read and follow
>> https://www.redhat.com/archives/freeipa-interest/2014-February/msg00001.html
>> before you upgrade bind-dyndb-ldap to version 4.x.
>>
>> The bind-dyndb-ldap 4.1 is being pushed to Fedora-updates repo right now.
>>
>> I will comment on your configuration in-line:
>>> Do you use bind-dyndb-ldap as part of ?FreeIPA installation? no, using
>>> openldap-servers-2.4.39-2.fc20.x86_64
>> Please make sure that syncrepl provider is configured on your LDAP server.
>> Syncrepl support on server side is *required* from version 4.0.
>>
>>> Please provide dynamic-db section from configuration
>>> file /etc/named.conf
>>> dynamic-db "my-domain.com" {
>>>               library "ldap.so";
>>>            arg "uri ldap://127.0.0.1/";
>>>               arg "base cn=dns,dc=my-domain,dc=com";
>>>            arg "auth_method simple";
>>>       arg "bind_dn cn=Manager,dc=my-domain,dc=com";
>>>       arg "password *****";
>>>       arg "psearch no";
>> This option was removed (replaced by mandatory syncrepl).
>>
>>>       // arg "serial_autoincrement yes";
>> This feature is now mandatory so the option was removed. Please make sure that
>> bind-dyndb-ldap has write access to the configured sub-tree.
>>
>>>       arg "sync_ptr yes";
>>>       arg "dyn_update yes";
>>>       arg "connections 2";
>>>            arg "cache_ttl 300";
>> This option was removed (replaced by mandatory syncrepl).
>>
>>>       arg "verbose_checks yes";
>>> };
>>
>> I hope this helps to prevent surprise after upgrade.
>>
>> Let us know if you encounter any problems!
>>
>
> syncrepl is configured and i am using it for N-Way Multi Master
> Replication between 2 hosts.  are there specific configs i need to
> add/change for the bind-dyndb-ldap piece?

I'm not aware of any, it should 'just work'. Version 4.0 requires a writable 
working directory but it is provided by RPM package so you should be ready for 
upgrade.

Enjoy :-)

-- 
Petr^2 Spacek



From shreerajkarulkar at yahoo.com  Tue Mar  4 18:28:31 2014
From: shreerajkarulkar at yahoo.com (Shree)
Date: Tue, 4 Mar 2014 10:28:31 -0800 (PST)
Subject: [Freeipa-users] HTTP Service: STOPPED
Message-ID: <1393957711.59955.YahooMailNeo@web160102.mail.bf1.yahoo.com>

Not sure what is going on?


I get the following error.
---------------

Starting httpd: (98)Address already in use: make_sock: could not bind to address [::]:443 
---------------

I have a feeling our puppet is causing some problem. I get the following when I run "puppet agent -t"
------------------
notice: /Stage[main]//Node[a-za-z0-9]/Service[httpd]/ensure: ensure changed 'stopped' to 'running'
------------------


ipa-server-3.0.0-26.el6_4.4.x86_64


Shreeraj 
---------------------------------------------------------------------------------------- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140304/7263f83c/attachment.htm>

From dpal at redhat.com  Tue Mar  4 18:41:27 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Tue, 04 Mar 2014 13:41:27 -0500
Subject: [Freeipa-users] HTTP Service: STOPPED
In-Reply-To: <1393957711.59955.YahooMailNeo@web160102.mail.bf1.yahoo.com>
References: <1393957711.59955.YahooMailNeo@web160102.mail.bf1.yahoo.com>
Message-ID: <53161E57.4010204@redhat.com>

On 03/04/2014 01:28 PM, Shree wrote:
> Not sure what is going on?
>
> I get the following error.
> ---------------
> Starting httpd: (98)Address already in use: make_sock: could not bind 
> to address [::]:443
> ---------------
>
> I have a feeling our puppet is causing some problem. I get the 
> following when I run "puppet agent -t"
> ------------------
> notice: /Stage[main]//Node[a-za-z0-9]/Service[httpd]/ensure: ensure 
> changed 'stopped' to 'running'
> ------------------
>
>
> ipa-server-3.0.0-26.el6_4.4.x86_64
>
> Shreeraj
> ---------------------------------------------------------------------------------------- 
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

This might be a collision between to services using the same port. IPA 
uses this port for HTTPS. If any other application is trying to use this 
port there will be a collision.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140304/d51123bd/attachment.htm>

From Duncan.Innes at virginmoney.com  Tue Mar  4 20:22:04 2014
From: Duncan.Innes at virginmoney.com (Innes, Duncan)
Date: Tue, 4 Mar 2014 20:22:04 -0000
Subject: [Freeipa-users] Replication issue
Message-ID: <56343345B145C043AE990701E3D193950478DAF2@EXVS2.nrplc.localnet>

Hi,
 
I'm testing an upgrade of my prod IPA servers in a dev cluster at the
moment.  Finally completed the upgrade, so I tested some user adds via
the WebUI.
 
Added user "aardvark" on ipa01 - replicated to ipa02
Added user "beaver" on ipa02 - NOT replicated to ipa01
Added user "banana" on ipa02 - replicated to ipa01
Added user "elephant" on ipa02 - replicated to ipa01
Edited user "beaver" on ipa02 - NOT replicated to ipa01
 
Is there anything I can do to force IPA to replicate that user from
ipa02 to ipa01?
 
I have tried running 'ipa-replica-manage force-sync --from ipa02' on
ipa01, but it hasn't appeared to do anything.
 
Thanks

Duncan

This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs.

This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message.

Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482).

For further details of Virgin Money group companies please visit our website at virginmoney.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140304/bf1240b0/attachment.htm>

From rmeggins at redhat.com  Tue Mar  4 22:40:59 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Tue, 04 Mar 2014 15:40:59 -0700
Subject: [Freeipa-users] Replication issue
In-Reply-To: <56343345B145C043AE990701E3D193950478DAF2@EXVS2.nrplc.localnet>
References: <56343345B145C043AE990701E3D193950478DAF2@EXVS2.nrplc.localnet>
Message-ID: <5316567B.50803@redhat.com>

On 03/04/2014 01:22 PM, Innes, Duncan wrote:
> Hi,
> I'm testing an upgrade of my prod IPA servers in a dev cluster at the 
> moment.  Finally completed the upgrade, so I tested some user adds via 
> the WebUI.
> Added user "aardvark" on ipa01 - replicated to ipa02
> Added user "beaver" on ipa02 - NOT replicated to ipa01
> Added user "banana" on ipa02 - replicated to ipa01
> Added user "elephant" on ipa02 - replicated to ipa01
> Edited user "beaver" on ipa02 - NOT replicated to ipa01

Is there anything in /var/log/dirsrv/slapd-DOMAIN-COM/errors on ipa01 or 
ipa02?

> Is there anything I can do to force IPA to replicate that user from 
> ipa02 to ipa01?
> I have tried running 'ipa-replica-manage force-sync --from ipa02' on 
> ipa01, but it hasn't appeared to do anything.
> Thanks
>
> Duncan
>
> This message has been checked for viruses and spam by the Virgin Money 
> email scanning system powered by Messagelabs.
>
> This e-mail is intended to be confidential to the recipient. If you 
> receive a copy in error, please inform the sender and then delete this 
> message.
>
> Virgin Money plc - Registered in England and Wales (Company no. 
> 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon 
> Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential 
> Regulation Authority and regulated by the Financial Conduct Authority 
> and the Prudential Regulation Authority.
>
> The following companies also trade as Virgin Money. They are both 
> authorised and regulated by the Financial Conduct Authority, are 
> registered in England and Wales and have their registered office at 
> Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money 
> Personal Financial Service Limited (Company no. 3072766) and Virgin 
> Money Unit Trust Managers Limited (Company no. 3000482).
>
> For further details of Virgin Money group companies please visit our 
> website at virginmoney.com
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140304/3286bf53/attachment.htm>

From Steven.Jones at vuw.ac.nz  Wed Mar  5 00:02:18 2014
From: Steven.Jones at vuw.ac.nz (Steven Jones)
Date: Wed, 5 Mar 2014 00:02:18 +0000
Subject: [Freeipa-users] Replication issue
In-Reply-To: <56343345B145C043AE990701E3D193950478DAF2@EXVS2.nrplc.localnet>
References: <56343345B145C043AE990701E3D193950478DAF2@EXVS2.nrplc.localnet>
Message-ID: <60a14d62852e4b0088ea5603c662243a@SINPR04MB298.apcprd04.prod.outlook.com>

RHEL 6.4 to RHEL 6.5?


regards

Steven


________________________________
From: freeipa-users-bounces at redhat.com <freeipa-users-bounces at redhat.com> on behalf of Innes, Duncan <Duncan.Innes at virginmoney.com>
Sent: Wednesday, 5 March 2014 9:22 a.m.
To: freeipa-users at redhat.com
Subject: [Freeipa-users] Replication issue

Hi,

I'm testing an upgrade of my prod IPA servers in a dev cluster at the moment.  Finally completed the upgrade, so I tested some user adds via the WebUI.

Added user "aardvark" on ipa01 - replicated to ipa02
Added user "beaver" on ipa02 - NOT replicated to ipa01
Added user "banana" on ipa02 - replicated to ipa01
Added user "elephant" on ipa02 - replicated to ipa01
Edited user "beaver" on ipa02 - NOT replicated to ipa01

Is there anything I can do to force IPA to replicate that user from ipa02 to ipa01?

I have tried running 'ipa-replica-manage force-sync --from ipa02' on ipa01, but it hasn't appeared to do anything.

Thanks

Duncan

This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs.

This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message.

Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482).

For further details of Virgin Money group companies please visit our website at virginmoney.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140305/6c21def5/attachment.htm>

From Duncan.Innes at virginmoney.com  Wed Mar  5 11:52:53 2014
From: Duncan.Innes at virginmoney.com (Innes, Duncan)
Date: Wed, 5 Mar 2014 11:52:53 -0000
Subject: [Freeipa-users] Replication issue
In-Reply-To: <60a14d62852e4b0088ea5603c662243a@SINPR04MB298.apcprd04.prod.outlook.com>
References: <56343345B145C043AE990701E3D193950478DAF2@EXVS2.nrplc.localnet>
	<60a14d62852e4b0088ea5603c662243a@SINPR04MB298.apcprd04.prod.outlook.com>
Message-ID: <56343345B145C043AE990701E3D193950478DAF3@EXVS2.nrplc.localnet>

Sorry - the upgrade was actually from RHEL 6.3 to RHEL 6.5.
 
ipa went from 
 
ipa-server-2.2.0-16.el6.x86_64
 
to 
 
ipa-server-3.0.0-37.el6.x86_64
 
Cheers
Duncan


________________________________

	From: freeipa-users-bounces at redhat.com
[mailto:freeipa-users-bounces at redhat.com] On Behalf Of Steven Jones
	Sent: 05 March 2014 00:02
	To: freeipa-users at redhat.com
	Subject: Re: [Freeipa-users] Replication issue
	
	

	RHEL 6.4 to RHEL 6.5?
	

	
	

	regards

	Steven 

	
	

________________________________

	From: freeipa-users-bounces at redhat.com
<freeipa-users-bounces at redhat.com> on behalf of Innes, Duncan
<Duncan.Innes at virginmoney.com>
	Sent: Wednesday, 5 March 2014 9:22 a.m.
	To: freeipa-users at redhat.com
	Subject: [Freeipa-users] Replication issue 
	 
	Hi,
	 
	I'm testing an upgrade of my prod IPA servers in a dev cluster
at the moment.  Finally completed the upgrade, so I tested some user
adds via the WebUI.
	 
	Added user "aardvark" on ipa01 - replicated to ipa02
	Added user "beaver" on ipa02 - NOT replicated to ipa01
	Added user "banana" on ipa02 - replicated to ipa01
	Added user "elephant" on ipa02 - replicated to ipa01
	Edited user "beaver" on ipa02 - NOT replicated to ipa01
	 
	Is there anything I can do to force IPA to replicate that user
from ipa02 to ipa01?
	 
	I have tried running 'ipa-replica-manage force-sync --from
ipa02' on ipa01, but it hasn't appeared to do anything.
	 
	Thanks
	
	Duncan

	This message has been checked for viruses and spam by the Virgin
Money email scanning system powered by Messagelabs.
	
	This e-mail is intended to be confidential to the recipient. If
you receive a copy in error, please inform the sender and then delete
this message.
	
	Virgin Money plc - Registered in England and Wales (Company no.
6952311). Registered office - Jubilee House, Gosforth, Newcastle upon
Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential
Regulation Authority and regulated by the Financial Conduct Authority
and the Prudential Regulation Authority.
	
	The following companies also trade as Virgin Money. They are
both authorised and regulated by the Financial Conduct Authority, are
registered in England and Wales and have their registered office at
Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money
Personal Financial Service Limited (Company no. 3072766) and Virgin
Money Unit Trust Managers Limited (Company no. 3000482).
	
	For further details of Virgin Money group companies please visit
our website at virginmoney.com
	

	This message has been checked for viruses and spam by the Virgin
Money email scanning system powered by Messagelabs.
	


This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs.

This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message.

Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482).

For further details of Virgin Money group companies please visit our website at virginmoney.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140305/4f26d4ec/attachment.htm>

From Duncan.Innes at virginmoney.com  Wed Mar  5 11:56:05 2014
From: Duncan.Innes at virginmoney.com (Innes, Duncan)
Date: Wed, 5 Mar 2014 11:56:05 -0000
Subject: [Freeipa-users] Replication issue
In-Reply-To: <5316567B.50803@redhat.com>
References: <56343345B145C043AE990701E3D193950478DAF2@EXVS2.nrplc.localnet>
	<5316567B.50803@redhat.com>
Message-ID: <56343345B145C043AE990701E3D193950478DAF4@EXVS2.nrplc.localnet>

I didn't record the time that the "beaver" user was added to ipa2, but
the logs after the upgrade & reboot are:
 
ipa01
=====
[04/Mar/2014:19:16:05 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
not connected)
[04/Mar/2014:19:16:05 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)
[04/Mar/2014:19:16:05 +0000] NSMMReplicationPlugin -
agmt="cn=meTolvdlvldap02.unix.vmoney.local" (lvdlvldap02:389):
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ((null))
[04/Mar/2014:19:16:09 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
not connected)
[04/Mar/2014:19:16:09 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)
[04/Mar/2014:19:16:16 +0000] NSMMReplicationPlugin -
agmt="cn=meTolvdlvldap02.unix.vmoney.local" (lvdlvldap02:389):
Replication bind with GSSAPI auth resumed
[04/Mar/2014:19:26:49 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
not connected)
[04/Mar/2014:19:26:49 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)
[04/Mar/2014:19:26:49 +0000] NSMMReplicationPlugin -
agmt="cn=meTolvdlvldap02.unix.vmoney.local" (lvdlvldap02:389):
Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact
LDAP server) ((null))
[04/Mar/2014:19:26:55 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
not connected)
[04/Mar/2014:19:26:55 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)
[04/Mar/2014:19:27:01 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
not connected)
[04/Mar/2014:19:27:01 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)
[04/Mar/2014:19:27:13 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
not connected)
[04/Mar/2014:19:27:13 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)
[04/Mar/2014:19:27:37 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
not connected)
[04/Mar/2014:19:27:37 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)
[04/Mar/2014:19:28:25 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
not connected)
[04/Mar/2014:19:28:25 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)
[04/Mar/2014:19:30:01 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
not connected)
[04/Mar/2014:19:30:01 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)
[04/Mar/2014:19:33:13 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
not connected)
[04/Mar/2014:19:33:13 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)
[04/Mar/2014:19:38:13 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
not connected)
[04/Mar/2014:19:38:13 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)
[04/Mar/2014:19:43:13 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
not connected)
[04/Mar/2014:19:43:13 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server)
[04/Mar/2014:19:48:10 +0000] NSMMReplicationPlugin -
agmt="cn=meTolvdlvldap02.unix.vmoney.local" (lvdlvldap02:389):
Replication bind with GSSAPI auth resumed
[04/Mar/2014:19:57:08 +0000] - slapd shutting down - signaling operation
threads
[04/Mar/2014:19:57:08 +0000] - slapd shutting down - closing down
internal subsystems and plugins
[04/Mar/2014:19:57:08 +0000] - Waiting for 4 database threads to stop
[04/Mar/2014:19:57:08 +0000] - All database threads now stopped
[04/Mar/2014:19:57:08 +0000] - slapd stopped.
[04/Mar/2014:19:57:44 +0000] - 389-Directory/1.2.11.15 B2013.337.1530
starting up
[04/Mar/2014:19:57:44 +0000] - WARNING: userRoot: entry cache size
10485760B is less than db size 14467072B; We recommend to increase the
entry cache size nsslapd-cachememsize.
[04/Mar/2014:19:57:44 +0000] schema-compat-plugin - warning: no entries
set up under cn=computers, cn=compat,dc=dev,dc=vmoney,dc=local
[04/Mar/2014:19:57:46 +0000] schema-compat-plugin - warning: no entries
set up under ou=sudoers,dc=dev,dc=vmoney,dc=local
[04/Mar/2014:19:57:47 +0000] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found,
which should be added before the CoS Definition.
[04/Mar/2014:19:57:47 +0000] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found,
which should be added before the CoS Definition.
[04/Mar/2014:19:57:47 +0000] set_krb5_creds - Could not get initial
credentials for principal
[ldap/lvdlvldap01.unix.vmoney.local at DEV.VMONEY.LOCAL] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)
[04/Mar/2014:19:57:47 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure.  Minor code may provide more information (Credentials cache
file '/tmp/krb5cc_493' not found)) errno 0 (Success)
[04/Mar/2014:19:57:47 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
[04/Mar/2014:19:57:47 +0000] NSMMReplicationPlugin -
agmt="cn=meTolvdlvldap02.unix.vmoney.local" (lvdlvldap02:389):
Replication bind with GSSAPI auth failed: LDAP error -2 (Local error)
(SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
Minor code may provide more information (Credentials cache file
'/tmp/krb5cc_493' not found))
[04/Mar/2014:19:57:47 +0000] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[04/Mar/2014:19:57:47 +0000] - Listening on All Interfaces port 636 for
LDAPS requests
[04/Mar/2014:19:57:47 +0000] - Listening on
/var/run/slapd-DEV-VMONEY-LOCAL.socket for LDAPI requests
[04/Mar/2014:19:57:51 +0000] NSMMReplicationPlugin -
agmt="cn=meTolvdlvldap02.unix.vmoney.local" (lvdlvldap02:389):
Replication bind with GSSAPI auth resumed

 
ipa02
=====
[04/Mar/2014:19:16:07 +0000] - 389-Directory/1.2.11.15 B2013.337.1530
starting up
[04/Mar/2014:19:16:08 +0000] - WARNING: userRoot: entry cache size
10485760B is less than db size 14401536B; We recommend to increase the
entry cache size nsslapd-cachememsize.
[04/Mar/2014:19:16:08 +0000] schema-compat-plugin - warning: no entries
set up under cn=computers, cn=compat,dc=dev,dc=vmoney,dc=local
[04/Mar/2014:19:16:10 +0000] schema-compat-plugin - warning: no entries
set up under ou=sudoers,dc=dev,dc=vmoney,dc=local
[04/Mar/2014:19:16:11 +0000] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found,
which should be added before the CoS Definition.
[04/Mar/2014:19:16:11 +0000] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found,
which should be added before the CoS Definition.
[04/Mar/2014:19:16:11 +0000] set_krb5_creds - Could not get initial
credentials for principal
[ldap/lvdlvldap02.unix.vmoney.local at DEV.VMONEY.LOCAL] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)
[04/Mar/2014:19:16:11 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure.  Minor code may provide more information (Credentials cache
file '/tmp/krb5cc_495' not found)) errno 0 (Success)
[04/Mar/2014:19:16:11 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
[04/Mar/2014:19:16:11 +0000] NSMMReplicationPlugin -
agmt="cn=meTolvdlvldap01.unix.vmoney.local" (lvdlvldap01:389):
Replication bind with GSSAPI auth failed: LDAP error -2 (Local error)
(SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
Minor code may provide more information (Credentials cache file
'/tmp/krb5cc_495' not found))
[04/Mar/2014:19:16:11 +0000] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[04/Mar/2014:19:16:11 +0000] - Listening on All Interfaces port 636 for
LDAPS requests
[04/Mar/2014:19:16:11 +0000] - Listening on
/var/run/slapd-DEV-VMONEY-LOCAL.socket for LDAPI requests
[04/Mar/2014:19:16:14 +0000] NSMMReplicationPlugin -
agmt="cn=meTolvdlvldap01.unix.vmoney.local" (lvdlvldap01:389):
Replication bind with GSSAPI auth resumed
[04/Mar/2014:19:22:07 +0000] - slapd shutting down - signaling operation
threads
[04/Mar/2014:19:22:07 +0000] - slapd shutting down - closing down
internal subsystems and plugins
[04/Mar/2014:19:22:08 +0000] - Waiting for 4 database threads to stop
[04/Mar/2014:19:22:08 +0000] - All database threads now stopped
[04/Mar/2014:19:22:08 +0000] - slapd stopped.
[04/Mar/2014:19:47:32 +0000] - 389-Directory/1.2.11.15 B2013.337.1530
starting up
[04/Mar/2014:19:47:32 +0000] - WARNING: userRoot: entry cache size
10485760B is less than db size 14401536B; We recommend to increase the
entry cache size nsslapd-cachememsize.
[04/Mar/2014:19:47:32 +0000] schema-compat-plugin - warning: no entries
set up under cn=computers, cn=compat,dc=dev,dc=vmoney,dc=local
[04/Mar/2014:19:47:34 +0000] schema-compat-plugin - warning: no entries
set up under ou=sudoers,dc=dev,dc=vmoney,dc=local
[04/Mar/2014:19:47:35 +0000] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found,
which should be added before the CoS Definition.
[04/Mar/2014:19:47:35 +0000] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found,
which should be added before the CoS Definition.
[04/Mar/2014:19:47:35 +0000] set_krb5_creds - Could not get initial
credentials for principal
[ldap/lvdlvldap02.unix.vmoney.local at DEV.VMONEY.LOCAL] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)
[04/Mar/2014:19:47:35 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure.  Minor code may provide more information (Credentials cache
file '/tmp/krb5cc_495' not found)) errno 0 (Success)
[04/Mar/2014:19:47:35 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
[04/Mar/2014:19:47:35 +0000] NSMMReplicationPlugin -
agmt="cn=meTolvdlvldap01.unix.vmoney.local" (lvdlvldap01:389):
Replication bind with GSSAPI auth failed: LDAP error -2 (Local error)
(SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
Minor code may provide more information (Credentials cache file
'/tmp/krb5cc_495' not found))
[04/Mar/2014:19:47:35 +0000] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[04/Mar/2014:19:47:35 +0000] - Listening on All Interfaces port 636 for
LDAPS requests
[04/Mar/2014:19:47:35 +0000] - Listening on
/var/run/slapd-DEV-VMONEY-LOCAL.socket for LDAPI requests
[04/Mar/2014:19:47:39 +0000] NSMMReplicationPlugin -
agmt="cn=meTolvdlvldap01.unix.vmoney.local" (lvdlvldap01:389):
Replication bind with GSSAPI auth resumed
[04/Mar/2014:19:54:10 +0000] NSMMReplicationPlugin - changelog program -
_cl5WriteOperationTxn: retry (49) the transaction
(csn=53162f5f000000030000) failed (rc=-30994 (DB_LOCK_DEADLOCK: Locker
killed to resolve a deadlock))
[04/Mar/2014:19:54:10 +0000] NSMMReplicationPlugin - changelog program -
_cl5WriteOperationTxn: failed to write entry with csn
(53162f5f000000030000); db error - -30994 DB_LOCK_DEADLOCK: Locker
killed to resolve a deadlock
[04/Mar/2014:19:54:10 +0000] NSMMReplicationPlugin -
write_changelog_and_ruv: can't add a change for
uid=beaver,cn=users,cn=accounts,dc=dev,dc=vmoney,dc=local (uniqid:
a9e60601-a3d611e3-ba5495ee-66868ebf, optype: 16) to changelog csn
53162f5f000000030000
[04/Mar/2014:19:59:38 +0000] - slapd shutting down - signaling operation
threads
[04/Mar/2014:19:59:38 +0000] - slapd shutting down - closing down
internal subsystems and plugins
[04/Mar/2014:19:59:38 +0000] - Waiting for 4 database threads to stop
[04/Mar/2014:19:59:39 +0000] - All database threads now stopped
[04/Mar/2014:19:59:39 +0000] - slapd stopped.
[04/Mar/2014:20:00:16 +0000] - 389-Directory/1.2.11.15 B2013.337.1530
starting up
[04/Mar/2014:20:00:16 +0000] - WARNING: userRoot: entry cache size
10485760B is less than db size 14434304B; We recommend to increase the
entry cache size nsslapd-cachememsize.
[04/Mar/2014:20:00:16 +0000] schema-compat-plugin - warning: no entries
set up under cn=computers, cn=compat,dc=dev,dc=vmoney,dc=local
[04/Mar/2014:20:00:18 +0000] schema-compat-plugin - warning: no entries
set up under ou=sudoers,dc=dev,dc=vmoney,dc=local
[04/Mar/2014:20:00:18 +0000] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found,
which should be added before the CoS Definition.
[04/Mar/2014:20:00:19 +0000] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found,
which should be added before the CoS Definition.
[04/Mar/2014:20:00:19 +0000] set_krb5_creds - Could not get initial
credentials for principal
[ldap/lvdlvldap02.unix.vmoney.local at DEV.VMONEY.LOCAL] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)
[04/Mar/2014:20:00:19 +0000] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure.  Minor code may provide more information (Credentials cache
file '/tmp/krb5cc_495' not found)) errno 0 (Success)
[04/Mar/2014:20:00:19 +0000] slapi_ldap_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
[04/Mar/2014:20:00:19 +0000] NSMMReplicationPlugin -
agmt="cn=meTolvdlvldap01.unix.vmoney.local" (lvdlvldap01:389):
Replication bind with GSSAPI auth failed: LDAP error -2 (Local error)
(SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
Minor code may provide more information (Credentials cache file
'/tmp/krb5cc_495' not found))
[04/Mar/2014:20:00:19 +0000] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[04/Mar/2014:20:00:19 +0000] - Listening on All Interfaces port 636 for
LDAPS requests
[04/Mar/2014:20:00:19 +0000] - Listening on
/var/run/slapd-DEV-VMONEY-LOCAL.socket for LDAPI requests
[04/Mar/2014:20:00:22 +0000] NSMMReplicationPlugin -
agmt="cn=meTolvdlvldap01.unix.vmoney.local" (lvdlvldap01:389):
Replication bind with GSSAPI auth resumed

The confusing point for me is that users were successfully added in each
direction before and after the failing "beaver" user.
 
Cheers
Duncan


________________________________

	From: Rich Megginson [mailto:rmeggins at redhat.com] 
	Sent: 04 March 2014 22:41
	To: Innes, Duncan; freeipa-users at redhat.com
	Subject: Re: [Freeipa-users] Replication issue
	
	
	On 03/04/2014 01:22 PM, Innes, Duncan wrote:
	

		Hi,
		 
		I'm testing an upgrade of my prod IPA servers in a dev
cluster at the moment.  Finally completed the upgrade, so I tested some
user adds via the WebUI.
		 
		Added user "aardvark" on ipa01 - replicated to ipa02
		Added user "beaver" on ipa02 - NOT replicated to ipa01
		Added user "banana" on ipa02 - replicated to ipa01
		Added user "elephant" on ipa02 - replicated to ipa01
		Edited user "beaver" on ipa02 - NOT replicated to ipa01


	Is there anything in /var/log/dirsrv/slapd-DOMAIN-COM/errors on
ipa01 or ipa02?
	
	

		 
		Is there anything I can do to force IPA to replicate
that user from ipa02 to ipa01?
		 
		I have tried running 'ipa-replica-manage force-sync
--from ipa02' on ipa01, but it hasn't appeared to do anything.
		 
		Thanks
		
		Duncan

		This message has been checked for viruses and spam by
the Virgin Money email scanning system powered by Messagelabs.
		
		This e-mail is intended to be confidential to the
recipient. If you receive a copy in error, please inform the sender and
then delete this message.
		
		Virgin Money plc - Registered in England and Wales
(Company no. 6952311). Registered office - Jubilee House, Gosforth,
Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the
Prudential Regulation Authority and regulated by the Financial Conduct
Authority and the Prudential Regulation Authority.
		
		The following companies also trade as Virgin Money. They
are both authorised and regulated by the Financial Conduct Authority,
are registered in England and Wales and have their registered office at
Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money
Personal Financial Service Limited (Company no. 3072766) and Virgin
Money Unit Trust Managers Limited (Company no. 3000482).
		
		For further details of Virgin Money group companies
please visit our website at virginmoney.com
		
		 
		
		_______________________________________________
		Freeipa-users mailing list
		Freeipa-users at redhat.com
		https://www.redhat.com/mailman/listinfo/freeipa-users



	This message has been checked for viruses and spam by the Virgin
Money email scanning system powered by Messagelabs.
	


This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs.

This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message.

Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482).

For further details of Virgin Money group companies please visit our website at virginmoney.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140305/bc4f1b47/attachment.htm>

From jokajak at gmail.com  Wed Mar  5 12:42:36 2014
From: jokajak at gmail.com (Josh)
Date: Wed, 05 Mar 2014 07:42:36 -0500
Subject: [Freeipa-users] selinuxusermap prioritization
Message-ID: <53171BBC.2010500@gmail.com>

I'm trying to use selinuxusermap to configure the SELinux role that 
users are assigned when they logged in to systems.  I have a question of 
what algorithm is used to determine which rule wins when multiple match.

My current setup is:

ipa selinuxusermap-add staff_u  --selinuxuser=staff_u:s0-s0:c0.c1023
ipa selinuxusermap-add resadm_u  --selinuxuser=resadm_u:s0-s0:c0.c1023
ipa selinuxusermap-add-host staff_u --hostgroups=targeted
ipa selinuxusermap-add-host resadm_u --hostgroups=targeted
ipa selinuxusermap-add-user staff_u --groups=wheel
ipa selinuxusermap-add-user resadm_u --groups=somegroup

ipa user-add jokajak --first=Joka --last=Jak --email=jokajak at gmail.com
ipa group-add-member wheel --users=jokajak
ipa group-add-member somegroup --users=jokajak

My current scenario is:

When I log in to a system I am assigned the resadm role but I would like 
to be assigned the staff_u role.  I tried naming the selinuxusermap 
ZZ_resadm_u and 99_resadm_u but that had no effect.

Any recommendations?

Thanks,
-josh



From jhrozek at redhat.com  Wed Mar  5 13:39:53 2014
From: jhrozek at redhat.com (Jakub Hrozek)
Date: Wed, 5 Mar 2014 14:39:53 +0100
Subject: [Freeipa-users] selinuxusermap prioritization
In-Reply-To: <53171BBC.2010500@gmail.com>
References: <53171BBC.2010500@gmail.com>
Message-ID: <20140305133953.GF15687@hendrix.redhat.com>

On Wed, Mar 05, 2014 at 07:42:36AM -0500, Josh wrote:
> I'm trying to use selinuxusermap to configure the SELinux role that
> users are assigned when they logged in to systems.  I have a
> question of what algorithm is used to determine which rule wins when
> multiple match.
> 
> My current setup is:
> 
> ipa selinuxusermap-add staff_u  --selinuxuser=staff_u:s0-s0:c0.c1023
> ipa selinuxusermap-add resadm_u  --selinuxuser=resadm_u:s0-s0:c0.c1023
> ipa selinuxusermap-add-host staff_u --hostgroups=targeted
> ipa selinuxusermap-add-host resadm_u --hostgroups=targeted
> ipa selinuxusermap-add-user staff_u --groups=wheel
> ipa selinuxusermap-add-user resadm_u --groups=somegroup
> 
> ipa user-add jokajak --first=Joka --last=Jak --email=jokajak at gmail.com
> ipa group-add-member wheel --users=jokajak
> ipa group-add-member somegroup --users=jokajak
> 
> My current scenario is:
> 
> When I log in to a system I am assigned the resadm role but I would
> like to be assigned the staff_u role.  I tried naming the
> selinuxusermap ZZ_resadm_u and 99_resadm_u but that had no effect.
> 
> Any recommendations?
> 
> Thanks,
> -josh

I think you need to modify the ordering (with ipa config-mod) so that
staff_u is higher priority than resadm.

See http://www.freeipa.org/page/SELinux_user_mapping#Evaluation



From rmeggins at redhat.com  Wed Mar  5 14:40:09 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Wed, 05 Mar 2014 07:40:09 -0700
Subject: [Freeipa-users] Replication issue
In-Reply-To: <56343345B145C043AE990701E3D193950478DAF4@EXVS2.nrplc.localnet>
References: <56343345B145C043AE990701E3D193950478DAF2@EXVS2.nrplc.localnet>
	<5316567B.50803@redhat.com>
	<56343345B145C043AE990701E3D193950478DAF4@EXVS2.nrplc.localnet>
Message-ID: <53173749.4090100@redhat.com>

On 03/05/2014 04:56 AM, Innes, Duncan wrote:
> I didn't record the time that the "beaver" user was added to ipa2, but 
> the logs after the upgrade & reboot are:
> ipa01
> =====
> [04/Mar/2014:19:16:05 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint 
> is not connected)
> [04/Mar/2014:19:16:05 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't 
> contact LDAP server)
> [04/Mar/2014:19:16:05 +0000] NSMMReplicationPlugin - 
> agmt="cn=meTolvdlvldap02.unix.vmoney.local" (lvdlvldap02:389): 
> Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact 
> LDAP server) ((null))
> [04/Mar/2014:19:16:09 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint 
> is not connected)
> [04/Mar/2014:19:16:09 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't 
> contact LDAP server)
> [04/Mar/2014:19:16:16 +0000] NSMMReplicationPlugin - 
> agmt="cn=meTolvdlvldap02.unix.vmoney.local" (lvdlvldap02:389): 
> Replication bind with GSSAPI auth resumed
> [04/Mar/2014:19:26:49 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint 
> is not connected)
> [04/Mar/2014:19:26:49 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't 
> contact LDAP server)
> [04/Mar/2014:19:26:49 +0000] NSMMReplicationPlugin - 
> agmt="cn=meTolvdlvldap02.unix.vmoney.local" (lvdlvldap02:389): 
> Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact 
> LDAP server) ((null))
> [04/Mar/2014:19:26:55 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint 
> is not connected)
> [04/Mar/2014:19:26:55 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't 
> contact LDAP server)
> [04/Mar/2014:19:27:01 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint 
> is not connected)
> [04/Mar/2014:19:27:01 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't 
> contact LDAP server)
> [04/Mar/2014:19:27:13 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint 
> is not connected)
> [04/Mar/2014:19:27:13 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't 
> contact LDAP server)
> [04/Mar/2014:19:27:37 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint 
> is not connected)
> [04/Mar/2014:19:27:37 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't 
> contact LDAP server)
> [04/Mar/2014:19:28:25 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint 
> is not connected)
> [04/Mar/2014:19:28:25 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't 
> contact LDAP server)
> [04/Mar/2014:19:30:01 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint 
> is not connected)
> [04/Mar/2014:19:30:01 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't 
> contact LDAP server)
> [04/Mar/2014:19:33:13 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint 
> is not connected)
> [04/Mar/2014:19:33:13 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't 
> contact LDAP server)
> [04/Mar/2014:19:38:13 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint 
> is not connected)
> [04/Mar/2014:19:38:13 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't 
> contact LDAP server)
> [04/Mar/2014:19:43:13 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint 
> is not connected)
> [04/Mar/2014:19:43:13 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't 
> contact LDAP server)
> [04/Mar/2014:19:48:10 +0000] NSMMReplicationPlugin - 
> agmt="cn=meTolvdlvldap02.unix.vmoney.local" (lvdlvldap02:389): 
> Replication bind with GSSAPI auth resumed
> [04/Mar/2014:19:57:08 +0000] - slapd shutting down - signaling 
> operation threads
> [04/Mar/2014:19:57:08 +0000] - slapd shutting down - closing down 
> internal subsystems and plugins
> [04/Mar/2014:19:57:08 +0000] - Waiting for 4 database threads to stop
> [04/Mar/2014:19:57:08 +0000] - All database threads now stopped
> [04/Mar/2014:19:57:08 +0000] - slapd stopped.
> [04/Mar/2014:19:57:44 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 
> starting up
> [04/Mar/2014:19:57:44 +0000] - WARNING: userRoot: entry cache size 
> 10485760B is less than db size 14467072B; We recommend to increase the 
> entry cache size nsslapd-cachememsize.
> [04/Mar/2014:19:57:44 +0000] schema-compat-plugin - warning: no 
> entries set up under cn=computers, cn=compat,dc=dev,dc=vmoney,dc=local
> [04/Mar/2014:19:57:46 +0000] schema-compat-plugin - warning: no 
> entries set up under ou=sudoers,dc=dev,dc=vmoney,dc=local
> [04/Mar/2014:19:57:47 +0000] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found, 
> which should be added before the CoS Definition.
> [04/Mar/2014:19:57:47 +0000] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found, 
> which should be added before the CoS Definition.
> [04/Mar/2014:19:57:47 +0000] set_krb5_creds - Could not get initial 
> credentials for principal 
> [ldap/lvdlvldap01.unix.vmoney.local at DEV.VMONEY.LOCAL] in keytab 
> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for 
> requested realm)
> [04/Mar/2014:19:57:47 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified 
> GSS failure.  Minor code may provide more information (Credentials 
> cache file '/tmp/krb5cc_493' not found)) errno 0 (Success)
> [04/Mar/2014:19:57:47 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
> [04/Mar/2014:19:57:47 +0000] NSMMReplicationPlugin - 
> agmt="cn=meTolvdlvldap02.unix.vmoney.local" (lvdlvldap02:389): 
> Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) 
> (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
> Minor code may provide more information (Credentials cache file 
> '/tmp/krb5cc_493' not found))
> [04/Mar/2014:19:57:47 +0000] - slapd started.  Listening on All 
> Interfaces port 389 for LDAP requests
> [04/Mar/2014:19:57:47 +0000] - Listening on All Interfaces port 636 
> for LDAPS requests
> [04/Mar/2014:19:57:47 +0000] - Listening on 
> /var/run/slapd-DEV-VMONEY-LOCAL.socket for LDAPI requests
> [04/Mar/2014:19:57:51 +0000] NSMMReplicationPlugin - 
> agmt="cn=meTolvdlvldap02.unix.vmoney.local" (lvdlvldap02:389): 
> Replication bind with GSSAPI auth resumed
> ipa02
> =====
> [04/Mar/2014:19:16:07 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 
> starting up
> [04/Mar/2014:19:16:08 +0000] - WARNING: userRoot: entry cache size 
> 10485760B is less than db size 14401536B; We recommend to increase the 
> entry cache size nsslapd-cachememsize.
> [04/Mar/2014:19:16:08 +0000] schema-compat-plugin - warning: no 
> entries set up under cn=computers, cn=compat,dc=dev,dc=vmoney,dc=local
> [04/Mar/2014:19:16:10 +0000] schema-compat-plugin - warning: no 
> entries set up under ou=sudoers,dc=dev,dc=vmoney,dc=local
> [04/Mar/2014:19:16:11 +0000] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found, 
> which should be added before the CoS Definition.
> [04/Mar/2014:19:16:11 +0000] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found, 
> which should be added before the CoS Definition.
> [04/Mar/2014:19:16:11 +0000] set_krb5_creds - Could not get initial 
> credentials for principal 
> [ldap/lvdlvldap02.unix.vmoney.local at DEV.VMONEY.LOCAL] in keytab 
> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for 
> requested realm)
> [04/Mar/2014:19:16:11 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified 
> GSS failure.  Minor code may provide more information (Credentials 
> cache file '/tmp/krb5cc_495' not found)) errno 0 (Success)
> [04/Mar/2014:19:16:11 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
> [04/Mar/2014:19:16:11 +0000] NSMMReplicationPlugin - 
> agmt="cn=meTolvdlvldap01.unix.vmoney.local" (lvdlvldap01:389): 
> Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) 
> (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
> Minor code may provide more information (Credentials cache file 
> '/tmp/krb5cc_495' not found))
> [04/Mar/2014:19:16:11 +0000] - slapd started.  Listening on All 
> Interfaces port 389 for LDAP requests
> [04/Mar/2014:19:16:11 +0000] - Listening on All Interfaces port 636 
> for LDAPS requests
> [04/Mar/2014:19:16:11 +0000] - Listening on 
> /var/run/slapd-DEV-VMONEY-LOCAL.socket for LDAPI requests
> [04/Mar/2014:19:16:14 +0000] NSMMReplicationPlugin - 
> agmt="cn=meTolvdlvldap01.unix.vmoney.local" (lvdlvldap01:389): 
> Replication bind with GSSAPI auth resumed
> [04/Mar/2014:19:22:07 +0000] - slapd shutting down - signaling 
> operation threads
> [04/Mar/2014:19:22:07 +0000] - slapd shutting down - closing down 
> internal subsystems and plugins
> [04/Mar/2014:19:22:08 +0000] - Waiting for 4 database threads to stop
> [04/Mar/2014:19:22:08 +0000] - All database threads now stopped
> [04/Mar/2014:19:22:08 +0000] - slapd stopped.
> [04/Mar/2014:19:47:32 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 
> starting up
> [04/Mar/2014:19:47:32 +0000] - WARNING: userRoot: entry cache size 
> 10485760B is less than db size 14401536B; We recommend to increase the 
> entry cache size nsslapd-cachememsize.
> [04/Mar/2014:19:47:32 +0000] schema-compat-plugin - warning: no 
> entries set up under cn=computers, cn=compat,dc=dev,dc=vmoney,dc=local
> [04/Mar/2014:19:47:34 +0000] schema-compat-plugin - warning: no 
> entries set up under ou=sudoers,dc=dev,dc=vmoney,dc=local
> [04/Mar/2014:19:47:35 +0000] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found, 
> which should be added before the CoS Definition.
> [04/Mar/2014:19:47:35 +0000] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found, 
> which should be added before the CoS Definition.
> [04/Mar/2014:19:47:35 +0000] set_krb5_creds - Could not get initial 
> credentials for principal 
> [ldap/lvdlvldap02.unix.vmoney.local at DEV.VMONEY.LOCAL] in keytab 
> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for 
> requested realm)
> [04/Mar/2014:19:47:35 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified 
> GSS failure.  Minor code may provide more information (Credentials 
> cache file '/tmp/krb5cc_495' not found)) errno 0 (Success)
> [04/Mar/2014:19:47:35 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
> [04/Mar/2014:19:47:35 +0000] NSMMReplicationPlugin - 
> agmt="cn=meTolvdlvldap01.unix.vmoney.local" (lvdlvldap01:389): 
> Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) 
> (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
> Minor code may provide more information (Credentials cache file 
> '/tmp/krb5cc_495' not found))
> [04/Mar/2014:19:47:35 +0000] - slapd started.  Listening on All 
> Interfaces port 389 for LDAP requests
> [04/Mar/2014:19:47:35 +0000] - Listening on All Interfaces port 636 
> for LDAPS requests
> [04/Mar/2014:19:47:35 +0000] - Listening on 
> /var/run/slapd-DEV-VMONEY-LOCAL.socket for LDAPI requests
> [04/Mar/2014:19:47:39 +0000] NSMMReplicationPlugin - 
> agmt="cn=meTolvdlvldap01.unix.vmoney.local" (lvdlvldap01:389): 
> Replication bind with GSSAPI auth resumed
> [04/Mar/2014:19:54:10 +0000] NSMMReplicationPlugin - changelog program 
> - _cl5WriteOperationTxn: retry (49) the transaction 
> (csn=53162f5f000000030000) failed (rc=-30994 (DB_LOCK_DEADLOCK: Locker 
> killed to resolve a deadlock))
> [04/Mar/2014:19:54:10 +0000] NSMMReplicationPlugin - changelog program 
> - _cl5WriteOperationTxn: failed to write entry with csn 
> (53162f5f000000030000); db error - -30994 DB_LOCK_DEADLOCK: Locker 
> killed to resolve a deadlock
> [04/Mar/2014:19:54:10 +0000] NSMMReplicationPlugin - 
> write_changelog_and_ruv: can't add a change for 
> uid=beaver,cn=users,cn=accounts,dc=dev,dc=vmoney,dc=local (uniqid: 
> a9e60601-a3d611e3-ba5495ee-66868ebf, optype: 16) to changelog csn 
> 53162f5f000000030000
> [04/Mar/2014:19:59:38 +0000] - slapd shutting down - signaling 
> operation threads
> [04/Mar/2014:19:59:38 +0000] - slapd shutting down - closing down 
> internal subsystems and plugins
> [04/Mar/2014:19:59:38 +0000] - Waiting for 4 database threads to stop
> [04/Mar/2014:19:59:39 +0000] - All database threads now stopped
> [04/Mar/2014:19:59:39 +0000] - slapd stopped.
> [04/Mar/2014:20:00:16 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 
> starting up
> [04/Mar/2014:20:00:16 +0000] - WARNING: userRoot: entry cache size 
> 10485760B is less than db size 14434304B; We recommend to increase the 
> entry cache size nsslapd-cachememsize.
> [04/Mar/2014:20:00:16 +0000] schema-compat-plugin - warning: no 
> entries set up under cn=computers, cn=compat,dc=dev,dc=vmoney,dc=local
> [04/Mar/2014:20:00:18 +0000] schema-compat-plugin - warning: no 
> entries set up under ou=sudoers,dc=dev,dc=vmoney,dc=local
> [04/Mar/2014:20:00:18 +0000] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found, 
> which should be added before the CoS Definition.
> [04/Mar/2014:20:00:19 +0000] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=dev,dc=vmoney,dc=local--no CoS Templates found, 
> which should be added before the CoS Definition.
> [04/Mar/2014:20:00:19 +0000] set_krb5_creds - Could not get initial 
> credentials for principal 
> [ldap/lvdlvldap02.unix.vmoney.local at DEV.VMONEY.LOCAL] in keytab 
> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for 
> requested realm)
> [04/Mar/2014:20:00:19 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified 
> GSS failure.  Minor code may provide more information (Credentials 
> cache file '/tmp/krb5cc_495' not found)) errno 0 (Success)
> [04/Mar/2014:20:00:19 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
> [04/Mar/2014:20:00:19 +0000] NSMMReplicationPlugin - 
> agmt="cn=meTolvdlvldap01.unix.vmoney.local" (lvdlvldap01:389): 
> Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) 
> (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
> Minor code may provide more information (Credentials cache file 
> '/tmp/krb5cc_495' not found))
> [04/Mar/2014:20:00:19 +0000] - slapd started.  Listening on All 
> Interfaces port 389 for LDAP requests
> [04/Mar/2014:20:00:19 +0000] - Listening on All Interfaces port 636 
> for LDAPS requests
> [04/Mar/2014:20:00:19 +0000] - Listening on 
> /var/run/slapd-DEV-VMONEY-LOCAL.socket for LDAPI requests
> [04/Mar/2014:20:00:22 +0000] NSMMReplicationPlugin - 
> agmt="cn=meTolvdlvldap01.unix.vmoney.local" (lvdlvldap01:389): 
> Replication bind with GSSAPI auth resumed
> The confusing point for me is that users were successfully added in 
> each direction before and after the failing "beaver" user.

I don't see anything obvious.  The GSSAPI errors are normal and transient.

Next, I would like to see the access logs from ipa01 and ipa02, showing 
both the operations associated with the failing "beaver" user, and 
operations for a successful user.

> Cheers
> Duncan
>
>     ------------------------------------------------------------------------
>     *From:* Rich Megginson [mailto:rmeggins at redhat.com]
>     *Sent:* 04 March 2014 22:41
>     *To:* Innes, Duncan; freeipa-users at redhat.com
>     *Subject:* Re: [Freeipa-users] Replication issue
>
>     On 03/04/2014 01:22 PM, Innes, Duncan wrote:
>>     Hi,
>>     I'm testing an upgrade of my prod IPA servers in a dev cluster at
>>     the moment.  Finally completed the upgrade, so I tested some user
>>     adds via the WebUI.
>>     Added user "aardvark" on ipa01 - replicated to ipa02
>>     Added user "beaver" on ipa02 - NOT replicated to ipa01
>>     Added user "banana" on ipa02 - replicated to ipa01
>>     Added user "elephant" on ipa02 - replicated to ipa01
>>     Edited user "beaver" on ipa02 - NOT replicated to ipa01
>
>     Is there anything in /var/log/dirsrv/slapd-DOMAIN-COM/errors on
>     ipa01 or ipa02?
>
>>     Is there anything I can do to force IPA to replicate that user
>>     from ipa02 to ipa01?
>>     I have tried running 'ipa-replica-manage force-sync --from ipa02'
>>     on ipa01, but it hasn't appeared to do anything.
>>     Thanks
>>
>>     Duncan
>>
>>     This message has been checked for viruses and spam by the Virgin
>>     Money email scanning system powered by Messagelabs.
>>
>>     This e-mail is intended to be confidential to the recipient. If
>>     you receive a copy in error, please inform the sender and then
>>     delete this message.
>>
>>     Virgin Money plc - Registered in England and Wales (Company no.
>>     6952311). Registered office - Jubilee House, Gosforth, Newcastle
>>     upon Tyne NE3 4PL. Virgin Money plc is authorised by the
>>     Prudential Regulation Authority and regulated by the Financial
>>     Conduct Authority and the Prudential Regulation Authority.
>>
>>     The following companies also trade as Virgin Money. They are both
>>     authorised and regulated by the Financial Conduct Authority, are
>>     registered in England and Wales and have their registered office
>>     at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin
>>     Money Personal Financial Service Limited (Company no. 3072766)
>>     and Virgin Money Unit Trust Managers Limited (Company no. 3000482).
>>
>>     For further details of Virgin Money group companies please visit
>>     our website at virginmoney.com
>>
>>
>>     _______________________________________________
>>     Freeipa-users mailing list
>>     Freeipa-users at redhat.com
>>     https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>     This message has been checked for viruses and spam by the Virgin
>     Money email scanning system powered by Messagelabs.
>
>
> This message has been checked for viruses and spam by the Virgin Money 
> email scanning system powered by Messagelabs.
>
> This e-mail is intended to be confidential to the recipient. If you 
> receive a copy in error, please inform the sender and then delete this 
> message.
>
> Virgin Money plc - Registered in England and Wales (Company no. 
> 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon 
> Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential 
> Regulation Authority and regulated by the Financial Conduct Authority 
> and the Prudential Regulation Authority.
>
> The following companies also trade as Virgin Money. They are both 
> authorised and regulated by the Financial Conduct Authority, are 
> registered in England and Wales and have their registered office at 
> Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money 
> Personal Financial Service Limited (Company no. 3072766) and Virgin 
> Money Unit Trust Managers Limited (Company no. 3000482).
>
> For further details of Virgin Money group companies please visit our 
> website at virginmoney.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140305/86862473/attachment.htm>

From Shaun.Mcadams at wellpoint.com  Wed Mar  5 14:55:21 2014
From: Shaun.Mcadams at wellpoint.com (Mcadams, Shaun)
Date: Wed, 5 Mar 2014 14:55:21 +0000
Subject: [Freeipa-users] Advice on hosting reset_password in jboss instance
Message-ID: <6696EC4DD514434D824E62988F5DB1C0033336B3@CO1PRD2802MB002.056d.mgd.msft.net>

We use ipa on our red hat boxes and have recently installed a SAS suite/servers for a contract.  Their users are a mix of internal/external associates.  Integrating with this ipa was straight-forward.  Their application is able to use pam, but their logon manager is limited as it does not support ids that have expired or need reset.  For security reason, some which are IDM UI related, we cannot expose the web app for those users to reset their passwords.  So investigating a little bit, we found a few options but I wanted to solicit any feedback for anyone who has been there done that.



We have the process working via the /ipa/session/change_password via a python script which we could form feed.  At the same time I see that there is already a reset_password form, javascript created.  So I don't know that this is even necessary.  However, I have found that hosting those in a web server isn't working and one person believes that could be related to the wrong ldap hostname.



Anyway just wanted to see if anyone has faced this before. Thanks.



Shaun McAdams
National Government Services
Health IT : CPI-Predictive Modeling
(o) - 317.595.4905 / x2004905
(c) - 317.430.9845



CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information or otherwise be protected by law. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140305/6d609755/attachment.htm>

From abokovoy at redhat.com  Wed Mar  5 15:15:20 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Wed, 5 Mar 2014 17:15:20 +0200
Subject: [Freeipa-users] Advice on hosting reset_password in jboss
 instance
In-Reply-To: <6696EC4DD514434D824E62988F5DB1C0033336B3@CO1PRD2802MB002.056d.mgd.msft.net>
References: <6696EC4DD514434D824E62988F5DB1C0033336B3@CO1PRD2802MB002.056d.mgd.msft.net>
Message-ID: <20140305151520.GI16644@redhat.com>

On Wed, 05 Mar 2014, Mcadams, Shaun wrote:
>We use ipa on our red hat boxes and have recently installed a SAS
>suite/servers for a contract.  Their users are a mix of
>internal/external associates.  Integrating with this ipa was
>straight-forward.  Their application is able to use pam, but their
>logon manager is limited as it does not support ids that have expired
>or need reset.  For security reason, some which are IDM UI related, we
>cannot expose the web app for those users to reset their passwords.  So
>investigating a little bit, we found a few options but I wanted to
>solicit any feedback for anyone who has been there done that.
>
>
>
>We have the process working via the /ipa/session/change_password via a
>python script which we could form feed.  At the same time I see that
>there is already a reset_password form, javascript created.  So I don't
>know that this is even necessary.  However, I have found that hosting
>those in a web server isn't working and one person believes that could
>be related to the wrong ldap hostname.
>
>
>
>Anyway just wanted to see if anyone has faced this before. Thanks.
Remember that passwords are managed in LDAP and integrated with
Kerberos. This gives you few other options than what is described above:

- use kpasswd to perform password change directly against KDC
   +: can be scripted easily
   +: requires no setup additional privileges in IPA
   -: cannot be used when password is forgotten

- use LDAP password change operation, through ldappasswd
   +: can be scripted easily
   +: requires no setup with additional privileges
   -: cannot be used when password is forgotten

For cases, when password is forgotten, admin has to reset user's
password through
   ipa passwd <user>
command line interface and then user can use any of the above to change
password.

All options above are scriptable since all tools accept passwords over
standard input or through a file.

If you want to build web application to reset passwords, then you need
to understand how conditional delegation works in IPA. As your
application works on user's behalf against IPA with Kerberos
credentials, it needs to be explicitly allowed to delegate user's
credentials. For doing that read my article at
https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html

-- 
/ Alexander Bokovoy



From rcritten at redhat.com  Wed Mar  5 15:35:00 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Wed, 05 Mar 2014 10:35:00 -0500
Subject: [Freeipa-users] Cert auto-renew probem.
In-Reply-To: <53150DC3.10903@redhat.com>
References: <1564912029.6544592.1393854654906.JavaMail.zimbra@lafayette.edu>
	<53150DC3.10903@redhat.com>
Message-ID: <53174424.4060408@redhat.com>

Dmitri Pal wrote:
> On 03/03/2014 08:50 AM, Lager, Nathan T. wrote:
>> Today i found that i was unable to authenticate to FreeIPA.
>>
>> I logged into my IPA master, and found that the cert had expired.
>> Which has never been a problem in the past.
>>
>> I did some googling, and found a few others with similar problems. but
>> none quite matched the issue i'm seeing.
>>
>> The issue is this:
>> [root at caroline0 PROD ~]# ipa-getcert list
>> Number of certificates and requests being tracked: 8.
>> Request ID '20120203213023':
>>     status: CA_UNREACHABLE
>>     ca-error: Server failed request, will retry: -504 (libcurl failed
>> to execute the HTTP POST transaction.  Peer certificate cannot be
>> authenticated with known CA certificates).
>>     stuck: yes
>>     key pair storage:
>> type=NSSDB,location='/etc/dirsrv/slapd-SYSTEMS-LAFAYETTE-EDU',nickname='Server-Cert',token='NSS
>> Certificate
>> DB',pinfile='/etc/dirsrv/slapd-SYSTEMS-LAFAYETTE-EDU//pwdfile.txt'
>>     certificate:
>> type=NSSDB,location='/etc/dirsrv/slapd-SYSTEMS-LAFAYETTE-EDU',nickname='Server-Cert',token='NSS
>> Certificate DB'
>>     CA: IPA
>>     issuer: CN=Certificate Authority,O=SYSTEMS.LAFAYETTE.EDU
>>     subject: CN=caroline0.lafayette.edu,O=SYSTEMS.LAFAYETTE.EDU
>>     expires: 2014-02-03 21:30:22 UTC
>>     eku: id-kp-serverAuth,id-kp-clientAuth
>>     pre-save command:
>>     post-save command:
>>     track: yes
>>     auto-renew: yes
>> Request ID '20120203213048':
>>     status: CA_UNREACHABLE
>>     ca-error: Server failed request, will retry: -504 (libcurl failed
>> to execute the HTTP POST transaction.  Peer certificate cannot be
>> authenticated with known CA certificates).
>>     stuck: yes
>>     key pair storage:
>> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
>> Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'
>>     certificate:
>> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
>> Certificate DB'
>>     CA: IPA
>>     issuer: CN=Certificate Authority,O=SYSTEMS.LAFAYETTE.EDU
>>     subject: CN=caroline0.lafayette.edu,O=SYSTEMS.LAFAYETTE.EDU
>>     expires: 2014-02-03 21:30:47 UTC
>>     eku: id-kp-serverAuth,id-kp-clientAuth
>>     pre-save command:
>>     post-save command:
>>     track: yes
>>     auto-renew: yes
>> Request ID '20120203213112':
>>     status: CA_UNREACHABLE
>>     ca-error: Server failed request, will retry: -504 (libcurl failed
>> to execute the HTTP POST transaction.  Peer certificate cannot be
>> authenticated with known CA certificates).
>>     stuck: yes
>>     key pair storage:
>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>>     certificate:
>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
>> Certificate DB'
>>     CA: IPA
>>     issuer: CN=Certificate Authority,O=SYSTEMS.LAFAYETTE.EDU
>>     subject: CN=caroline0.lafayette.edu,O=SYSTEMS.LAFAYETTE.EDU
>>     expires: 2014-02-03 21:31:11 UTC
>>     eku: id-kp-serverAuth,id-kp-clientAuth
>>     pre-save command:
>>     post-save command:
>>     track: yes
>>     auto-renew: yes
>>
>> Now, if i understand FreeIPA, the CA is FreeIPA itself, isnt it?  If
>> so, how could it be unreachable?
>>
>> What else might I be able to try to get past this?
>>
>> Thanks!
>>
>>
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
> Seems like your certificates have expired.
> The best would be to set the time back and restart the services
> everything should come up again.
> There have been some bugs with the cert rotation and restart.
> I suggest you check the mail threads regarding making sure that you have
> the fixed version and that certificates are rotated.
> Sorry for the situation.
>

I think Dmitri is right. To expand on this, if you use getcert rather 
than ipa-getcert you'll see all the certificates tracked by certmonger, 
specifically those of the CA itself. This will give you a better picture 
of what is going on.

rob



From Shaun.Mcadams at wellpoint.com  Wed Mar  5 15:34:50 2014
From: Shaun.Mcadams at wellpoint.com (Mcadams, Shaun)
Date: Wed, 5 Mar 2014 15:34:50 +0000
Subject: [Freeipa-users] Advice on hosting reset_password in jboss
 instance
In-Reply-To: <20140305151520.GI16644@redhat.com>
References: <6696EC4DD514434D824E62988F5DB1C0033336B3@CO1PRD2802MB002.056d.mgd.msft.net>
	<20140305151520.GI16644@redhat.com>
Message-ID: <6696EC4DD514434D824E62988F5DB1C0033337AF@CO1PRD2802MB002.056d.mgd.msft.net>

Thanks you sir!

Shaun McAdams
National Government Services
Health IT : CPI-Predictive Modeling 
(o) - 317.595.4905 / x2004905
(c) - 317.430.9845


-----Original Message-----
From: Alexander Bokovoy [mailto:abokovoy at redhat.com] 
Sent: Wednesday, March 05, 2014 10:15 AM
To: Mcadams, Shaun
Cc: freeipa-users at redhat.com; Xue, Xinjian
Subject: Re: [Freeipa-users] Advice on hosting reset_password in jboss instance

On Wed, 05 Mar 2014, Mcadams, Shaun wrote:
>We use ipa on our red hat boxes and have recently installed a SAS 
>suite/servers for a contract.  Their users are a mix of 
>internal/external associates.  Integrating with this ipa was 
>straight-forward.  Their application is able to use pam, but their 
>logon manager is limited as it does not support ids that have expired 
>or need reset.  For security reason, some which are IDM UI related, we 
>cannot expose the web app for those users to reset their passwords.  So 
>investigating a little bit, we found a few options but I wanted to 
>solicit any feedback for anyone who has been there done that.
>
>
>
>We have the process working via the /ipa/session/change_password via a 
>python script which we could form feed.  At the same time I see that 
>there is already a reset_password form, javascript created.  So I don't 
>know that this is even necessary.  However, I have found that hosting 
>those in a web server isn't working and one person believes that could 
>be related to the wrong ldap hostname.
>
>
>
>Anyway just wanted to see if anyone has faced this before. Thanks.
Remember that passwords are managed in LDAP and integrated with Kerberos. This gives you few other options than what is described above:

- use kpasswd to perform password change directly against KDC
   +: can be scripted easily
   +: requires no setup additional privileges in IPA
   -: cannot be used when password is forgotten

- use LDAP password change operation, through ldappasswd
   +: can be scripted easily
   +: requires no setup with additional privileges
   -: cannot be used when password is forgotten

For cases, when password is forgotten, admin has to reset user's password through
   ipa passwd <user>
command line interface and then user can use any of the above to change password.

All options above are scriptable since all tools accept passwords over standard input or through a file.

If you want to build web application to reset passwords, then you need to understand how conditional delegation works in IPA. As your application works on user's behalf against IPA with Kerberos credentials, it needs to be explicitly allowed to delegate user's credentials. For doing that read my article at https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html

--
/ Alexander Bokovoy


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information or otherwise be protected by law. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message.






From mareynol at redhat.com  Wed Mar  5 19:57:42 2014
From: mareynol at redhat.com (Mark Reynolds)
Date: Wed, 05 Mar 2014 14:57:42 -0500
Subject: [Freeipa-users] Replication issue
In-Reply-To: <56343345B145C043AE990701E3D193950478DAF2@EXVS2.nrplc.localnet>
References: <56343345B145C043AE990701E3D193950478DAF2@EXVS2.nrplc.localnet>
Message-ID: <531781B6.3050900@redhat.com>


On 03/04/2014 03:22 PM, Innes, Duncan wrote:
> Hi,
> I'm testing an upgrade of my prod IPA servers in a dev cluster at the 
> moment.  Finally completed the upgrade, so I tested some user adds via 
> the WebUI.
> Added user "aardvark" on ipa01 - replicated to ipa02
> Added user "beaver" on ipa02 - NOT replicated to ipa01
> Added user "banana" on ipa02 - replicated to ipa01
> Added user "elephant" on ipa02 - replicated to ipa01
> Edited user "beaver" on ipa02 - NOT replicated to ipa01
> Is there anything I can do to force IPA to replicate that user from 
> ipa02 to ipa01?
   If you turn on replication error logging it would provide more 
detailswhen these updates fail. What if you try to delete "beaver" and 
re-add it on ipa02, does it still not replicate?
> I have tried running 'ipa-replica-manage force-sync --from ipa02' on 
> ipa01, but it hasn't appeared to do anything.
> Thanks
>
> Duncan
>
> This message has been checked for viruses and spam by the Virgin Money 
> email scanning system powered by Messagelabs.
>
> This e-mail is intended to be confidential to the recipient. If you 
> receive a copy in error, please inform the sender and then delete this 
> message.
>
> Virgin Money plc - Registered in England and Wales (Company no. 
> 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon 
> Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential 
> Regulation Authority and regulated by the Financial Conduct Authority 
> and the Prudential Regulation Authority.
>
> The following companies also trade as Virgin Money. They are both 
> authorised and regulated by the Financial Conduct Authority, are 
> registered in England and Wales and have their registered office at 
> Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money 
> Personal Financial Service Limited (Company no. 3072766) and Virgin 
> Money Unit Trust Managers Limited (Company no. 3000482).
>
> For further details of Virgin Money group companies please visit our 
> website at virginmoney.com
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-- 
Mark Reynolds
389 Development Team
Red Hat, Inc
mreynolds at redhat.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140305/94753b7a/attachment.htm>

From treydock at gmail.com  Wed Mar  5 23:22:39 2014
From: treydock at gmail.com (Trey Dockendorf)
Date: Wed, 5 Mar 2014 17:22:39 -0600
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <53152C7C.9070304@redhat.com>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
Message-ID: <CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>

On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal <dpal at redhat.com> wrote:
> On 03/03/2014 07:47 PM, Simo Sorce wrote:
>>
>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
>>>
>>> Is it possible with FreeIPA to use an external KDC or pass some or all
>>> authentication to an external KDC?  The KDC at our University may give
>>> me a one way trust if I describe my implementation plan for FreeIPA.
>>> Currently I use 389DS with PAM pass through using untrusted pam_krb5.
>>> I'd like to fully utilize FreeIPA without managing passwords since all
>>> my users already have University accounts.  I just want to manage
>>> authorization for my systems, not authentication.
>>
>> You could set up a kerberos trust manually but at the moment we do not
>> support it in the code or the utilities.
>>
>> SSSD in particular will have no place to find identity information if
>> all you have is a kerberos trust, you'd need also an external identity
>> store to point to, but there is no builtin code in SSSD to link the 2
>> domain at this point.
>>
>> We are planning on working on IPA-to-IPA trust, and possibly
>> IPA-to-*other* so any requirements you can throw at us will be made part
>> of the consideration and planning to add this kind of functionality in
>> the future.
>>
>> NM B HTH,
>> Simo.
>>
> Can you describe your workflows because I have some idea in mind?

Right now the workflow I have with 389ds using PAM Pass Through Auth
is the following:

For users with the proper attribute defined in 'pamIDAttr'

client ---> 389DS ---> 389DS server's pam_krb5 ---> Campus KDC

For users lacking the attribute for 'pamIDAttr'

client ---> 389DS

The Kerberos setup currently on the 389DS server is untrusted (no krb5.keytab).

The ideal workflow with FreeIPA would be

client ----> IPA ---> Campus KDC

> Would you be OK if your accounts would be in IPA but the authentication
> would be proxied out?

This is fine with me.  Does the idea you describe allow for some
authentication (ie system accounts or internal accounts) to be handled
by FreeIPA?  That's the benefit to us when using PAM Pass Through
Auth, is that we can conditionally proxy out the authentication.

>
> The idea is that you can use OTP RADIUS capability to proxy passwords to
> your main KDC.
>
> client ---OTP---> IPA ---> OTP Proxy ---> RADIUS ---> Your KDC
>
> Disclaimer: that would defeat the purpose of Kerberos and the password will
> be sent over the wire but it seems that you are already in this setup.
>
> Would you be interested to give it a try?

Absolutely.  Right now I need to contact our campus IT group and let
them know what I require to make our setup work.  I have been told a
one way trust is the most I can get.  Will that facilitate what you
described?

> Would require latest SSSD and kerberos library on the client though but
> would work with LDAP binds too.

Latest SSSD and Kerberos that's available in EL6, or latest upstream?

>
>
> --
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users



From treydock at gmail.com  Wed Mar  5 23:24:09 2014
From: treydock at gmail.com (Trey Dockendorf)
Date: Wed, 5 Mar 2014 17:24:09 -0600
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
Message-ID: <CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>

Correction from my email, the condition that sets if a 389DS user is
proxied to pam_krb5 is the "pamFilter", sorry.

On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorf <treydock at gmail.com> wrote:
> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal <dpal at redhat.com> wrote:
>> On 03/03/2014 07:47 PM, Simo Sorce wrote:
>>>
>>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
>>>>
>>>> Is it possible with FreeIPA to use an external KDC or pass some or all
>>>> authentication to an external KDC?  The KDC at our University may give
>>>> me a one way trust if I describe my implementation plan for FreeIPA.
>>>> Currently I use 389DS with PAM pass through using untrusted pam_krb5.
>>>> I'd like to fully utilize FreeIPA without managing passwords since all
>>>> my users already have University accounts.  I just want to manage
>>>> authorization for my systems, not authentication.
>>>
>>> You could set up a kerberos trust manually but at the moment we do not
>>> support it in the code or the utilities.
>>>
>>> SSSD in particular will have no place to find identity information if
>>> all you have is a kerberos trust, you'd need also an external identity
>>> store to point to, but there is no builtin code in SSSD to link the 2
>>> domain at this point.
>>>
>>> We are planning on working on IPA-to-IPA trust, and possibly
>>> IPA-to-*other* so any requirements you can throw at us will be made part
>>> of the consideration and planning to add this kind of functionality in
>>> the future.
>>>
>>> NM B HTH,
>>> Simo.
>>>
>> Can you describe your workflows because I have some idea in mind?
>
> Right now the workflow I have with 389ds using PAM Pass Through Auth
> is the following:
>
> For users with the proper attribute defined in 'pamIDAttr'
>
> client ---> 389DS ---> 389DS server's pam_krb5 ---> Campus KDC
>
> For users lacking the attribute for 'pamIDAttr'
>
> client ---> 389DS
>
> The Kerberos setup currently on the 389DS server is untrusted (no krb5.keytab).
>
> The ideal workflow with FreeIPA would be
>
> client ----> IPA ---> Campus KDC
>
>> Would you be OK if your accounts would be in IPA but the authentication
>> would be proxied out?
>
> This is fine with me.  Does the idea you describe allow for some
> authentication (ie system accounts or internal accounts) to be handled
> by FreeIPA?  That's the benefit to us when using PAM Pass Through
> Auth, is that we can conditionally proxy out the authentication.
>
>>
>> The idea is that you can use OTP RADIUS capability to proxy passwords to
>> your main KDC.
>>
>> client ---OTP---> IPA ---> OTP Proxy ---> RADIUS ---> Your KDC
>>
>> Disclaimer: that would defeat the purpose of Kerberos and the password will
>> be sent over the wire but it seems that you are already in this setup.
>>
>> Would you be interested to give it a try?
>
> Absolutely.  Right now I need to contact our campus IT group and let
> them know what I require to make our setup work.  I have been told a
> one way trust is the most I can get.  Will that facilitate what you
> described?
>
>> Would require latest SSSD and kerberos library on the client though but
>> would work with LDAP binds too.
>
> Latest SSSD and Kerberos that's available in EL6, or latest upstream?
>
>>
>>
>> --
>> 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users



From rstory at tislabs.com  Thu Mar  6 04:42:58 2014
From: rstory at tislabs.com (Robert Story)
Date: Wed, 5 Mar 2014 23:42:58 -0500
Subject: [Freeipa-users] install with external CA failed
Message-ID: <20140305234258.1641247f@ispx.vb.futz.org>

Hi,

I'm trying to install on CentOS 6.5 (ipa-server-3.0.0-37.el6.x86_64) and an
external CA. I'm getting this error:

Command '/usr/bin/sslget -v -n ipa-ca-agent -p XXXXXXXX -d /tmp/tmp-jNYt3P -r /ca/agent/ca/profileReview?requestId=6 auth.lan:9443' returned non-zero exit status 4

I found a thread from back in 2012 with exact same symptoms:

  https://www.redhat.com/archives/freeipa-users/2012-May/msg00357.html

Unfortunately, the thread died out without any resolution/fix. When I run
the suggested commands from that thread, I get the same results the OP did..

#certutil -L -d /tmp/tmp-jNYt3P/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

ipa-ca-agent                                                 u,u,u
Certificate Authority - xxx                   CT,C,C
testnick                                                     P,,  
xxx Certificate Authority - xxx            CT,C,C

# certutil -V -u C -n ipa-ca-agent -d /tmp/tmp-jNYt3P/
certutil: certificate is invalid: Issuer certificate is invalid.

# certutil -L -n ipa-ca-agent -d /tmp/tmp-jNYt3P/
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 5 (0x5)
        Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
        Issuer: "CN=Certificate Authority,O=xxx"
        Validity:
            Not Before: Thu Mar 06 04:17:13 2014
            Not After : Wed Feb 24 04:17:13 2016
        Subject: "CN=ipa-ca-agent,O=xxx"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    bf:0c:5b:f0:14:9e:0f:26:91:21:66:62:95:0c:4d:04:
                    e5:ec:96:6f:a1:3b:a8:05:de:1b:40:a7:7c:59:55:c4:
                    1e:a0:62:3d:7a:50:e8:c4:8b:d7:5d:cd:55:b2:e7:f9:
                    63:f6:43:75:1e:3d:3c:ac:51:a4:81:94:6b:e5:7f:94:
                    d7:b2:aa:8d:e8:b6:50:f2:24:96:76:8d:5f:e9:aa:43:
                    07:97:c8:06:2e:dc:22:9b:d1:2e:90:24:d8:07:94:33:
                    d1:0f:44:e5:14:37:3c:96:ee:24:e0:07:91:f1:ee:c8:
                    c4:01:e9:85:d8:35:eb:42:92:8a:58:c3:ae:e8:7d:27:
                    4d:2d:cb:b8:97:0b:5d:e0:3c:99:8a:a8:a2:b7:e2:10:
                    61:2b:77:33:87:ea:59:16:87:f7:f7:43:cf:c2:7b:60:
                    3a:fc:44:2f:9e:9c:56:bc:99:0c:d0:e9:08:d6:db:f5:
                    b1:d2:5e:28:45:d2:8f:71:1d:49:e9:41:c6:d2:e0:03:
                    ac:85:ea:51:c6:17:5d:ed:eb:a5:11:86:40:37:cf:49:
                    d3:cc:11:f1:3f:17:61:38:52:fa:12:a6:a0:bf:61:74:
                    aa:3e:87:bd:ff:d1:eb:d7:c5:d7:d5:90:8f:d6:d6:e1:
                    ab:d0:1f:db:91:8e:ff:d1:52:e3:6a:7a:fe:20:b3:53
                Exponent: 65537 (0x10001)
        Signed Extensions:
            Name: Certificate Authority Key Identifier
            Key ID:
                b5:5e:45:9f:e9:71:c5:11:a2:6c:6c:06:00:be:02:ad:
                8e:ae:76:1b

            Name: Authority Information Access
            Method: PKIX Online Certificate Status Protocol
            Location: 
                URI: "http://auth.lan:80/ca/ocsp"

            Name: Certificate Key Usage
            Critical: True
            Usages: Digital Signature
                    Non-Repudiation
                    Key Encipherment
                    Data Encipherment

            Name: Extended Key Usage
                TLS Web Client Authentication Certificate
                E-Mail Protection Certificate

    Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
    Signature:
        91:e8:3c:26:1e:e6:24:35:64:95:92:10:79:9b:c3:3f:
        3d:6c:7b:db:56:bd:98:85:31:4a:2c:6c:1f:76:e4:74:
        8a:90:49:43:6d:16:63:f9:cc:9b:89:bd:bc:5c:fa:3b:
        55:9e:a8:54:ce:61:fa:62:61:cf:b5:47:54:e5:70:f6:
        d0:a0:a6:56:bf:1e:19:4d:f3:95:8a:70:1f:43:c2:6b:
        85:bf:dd:90:6a:13:f7:58:9d:b2:40:88:d6:3a:d1:84:
        2e:7f:b8:b8:e1:f9:5f:83:c5:d4:55:c4:a7:1a:28:a4:
        64:fc:ac:78:3b:43:a0:00:78:db:f1:cc:a6:b6:11:70:
        64:2f:43:d2:74:a5:2a:50:91:e0:8d:8c:82:c5:1a:5c:
        dd:00:60:62:55:be:0a:ea:b9:75:0f:8d:0e:40:cd:26:
        9c:63:08:3f:7d:79:c5:6b:73:fd:26:60:d3:e4:59:1e:
        1d:0f:82:ea:eb:23:b3:b4:59:7f:a9:87:e8:01:c7:aa:
        7b:c0:dd:0a:f0:4d:da:90:c9:57:00:4b:86:ea:58:22:
        ff:45:11:18:25:de:09:ee:a4:7a:4a:ea:8f:17:c9:ad:
        38:15:af:fa:c0:f3:fb:1c:6c:e1:69:1f:99:4e:fe:a2:
        eb:66:92:77:3a:5d:8f:7a:63:9b:14:ea:95:3e:c7:e9
    Fingerprint (MD5):
        96:68:7A:76:9F:06:78:BC:67:85:0C:82:A8:43:14:6B
    Fingerprint (SHA1):
        99:7D:9F:1B:F4:A7:52:9F:CF:BF:23:4F:5B:1A:90:22:19:14:37:16

    Certificate Trust Flags:
        SSL Flags:
            User
        Email Flags:
            User
        Object Signing Flags:
            User

... and so on...

Any suggestions from anyone who has gotten an external-ca install to work?


Robert

--
Senior Software Engineer @ Parsons
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140305/aef3a358/attachment.sig>

From bret.wortman at damascusgrp.com  Thu Mar  6 12:39:15 2014
From: bret.wortman at damascusgrp.com (Bret Wortman)
Date: Thu, 06 Mar 2014 07:39:15 -0500
Subject: [Freeipa-users] Password issues
Message-ID: <53186C73.6000701@damascusgrp.com>

Strange behavior now with our passwords (and we still haven't solved our 
problem with the "ipa" command, but at least with script, we have a 
workaround):

I noticed yesterday morning that my password, which has the following 
policy, was going to expire in 3 days so I changed it.

Max lifetime (days) : 0
Min lifetime (hours) : 0
History size (number of passwords): 0
Character classes: 2
Min length: 8
Max failures: 4
Failure reset interval (seconds): 60
Lockout duration (seconds): 60

The IPA web UI immediately began reporting in red that "Your password 
expires in -1 days."

This morning, I ran "kinit":

$ kinit
Password for bretw at DAMASCUSGRP.COM:
Password expired.  You must change it now.
Enter new password:
Enter it again:
Warning: Your password wille xpire in less than one hour on Thu 06 Mar 
2014 06:45:48 AM EST
$

What's up? I'd like to solve this before it bites any of my users, 
though most have a policy that looks more like this:

Max lifetime (days) : 180
Min lifetime (hours) : 1
History size (number of passwords): 0
Character classes: 2
Min length: 8
Max failures: 6
Failure reset interval (seconds): 60
Lockout duration (seconds): 600


-- 
*Bret Wortman*

http://damascusgrp.com/
http://about.me/wortmanbret

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/75d6a1b2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 51f7de33e4b08d2bdb8b4860
Type: image/png
Size: 28526 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/75d6a1b2/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/75d6a1b2/attachment.p7s>

From sbose at redhat.com  Thu Mar  6 12:55:36 2014
From: sbose at redhat.com (Sumit Bose)
Date: Thu, 6 Mar 2014 13:55:36 +0100
Subject: [Freeipa-users] Password issues
In-Reply-To: <53186C73.6000701@damascusgrp.com>
References: <53186C73.6000701@damascusgrp.com>
Message-ID: <20140306125536.GG3051@localhost.localdomain>

On Thu, Mar 06, 2014 at 07:39:15AM -0500, Bret Wortman wrote:
> Strange behavior now with our passwords (and we still haven't solved
> our problem with the "ipa" command, but at least with script, we
> have a workaround):
> 
> I noticed yesterday morning that my password, which has the
> following policy, was going to expire in 3 days so I changed it.
> 
> Max lifetime (days) : 0

I think the behaviour is expected with this maximal lifetime.

bye,
Sumit

> Min lifetime (hours) : 0
> History size (number of passwords): 0
> Character classes: 2
> Min length: 8
> Max failures: 4
> Failure reset interval (seconds): 60
> Lockout duration (seconds): 60
> 
> The IPA web UI immediately began reporting in red that "Your
> password expires in -1 days."
> 
> This morning, I ran "kinit":
> 
> $ kinit
> Password for bretw at DAMASCUSGRP.COM:
> Password expired.  You must change it now.
> Enter new password:
> Enter it again:
> Warning: Your password wille xpire in less than one hour on Thu 06
> Mar 2014 06:45:48 AM EST
> $
> 
> What's up? I'd like to solve this before it bites any of my users,
> though most have a policy that looks more like this:
> 
> Max lifetime (days) : 180
> Min lifetime (hours) : 1
> History size (number of passwords): 0
> Character classes: 2
> Min length: 8
> Max failures: 6
> Failure reset interval (seconds): 60
> Lockout duration (seconds): 600
> 
> 
> -- 
> *Bret Wortman*
> 
> http://damascusgrp.com/
> http://about.me/wortmanbret
> 



> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users



From bret.wortman at damascusgrp.com  Thu Mar  6 13:08:01 2014
From: bret.wortman at damascusgrp.com (Bret Wortman)
Date: Thu, 06 Mar 2014 08:08:01 -0500
Subject: [Freeipa-users] Password issues
In-Reply-To: <20140306125536.GG3051@localhost.localdomain>
References: <53186C73.6000701@damascusgrp.com>
	<20140306125536.GG3051@localhost.localdomain>
Message-ID: <53187331.8010207@damascusgrp.com>

Is there a way to set a password to not expire? I thought I read 
somewhere that 0 did that, but apparently not.

On 03/06/2014 07:55 AM, Sumit Bose wrote:
> On Thu, Mar 06, 2014 at 07:39:15AM -0500, Bret Wortman wrote:
>> Strange behavior now with our passwords (and we still haven't solved
>> our problem with the "ipa" command, but at least with script, we
>> have a workaround):
>>
>> I noticed yesterday morning that my password, which has the
>> following policy, was going to expire in 3 days so I changed it.
>>
>> Max lifetime (days) : 0
> I think the behaviour is expected with this maximal lifetime.
>
> bye,
> Sumit
>
>> Min lifetime (hours) : 0
>> History size (number of passwords): 0
>> Character classes: 2
>> Min length: 8
>> Max failures: 4
>> Failure reset interval (seconds): 60
>> Lockout duration (seconds): 60
>>
>> The IPA web UI immediately began reporting in red that "Your
>> password expires in -1 days."
>>
>> This morning, I ran "kinit":
>>
>> $ kinit
>> Password for bretw at DAMASCUSGRP.COM:
>> Password expired.  You must change it now.
>> Enter new password:
>> Enter it again:
>> Warning: Your password wille xpire in less than one hour on Thu 06
>> Mar 2014 06:45:48 AM EST
>> $
>>
>> What's up? I'd like to solve this before it bites any of my users,
>> though most have a policy that looks more like this:
>>
>> Max lifetime (days) : 180
>> Min lifetime (hours) : 1
>> History size (number of passwords): 0
>> Character classes: 2
>> Min length: 8
>> Max failures: 6
>> Failure reset interval (seconds): 60
>> Lockout duration (seconds): 600
>>
>>
>> -- 
>> *Bret Wortman*
>>
>> http://damascusgrp.com/
>> http://about.me/wortmanbret
>>
>
>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/1fd4d1e0/attachment.p7s>

From bret.wortman at damascusgrp.com  Thu Mar  6 13:10:07 2014
From: bret.wortman at damascusgrp.com (Bret Wortman)
Date: Thu, 06 Mar 2014 08:10:07 -0500
Subject: [Freeipa-users] Password issues
In-Reply-To: <53187331.8010207@damascusgrp.com>
References: <53186C73.6000701@damascusgrp.com>	<20140306125536.GG3051@localhost.localdomain>
	<53187331.8010207@damascusgrp.com>
Message-ID: <531873AF.2060803@damascusgrp.com>

Just found with some fresh Googling an email from Rob recommending 
setting the max to 5000. I'll try that.


On 03/06/2014 08:08 AM, Bret Wortman wrote:
> Is there a way to set a password to not expire? I thought I read 
> somewhere that 0 did that, but apparently not.
>
> On 03/06/2014 07:55 AM, Sumit Bose wrote:
>> On Thu, Mar 06, 2014 at 07:39:15AM -0500, Bret Wortman wrote:
>>> Strange behavior now with our passwords (and we still haven't solved
>>> our problem with the "ipa" command, but at least with script, we
>>> have a workaround):
>>>
>>> I noticed yesterday morning that my password, which has the
>>> following policy, was going to expire in 3 days so I changed it.
>>>
>>> Max lifetime (days) : 0
>> I think the behaviour is expected with this maximal lifetime.
>>
>> bye,
>> Sumit
>>
>>> Min lifetime (hours) : 0
>>> History size (number of passwords): 0
>>> Character classes: 2
>>> Min length: 8
>>> Max failures: 4
>>> Failure reset interval (seconds): 60
>>> Lockout duration (seconds): 60
>>>
>>> The IPA web UI immediately began reporting in red that "Your
>>> password expires in -1 days."
>>>
>>> This morning, I ran "kinit":
>>>
>>> $ kinit
>>> Password for bretw at DAMASCUSGRP.COM:
>>> Password expired.  You must change it now.
>>> Enter new password:
>>> Enter it again:
>>> Warning: Your password wille xpire in less than one hour on Thu 06
>>> Mar 2014 06:45:48 AM EST
>>> $
>>>
>>> What's up? I'd like to solve this before it bites any of my users,
>>> though most have a policy that looks more like this:
>>>
>>> Max lifetime (days) : 180
>>> Min lifetime (hours) : 1
>>> History size (number of passwords): 0
>>> Character classes: 2
>>> Min length: 8
>>> Max failures: 6
>>> Failure reset interval (seconds): 60
>>> Lockout duration (seconds): 600
>>>
>>>
>>> -- 
>>> *Bret Wortman*
>>>
>>> http://damascusgrp.com/
>>> http://about.me/wortmanbret
>>>
>>
>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/f5d53afe/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/f5d53afe/attachment.p7s>

From pspacek at redhat.com  Thu Mar  6 13:32:41 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Thu, 06 Mar 2014 14:32:41 +0100
Subject: [Freeipa-users] Propose FreeIPA theses for the next year
Message-ID: <531878F9.80400@redhat.com>

Hello,

now it is the right time to propose topics for theses in the next university year.

If you know about some interesting area or feature we don't have time to 
implement - propose it!

Current topics are listed on
https://thesis-managementsystem.rhcloud.com/topic/list?filter.categories.id=129

Please change e-mail subject for discussion about each topic and start 
sub-thread by replying to this message so it will be easy to follow only one 
thread or so.

-- 
Petr^2 Spacek



From pspacek at redhat.com  Thu Mar  6 15:55:50 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Thu, 06 Mar 2014 16:55:50 +0100
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <531878F9.80400@redhat.com>
References: <531878F9.80400@redhat.com>
Message-ID: <53189A86.7000707@redhat.com>

On 6.3.2014 14:32, Petr Spacek wrote:
> now it is the right time to propose topics for theses in the next university
> year.

I propose "[RFE] IPA should support and manage DNS sites"
https://fedorahosted.org/freeipa/ticket/2008

It is rotting in the backlog and we are not going to touch it any time soon.

There is very low amount of 'theory' behind it but IMHO it is complex enough:
- Some theoretical analysis of our proposal sounds like a good idea. We don't 
know if it is the best way or not.
- Some testing with various *real* non-SSSD clients will be helpful.
- Analysis how this can work with DNSSEC will be helpful.
- This feature needs API/CLI/UI design. It is not clear how the workflow 
should look like etc.
- Support for roaming clients (in bind-dyndb-ldap) is missing.

The scope can be changed as necessary.

-- 
Petr^2 Spacek



From antonio.lopez at ife.org.mx  Thu Mar  6 16:09:22 2014
From: antonio.lopez at ife.org.mx (Juan Antonio)
Date: Thu, 6 Mar 2014 10:09:22 -0600
Subject: [Freeipa-users] incompatibility Operative systems
Message-ID: <00c001cf3956$73093e30$591bba90$@ife.org.mx>

 

 

I have a conflict with a configuration of free-ipa.
The problem is an incompatibility between the client operating system with
fedora 19 and the ipa server with Red hat 6.4 operating system.
When executing the command: 

ipa add-service cifs/ipaserver.example.com

Generates the error:
ipa: ERROR: Unknown option: no_members

For this reason I would like to know if there is a specific configuration or
patch that solution problem.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/18a7d495/attachment.htm>

From sakodak at gmail.com  Thu Mar  6 16:48:47 2014
From: sakodak at gmail.com (KodaK)
Date: Thu, 6 Mar 2014 10:48:47 -0600
Subject: [Freeipa-users] scripting ipa commands
Message-ID: <CAA9J0ZGyQQz6+KrzTF9UZZ10DuMFr0Sg96kJA9jTqX3pk4ZiVg@mail.gmail.com>

Once again, I'm probably missing something that's well documented.  I
promise I searched.

We have a daily termination list that needs to be enforced at 5:00 PM every
day.  I can script it up just fine, but sometimes I like to sneak out early.

I tried to use "at," but since I'm logged out when the job runs there's no
ticket and the ipa commands fail.

ex:

echo "sh terminate" | at 5:00 PM Friday

works if I'm logged in with a ticket ("terminate" contains the ipa command
to disable / delete users.)

Is there some way to automate this?  I can leave a terminal open on a VM as
a work-around, but I'd like to be cleaner if I can.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/b4cc0c85/attachment.htm>

From JR.Aquino at citrix.com  Thu Mar  6 17:23:23 2014
From: JR.Aquino at citrix.com (JR Aquino)
Date: Thu, 6 Mar 2014 17:23:23 +0000
Subject: [Freeipa-users] scripting ipa commands
In-Reply-To: <CAA9J0ZGyQQz6+KrzTF9UZZ10DuMFr0Sg96kJA9jTqX3pk4ZiVg@mail.gmail.com>
References: <CAA9J0ZGyQQz6+KrzTF9UZZ10DuMFr0Sg96kJA9jTqX3pk4ZiVg@mail.gmail.com>
Message-ID: <32C917C8-487C-4F5B-9D7A-981DC3F67084@citrix.com>

If you don't find an answer for doing it -minus- a ticket, here is what I would suggest.

Create a service user who's only role permissions give them the ability to delete users.

Then perform a getkeytab for the user:
ipa-getkeytab -s ipa.example.com -p <user name to export>@EXAMPLE.COM -k /path/to/username.keytab

Then associate the following along with your cron.  I would also recommend a kdestroy -after- the task is run.
#!/bin/bash

#######
# Auto Kinit
########

/usr/kerberos/bin/klist -s
EXITCODE=$?
if [ $EXITCODE != "0" ] ; then
        /usr/kerberos/bin/kdestroy >> /dev/null 2>&1
        /usr/kerberos/bin/kinit -F username at EXAMPLE.COM -k -t /path/to/username.keytab
fi


On Mar 6, 2014, at 8:48 AM, KodaK <sakodak at gmail.com> wrote:

> Once again, I'm probably missing something that's well documented.  I promise I searched.
> 
> We have a daily termination list that needs to be enforced at 5:00 PM every day.  I can script it up just fine, but sometimes I like to sneak out early.
> 
> I tried to use "at," but since I'm logged out when the job runs there's no ticket and the ipa commands fail.
> 
> ex:
> 
> echo "sh terminate" | at 5:00 PM Friday
> 
> works if I'm logged in with a ticket ("terminate" contains the ipa command to disable / delete users.)
> 
> Is there some way to automate this?  I can leave a terminal open on a VM as a work-around, but I'd like to be cleaner if I can.
> 
> --Jason
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/5cb2e983/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/5cb2e983/attachment.sig>

From sakodak at gmail.com  Thu Mar  6 18:58:09 2014
From: sakodak at gmail.com (KodaK)
Date: Thu, 6 Mar 2014 12:58:09 -0600
Subject: [Freeipa-users] scripting ipa commands [solved]
Message-ID: <CAA9J0ZHmWYoOA5ZGQXi1fr4P3Jtz_onQN1HfvFDEXX-fiVo=XA@mail.gmail.com>

That's pretty much exactly what I was looking for.

Thanks JR.

--Jason


On Thu, Mar 6, 2014 at 11:23 AM, JR Aquino <JR.Aquino at citrix.com> wrote:

> If you don't find an answer for doing it -minus- a ticket, here is what I
> would suggest.
>
> Create a service user who's only role permissions give them the ability to
> delete users.
>
> Then perform a getkeytab for the user:
> ipa-getkeytab -s ipa.example.com -p <user name to export>@EXAMPLE.COM -k
> /path/to/username.keytab
>
> Then associate the following along with your cron.  I would also recommend
> a kdestroy -after- the task is run.
>
> #!/bin/bash
>
> #######
> # Auto Kinit
> ########
>
> /usr/kerberos/bin/klist -s
> EXITCODE=$?
> if [ $EXITCODE != "0" ] ; then
>         /usr/kerberos/bin/kdestroy >> /dev/null 2>&1
>         /usr/kerberos/bin/kinit -F username at EXAMPLE.COM -k -t /path/to/username.keytab
> fi
>
>
>
> On Mar 6, 2014, at 8:48 AM, KodaK <sakodak at gmail.com> wrote:
>
> Once again, I'm probably missing something that's well documented.  I
> promise I searched.
>
> We have a daily termination list that needs to be enforced at 5:00 PM
> every day.  I can script it up just fine, but sometimes I like to sneak out
> early.
>
> I tried to use "at," but since I'm logged out when the job runs there's no
> ticket and the ipa commands fail.
>
> ex:
>
> echo "sh terminate" | at 5:00 PM Friday
>
> works if I'm logged in with a ticket ("terminate" contains the ipa command
> to disable / delete users.)
>
> Is there some way to automate this?  I can leave a terminal open on a VM
> as a work-around, but I'd like to be cleaner if I can.
>
> --Jason
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>


-- 
The government is going to read our mail anyway, might as well make it
tough for them.  GPG Public key ID:  B6A1A7C6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/745303c0/attachment.htm>

From devel at jasonwoods.me.uk  Thu Mar  6 21:25:44 2014
From: devel at jasonwoods.me.uk (Jason Woods)
Date: Thu, 6 Mar 2014 21:25:44 +0000
Subject: [Freeipa-users] Patch for ipa-sam: ipa-server-trust-ad samba server
	valid users =@groupname
Message-ID: <2EF3F569-081B-46EB-9188-FB7349450479@jasonwoods.me.uk>

Hi all,

I am quite aware that installing ipa-server-trust-ad and using the samba as a file server is as unsupported as one can get... but I really needed a Samba server integrated with IPA (damn Mac OS and Windows). I don't actually have a Windows environment but this seemed to bootstrap enough of the requirements to get it working

Bit of a story for those who have time to read and maybe battling similiar, or just skip to after the log for the fix+patch :)
* ipaNTSecurityIdentifier ended up missing because I didn't use --setsid and NT hash missing because I did not do a ipa passwd reset
* As a result, experienced user not found or invalid password, and after debug level 5 I had about 500M of core dumps (sorry don't have them anymore)
* Ran ipa-adtrust-install again with --setsid and reset some passwords and things started looking better, could connect, all good, NT hash was there and ipaNTSecurityIdentifier there (ldapsearch <3)
* Then next problem was when I added "valid users = @groupname" to share config. No longer could connect even if member of the group!
* Turned out ipNTGroupAttr was missing from some groups - thus had to register the ldif for the ipa-setsid task

Still had problems even after ipa-setsid, and ldapsearch showed all correct.
Here is a snippet from the logs at debug level 10.

> [2014/03/06 15:32:55.658567,  4, pid=28139, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:316(set_sec_ctx)
>   setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
> [2014/03/06 15:32:55.658601,  5, pid=28139, effective(0, 0), real(0, 0)] ../libcli/security/security_token.c:53(security_token_debug)
>   Security token: (NULL)
> [2014/03/06 15:32:55.658634,  5, pid=28139, effective(0, 0), real(0, 0)] ../source3/auth/token_util.c:528(debug_unix_user_token)
>   UNIX token of user 0
>   Primary group is 0 and contains 0 supplementary groups
> [2014/03/06 15:32:55.658691,  5, pid=28139, effective(0, 0), real(0, 0)] ../source3/lib/smbldap.c:1249(smbldap_search_ext)
>   smbldap_search_ext: base => [dc=local,dc=othermedia,dc=com], filter => [(&(ipaNTSecurityIdentifier=S-1-5-21-2563482189-1697247676-1628377611-1005)(|(objectClass=ipaNTGroupAttrs)(objectClass=ipaNTUserAttrs)))], scope => [2]
> [2014/03/06 15:32:55.659599, 10, pid=28139, effective(0, 0), real(0, 0)] ipa_sam.c:309(get_single_attribute)
>   Attribute [uidNumber] not found.
> [2014/03/06 15:32:55.659667,  1, pid=28139, effective(0, 0), real(0, 0)] ipa_sam.c:717(ldapsam_sid_to_id)
>   Could not find uidNumber in cn=filestore_archive,cn=groups,cn=accounts,dc=local,dc=othermedia,dc=com
> [2014/03/06 15:32:55.659716,  4, pid=28139, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:424(pop_sec_ctx)
>   pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
> [2014/03/06 15:32:55.659758, 10, pid=28139, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:1121(legacy_sid_to_unixid)
>   LEGACY: mapping failed for sid S-1-5-21-2563482189-1697247676-1628377611-1005
> [2014/03/06 15:32:55.659796,  4, pid=28139, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:216(push_sec_ctx)
>   push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1


I noticed the "Could not find uidNumber" - turns out ipa-sam was being asked to turn SID into ID and was successfully finding it but needed to work out whether it was a group or a user. To do this, it searches the objectClass for "ipNTGroupAttr" - if it finds it, it looks for gidNumber, otherwise it looks for uidNumber. However, the objectClass added by ipa-setsid is "ipntgroupattr" and ipa-sam was using "strncmp".

I've fixed this with a patch to use strncasecmp. Might not be the best fix... maybe ipa-sam should be modified to have the attributes lower case for comparison? But this was simplest patch. Comments/feedback welcome and maybe I'll have time to do alternative fix if felt better?

Versions:
RHEL 6.4 3.0.0-37
Code in master branch appears to show the same issue

References:
freeipa/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen.h
around line 54-55: lowercase objectClass addition
freeipa/daemons/ipa-sam/ipa_sam.c
around line 688: case sensitive comparison to ipaNTGroupAttrs

Patch for master branch:
diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c
index 1ca504d..c5e8b39 100644
--- a/daemons/ipa-sam/ipa_sam.c
+++ b/daemons/ipa-sam/ipa_sam.c
@@ -750,7 +750,7 @@ static bool ldapsam_sid_to_id(struct pdb_methods *methods,
 	}
 
 	for (c = 0; values[c] != NULL; c++) {
-		if (strncmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val,
+		if (strncasecmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val,
 			                       values[c]->bv_len) == 0) {
 			break;
 		}

Patch for RHEL 6.5 3.0.0-37:
--- a/daemons/ipa-sam/ipa_sam.c	2014-03-06 19:30:15.994792879 +0000
+++ b/daemons/ipa-sam/ipa_sam.c	2014-03-06 19:35:34.966791637 +0000
@@ -685,7 +685,7 @@
 	}

 	for (c = 0; values[c] != NULL; c++) {
-		if (strncmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val,
+		if (strncasecmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val,
 			                       values[c]->bv_len) == 0) {
 			break;
 		}

Regards,

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/6150fc58/attachment.htm>

From abokovoy at redhat.com  Thu Mar  6 22:06:15 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Fri, 7 Mar 2014 00:06:15 +0200
Subject: [Freeipa-users] Patch for ipa-sam: ipa-server-trust-ad samba
 server valid users =@groupname
In-Reply-To: <2EF3F569-081B-46EB-9188-FB7349450479@jasonwoods.me.uk>
References: <2EF3F569-081B-46EB-9188-FB7349450479@jasonwoods.me.uk>
Message-ID: <20140306220615.GQ16644@redhat.com>

On Thu, 06 Mar 2014, Jason Woods wrote:
>Hi all,
>
>I am quite aware that installing ipa-server-trust-ad and using the
>samba as a file server is as unsupported as one can get... but I really
>needed a Samba server integrated with IPA (damn Mac OS and Windows). I
>don't actually have a Windows environment but this seemed to bootstrap
>enough of the requirements to get it working
>
>Bit of a story for those who have time to read and maybe battling
>similiar, or just skip to after the log for the fix+patch :)
>* ipaNTSecurityIdentifier ended up missing because I didn't use
>--setsid and NT hash missing because I did not do a ipa passwd reset
>* As a result, experienced user not found or invalid password, and
>after debug level 5 I had about 500M of core dumps (sorry don't have
>them anymore)
>* Ran ipa-adtrust-install again with --setsid and reset some passwords
>and things started looking better, could connect, all good, NT hash was
>there and ipaNTSecurityIdentifier there (ldapsearch <3)
>* Then next problem was when I added "valid users = @groupname" to
>share config. No longer could connect even if member of the group!
>* Turned out ipNTGroupAttr was missing from some groups - thus had to
>register the ldif for the ipa-setsid task
For the record, it is ipa-adtrust-install --add-sids and the task is
called sidgen task.

>I noticed the "Could not find uidNumber" - turns out ipa-sam was being
>asked to turn SID into ID and was successfully finding it but needed to
>work out whether it was a group or a user. To do this, it searches the
>objectClass for "ipNTGroupAttr" - if it finds it, it looks for
>gidNumber, otherwise it looks for uidNumber. However, the objectClass
>added by ipa-setsid is "ipntgroupattr" and ipa-sam was using "strncmp".
>
>I've fixed this with a patch to use strncasecmp. Might not be the best
>fix... maybe ipa-sam should be modified to have the attributes lower
>case for comparison? But this was simplest patch. Comments/feedback
>welcome and maybe I'll have time to do alternative fix if felt better?
You are absolutely on spot here, thanks!

Since we are comparing values of the attribute, we are on our own and
cannot rely on attribute name canonicalization here. This means
strncasecmp() is for the job. I've looked at other options like using
ber_bvcmp() macro but we are really can't guarantee that objectClass
attribute values are in any specific string case because the only 
matching rule defined for them is objectIdentifierMatch -- we would have
to turn the value to oid first and then compare which is probably too
much for this specific case.


>Versions:
>RHEL 6.4 3.0.0-37
>Code in master branch appears to show the same issue
>
>References:
>freeipa/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen.h
>around line 54-55: lowercase objectClass addition
>freeipa/daemons/ipa-sam/ipa_sam.c
>around line 688: case sensitive comparison to ipaNTGroupAttrs
>
>Patch for master branch:
>diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c
>index 1ca504d..c5e8b39 100644
>--- a/daemons/ipa-sam/ipa_sam.c
>+++ b/daemons/ipa-sam/ipa_sam.c
>@@ -750,7 +750,7 @@ static bool ldapsam_sid_to_id(struct pdb_methods *methods,
> 	}
>
> 	for (c = 0; values[c] != NULL; c++) {
>-		if (strncmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val,
>+		if (strncasecmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val,
> 			                       values[c]->bv_len) == 0) {
> 			break;
> 		}
>
>Patch for RHEL 6.5 3.0.0-37:
>--- a/daemons/ipa-sam/ipa_sam.c	2014-03-06 19:30:15.994792879 +0000
>+++ b/daemons/ipa-sam/ipa_sam.c	2014-03-06 19:35:34.966791637 +0000
>@@ -685,7 +685,7 @@
> 	}
>
> 	for (c = 0; values[c] != NULL; c++) {
>-		if (strncmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val,
>+		if (strncasecmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val,
> 			                       values[c]->bv_len) == 0) {
> 			break;
> 		}
>
This is valid bug. Could you please raise it in bugzilla.redhat.com or,
alternatively, at FreeIPA's trac?

-- 
/ Alexander Bokovoy



From dpal at redhat.com  Fri Mar  7 01:20:23 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Thu, 06 Mar 2014 20:20:23 -0500
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>
Message-ID: <53191ED7.1000502@redhat.com>

On 03/05/2014 06:24 PM, Trey Dockendorf wrote:
> Correction from my email, the condition that sets if a 389DS user is
> proxied to pam_krb5 is the "pamFilter", sorry.
>
> On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorf<treydock at gmail.com>  wrote:
>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<dpal at redhat.com>  wrote:
>>> On 03/03/2014 07:47 PM, Simo Sorce wrote:
>>>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
>>>>> Is it possible with FreeIPA to use an external KDC or pass some or all
>>>>> authentication to an external KDC?  The KDC at our University may give
>>>>> me a one way trust if I describe my implementation plan for FreeIPA.
>>>>> Currently I use 389DS with PAM pass through using untrusted pam_krb5.
>>>>> I'd like to fully utilize FreeIPA without managing passwords since all
>>>>> my users already have University accounts.  I just want to manage
>>>>> authorization for my systems, not authentication.
>>>> You could set up a kerberos trust manually but at the moment we do not
>>>> support it in the code or the utilities.
>>>>
>>>> SSSD in particular will have no place to find identity information if
>>>> all you have is a kerberos trust, you'd need also an external identity
>>>> store to point to, but there is no builtin code in SSSD to link the 2
>>>> domain at this point.
>>>>
>>>> We are planning on working on IPA-to-IPA trust, and possibly
>>>> IPA-to-*other* so any requirements you can throw at us will be made part
>>>> of the consideration and planning to add this kind of functionality in
>>>> the future.
>>>>
>>>> NM B HTH,
>>>> Simo.
>>>>
>>> Can you describe your workflows because I have some idea in mind?
>> Right now the workflow I have with 389ds using PAM Pass Through Auth
>> is the following:
>>
>> For users with the proper attribute defined in 'pamIDAttr'
>>
>> client --->  389DS --->  389DS server's pam_krb5 --->  Campus KDC
>>
>> For users lacking the attribute for 'pamIDAttr'
>>
>> client --->  389DS
>>
>> The Kerberos setup currently on the 389DS server is untrusted (no krb5.keytab).
>>
>> The ideal workflow with FreeIPA would be
>>
>> client ---->  IPA --->  Campus KDC
>>
>>> Would you be OK if your accounts would be in IPA but the authentication
>>> would be proxied out?
>> This is fine with me.  Does the idea you describe allow for some
>> authentication (ie system accounts or internal accounts) to be handled
>> by FreeIPA?  That's the benefit to us when using PAM Pass Through
>> Auth, is that we can conditionally proxy out the authentication.
>>
>>> The idea is that you can use OTP RADIUS capability to proxy passwords to
>>> your main KDC.
>>>
>>> client ---OTP--->  IPA --->  OTP Proxy --->  RADIUS --->  Your KDC
>>>
>>> Disclaimer: that would defeat the purpose of Kerberos and the password will
>>> be sent over the wire but it seems that you are already in this setup.
>>>
>>> Would you be interested to give it a try?
>> Absolutely.  Right now I need to contact our campus IT group and let
>> them know what I require to make our setup work.  I have been told a
>> one way trust is the most I can get.  Will that facilitate what you
>> described?

You do not need trust for that setup. Any user account (i am not sure 
about special system accounts that are not created in cn=users) would be 
able to go to external RADIUS server.

>>
>>> Would require latest SSSD and kerberos library on the client though but
>>> would work with LDAP binds too.
>> Latest SSSD and Kerberos that's available in EL6, or latest upstream?

Upstream.

Please take a look at the design page: 
http://www.freeipa.org/page/V3/OTP - that will give you an idea about 
the internals.

Latest upstream UI should be able to allow to configure external RADIUS 
servers and then change per user policy to proxy via RADIUS. Then you 
can try binding with LDAP to IPA using password from your main KDC.
Then you can use SSSD on the same system to try to authenticate using 
Kerberos. You will create a new user, set him to use RADIUS server for 
authentication and then try to su to this user or ssh into the box as 
that user. It should work and klist should report a TGT for this user on 
the box.

>>
>>>
>>> --
>>> 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 at 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/





From dpal at redhat.com  Fri Mar  7 01:25:30 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Thu, 06 Mar 2014 20:25:30 -0500
Subject: [Freeipa-users] Password issues
In-Reply-To: <531873AF.2060803@damascusgrp.com>
References: <53186C73.6000701@damascusgrp.com>	<20140306125536.GG3051@localhost.localdomain>
	<53187331.8010207@damascusgrp.com>
	<531873AF.2060803@damascusgrp.com>
Message-ID: <5319200A.8060303@redhat.com>

On 03/06/2014 08:10 AM, Bret Wortman wrote:
> Just found with some fresh Googling an email from Rob recommending 
> setting the max to 5000. I'll try that.

Just make sure it is not after 2038 because Kerberos uses 32 bit time 
that rolls over in Feb of 2038.

>
>
> On 03/06/2014 08:08 AM, Bret Wortman wrote:
>> Is there a way to set a password to not expire? I thought I read 
>> somewhere that 0 did that, but apparently not.
>>
>> On 03/06/2014 07:55 AM, Sumit Bose wrote:
>>> On Thu, Mar 06, 2014 at 07:39:15AM -0500, Bret Wortman wrote:
>>>> Strange behavior now with our passwords (and we still haven't solved
>>>> our problem with the "ipa" command, but at least with script, we
>>>> have a workaround):
>>>>
>>>> I noticed yesterday morning that my password, which has the
>>>> following policy, was going to expire in 3 days so I changed it.
>>>>
>>>> Max lifetime (days) : 0
>>> I think the behaviour is expected with this maximal lifetime.
>>>
>>> bye,
>>> Sumit
>>>
>>>> Min lifetime (hours) : 0
>>>> History size (number of passwords): 0
>>>> Character classes: 2
>>>> Min length: 8
>>>> Max failures: 4
>>>> Failure reset interval (seconds): 60
>>>> Lockout duration (seconds): 60
>>>>
>>>> The IPA web UI immediately began reporting in red that "Your
>>>> password expires in -1 days."
>>>>
>>>> This morning, I ran "kinit":
>>>>
>>>> $ kinit
>>>> Password for bretw at DAMASCUSGRP.COM:
>>>> Password expired.  You must change it now.
>>>> Enter new password:
>>>> Enter it again:
>>>> Warning: Your password wille xpire in less than one hour on Thu 06
>>>> Mar 2014 06:45:48 AM EST
>>>> $
>>>>
>>>> What's up? I'd like to solve this before it bites any of my users,
>>>> though most have a policy that looks more like this:
>>>>
>>>> Max lifetime (days) : 180
>>>> Min lifetime (hours) : 1
>>>> History size (number of passwords): 0
>>>> Character classes: 2
>>>> Min length: 8
>>>> Max failures: 6
>>>> Failure reset interval (seconds): 60
>>>> Lockout duration (seconds): 600
>>>>
>>>>
>>>> -- 
>>>> *Bret Wortman*
>>>>
>>>> http://damascusgrp.com/
>>>> http://about.me/wortmanbret
>>>>
>>>
>>>
>>>> _______________________________________________
>>>> Freeipa-users mailing list
>>>> Freeipa-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>>
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/542a0838/attachment.htm>

From bret.wortman at damascusgrp.com  Fri Mar  7 01:32:30 2014
From: bret.wortman at damascusgrp.com (Bret Wortman)
Date: Thu, 6 Mar 2014 20:32:30 -0500
Subject: [Freeipa-users] Password issues
In-Reply-To: <5319200A.8060303@redhat.com>
References: <53186C73.6000701@damascusgrp.com>
	<20140306125536.GG3051@localhost.localdomain>
	<53187331.8010207@damascusgrp.com>
	<531873AF.2060803@damascusgrp.com> <5319200A.8060303@redhat.com>
Message-ID: <5AF41B23-DEF0-4C81-BDA8-545E7591D903@damascusgrp.com>

In 26 years, I guarantee this will be someone else's problem. 


Bret Wortman
http://bretwortman.com/
http://twitter.com/BretWortman

> On Mar 6, 2014, at 8:25 PM, Dmitri Pal <dpal at redhat.com> wrote:
> 
>> On 03/06/2014 08:10 AM, Bret Wortman wrote:
>> Just found with some fresh Googling an email from Rob recommending setting the max to 5000. I'll try that.
> 
> Just make sure it is not after 2038 because Kerberos uses 32 bit time that rolls over in Feb of 2038.
> 
>> 
>> 
>>> On 03/06/2014 08:08 AM, Bret Wortman wrote:
>>> Is there a way to set a password to not expire? I thought I read somewhere that 0 did that, but apparently not. 
>>> 
>>>> On 03/06/2014 07:55 AM, Sumit Bose wrote: 
>>>>> On Thu, Mar 06, 2014 at 07:39:15AM -0500, Bret Wortman wrote: 
>>>>> Strange behavior now with our passwords (and we still haven't solved 
>>>>> our problem with the "ipa" command, but at least with script, we 
>>>>> have a workaround): 
>>>>> 
>>>>> I noticed yesterday morning that my password, which has the 
>>>>> following policy, was going to expire in 3 days so I changed it. 
>>>>> 
>>>>> Max lifetime (days) : 0
>>>> I think the behaviour is expected with this maximal lifetime. 
>>>> 
>>>> bye, 
>>>> Sumit 
>>>> 
>>>>> Min lifetime (hours) : 0 
>>>>> History size (number of passwords): 0 
>>>>> Character classes: 2 
>>>>> Min length: 8 
>>>>> Max failures: 4 
>>>>> Failure reset interval (seconds): 60 
>>>>> Lockout duration (seconds): 60 
>>>>> 
>>>>> The IPA web UI immediately began reporting in red that "Your 
>>>>> password expires in -1 days." 
>>>>> 
>>>>> This morning, I ran "kinit": 
>>>>> 
>>>>> $ kinit 
>>>>> Password for bretw at DAMASCUSGRP.COM: 
>>>>> Password expired.  You must change it now. 
>>>>> Enter new password: 
>>>>> Enter it again: 
>>>>> Warning: Your password wille xpire in less than one hour on             Thu 06 
>>>>> Mar 2014 06:45:48 AM EST 
>>>>> $ 
>>>>> 
>>>>> What's up? I'd like to solve this before it bites any of my users, 
>>>>> though most have a policy that looks more like this: 
>>>>> 
>>>>> Max lifetime (days) : 180 
>>>>> Min lifetime (hours) : 1 
>>>>> History size (number of passwords): 0 
>>>>> Character classes: 2 
>>>>> Min length: 8 
>>>>> Max failures: 6 
>>>>> Failure reset interval (seconds): 60 
>>>>> Lockout duration (seconds): 600 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> *Bret Wortman* 
>>>>> 
>>>>> http://damascusgrp.com/ 
>>>>> http://about.me/wortmanbret
>>>> 
>>>> 
>>>>> _______________________________________________ 
>>>>> Freeipa-users mailing list 
>>>>> Freeipa-users at redhat.com 
>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>> _______________________________________________ 
>>>> Freeipa-users mailing list 
>>>> Freeipa-users at redhat.com 
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> 
>> 
>> 
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/9c17421a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2346 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140306/9c17421a/attachment.p7s>

From mkosek at redhat.com  Fri Mar  7 08:37:29 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Fri, 07 Mar 2014 09:37:29 +0100
Subject: [Freeipa-users] winsync and new users
In-Reply-To: <20140227221100.GX16644@redhat.com>
References: <530FB5D7.9040002@img.cas.cz> <20140227221100.GX16644@redhat.com>
Message-ID: <53198549.9000702@redhat.com>

On 02/27/2014 11:11 PM, Alexander Bokovoy wrote:
> On Thu, 27 Feb 2014, Michal Zacek wrote:
>> Hi,
>>
>> I have successfully completed agreement between Windows and IPA and it
>> works.  When I create user in Windows, it's synchronized to IPA and when I
>> change something  on IPA  for this user, it's synchronized back to Windows,
>> but when I create *new* user in IPA it's not synchronized (created) in
>> Windows. Is this the way how it's supposed to work? New user are synchronized
>> only from Windows to IPA?
> Yes, that's how it is supposed to work.

I would also recommend checking our preferred way of integrating with Windows
to see if it matches your requirements better:

http://www.freeipa.org/page/Trusts

Martin



From pspacek at redhat.com  Fri Mar  7 08:39:00 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Fri, 07 Mar 2014 09:39:00 +0100
Subject: [Freeipa-users] Patch for ipa-sam: ipa-server-trust-ad samba
 server valid users =@groupname
In-Reply-To: <20140306220615.GQ16644@redhat.com>
References: <2EF3F569-081B-46EB-9188-FB7349450479@jasonwoods.me.uk>
	<20140306220615.GQ16644@redhat.com>
Message-ID: <531985A4.6010505@redhat.com>

On 6.3.2014 23:06, Alexander Bokovoy wrote:
> On Thu, 06 Mar 2014, Jason Woods wrote:
>> Hi all,
>>
>> I am quite aware that installing ipa-server-trust-ad and using the
>> samba as a file server is as unsupported as one can get... but I really
>> needed a Samba server integrated with IPA (damn Mac OS and Windows). I
>> don't actually have a Windows environment but this seemed to bootstrap
>> enough of the requirements to get it working
>>
>> Bit of a story for those who have time to read and maybe battling
>> similiar, or just skip to after the log for the fix+patch :)
>> * ipaNTSecurityIdentifier ended up missing because I didn't use
>> --setsid and NT hash missing because I did not do a ipa passwd reset
>> * As a result, experienced user not found or invalid password, and
>> after debug level 5 I had about 500M of core dumps (sorry don't have
>> them anymore)
>> * Ran ipa-adtrust-install again with --setsid and reset some passwords
>> and things started looking better, could connect, all good, NT hash was
>> there and ipaNTSecurityIdentifier there (ldapsearch <3)
>> * Then next problem was when I added "valid users = @groupname" to
>> share config. No longer could connect even if member of the group!
>> * Turned out ipNTGroupAttr was missing from some groups - thus had to
>> register the ldif for the ipa-setsid task
> For the record, it is ipa-adtrust-install --add-sids and the task is
> called sidgen task.
>
>> I noticed the "Could not find uidNumber" - turns out ipa-sam was being
>> asked to turn SID into ID and was successfully finding it but needed to
>> work out whether it was a group or a user. To do this, it searches the
>> objectClass for "ipNTGroupAttr" - if it finds it, it looks for
>> gidNumber, otherwise it looks for uidNumber. However, the objectClass
>> added by ipa-setsid is "ipntgroupattr" and ipa-sam was using "strncmp".
>>
>> I've fixed this with a patch to use strncasecmp. Might not be the best
>> fix... maybe ipa-sam should be modified to have the attributes lower
>> case for comparison? But this was simplest patch. Comments/feedback
>> welcome and maybe I'll have time to do alternative fix if felt better?
> You are absolutely on spot here, thanks!
>
> Since we are comparing values of the attribute, we are on our own and
> cannot rely on attribute name canonicalization here. This means
> strncasecmp() is for the job. I've looked at other options like using
> ber_bvcmp() macro but we are really can't guarantee that objectClass
> attribute values are in any specific string case because the only matching
> rule defined for them is objectIdentifierMatch -- we would have
> to turn the value to oid first and then compare which is probably too
> much for this specific case.
>
>
>> Versions:
>> RHEL 6.4 3.0.0-37
>> Code in master branch appears to show the same issue
>>
>> References:
>> freeipa/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen.h
>> around line 54-55: lowercase objectClass addition
>> freeipa/daemons/ipa-sam/ipa_sam.c
>> around line 688: case sensitive comparison to ipaNTGroupAttrs
>>
>> Patch for master branch:
>> diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c
>> index 1ca504d..c5e8b39 100644
>> --- a/daemons/ipa-sam/ipa_sam.c
>> +++ b/daemons/ipa-sam/ipa_sam.c
>> @@ -750,7 +750,7 @@ static bool ldapsam_sid_to_id(struct pdb_methods *methods,
>>     }
>>
>>     for (c = 0; values[c] != NULL; c++) {
>> -        if (strncmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val,
>> +        if (strncasecmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val,
>>                                    values[c]->bv_len) == 0) {
>>             break;
>>         }
>>
>> Patch for RHEL 6.5 3.0.0-37:
>> --- a/daemons/ipa-sam/ipa_sam.c    2014-03-06 19:30:15.994792879 +0000
>> +++ b/daemons/ipa-sam/ipa_sam.c    2014-03-06 19:35:34.966791637 +0000
>> @@ -685,7 +685,7 @@
>>     }
>>
>>     for (c = 0; values[c] != NULL; c++) {
>> -        if (strncmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val,
>> +        if (strncasecmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val,
>>                                    values[c]->bv_len) == 0) {
>>             break;
>>         }
>>
> This is valid bug. Could you please raise it in bugzilla.redhat.com or,
> alternatively, at FreeIPA's trac?

To simply it for you:

The right place is
https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%206

Version = 6.4
Component = ipa

-- 
Petr^2 Spacek



From mkosek at redhat.com  Fri Mar  7 09:16:04 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Fri, 07 Mar 2014 10:16:04 +0100
Subject: [Freeipa-users] F19 -> F20 yum upgrade success report (WAS: Re:
 WARNING: Do not upgrade FreeIPA deployments to Fedora 20 final (yet))
In-Reply-To: <4052016.7n8uHLVFPi@linux-ws1.messinet.com>
References: <20131217091434.GW21264@redhat.com>	<81614488.131679.1387708947601.JavaMail.root@redhat.com>	<3420623.9DfvCDMCbu@linux-ws1.messinet.com>
	<4052016.7n8uHLVFPi@linux-ws1.messinet.com>
Message-ID: <53198E54.9090402@redhat.com>

On 03/03/2014 09:54 PM, Anthony Messina wrote:
> On Saturday, March 01, 2014 04:18:11 AM Anthony Messina wrote:
>> I've been waiting patiently for F20 to "settle" before upgrading my two
>> VM installations of FreeIPA:
>> 
>> ipa1 (original master) ipa2 (clone)
>> 
>> I'm considering doing a "yum upgrade" this weekend and was wondering if
>> any users had found any "gotchas"?  One that I can think of is the
>> addition of the following in F20's default /etc/krb5.conf:
>> 
>> [libdefaults] ... default_ccache_name = KEYRING:persistent:%{uid} ...
>> 
>> I've seen on some of my freshly installed F20 FreeIPA clients that this 
>> option  is no longer present after ipa-client-install.  On those
>> clients, I've manually added it post client install and things seem to
>> work OK with the exception of SELinux errors reported here:
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1001703
>> 
>> Should I place this option in /etc/krb5.conf on the masters
>> before/after the  yum upgrade (or at all)?
>> 
>> Should I run "ipactl stop" prior to running the yum upgrade?
>> 
>> Of note, I'm considering the "yum upgrade" option rather than creating
>> F20 replicas of F19 masters due to:
>> 
>> https://fedorahosted.org/pki/ticket/816 
>> https://fedorahosted.org/389/ticket/47721
>> 
>> Any guidance is appreciated.  Thanks, and have a good weekend.
>> 
>> -A
> 
> I can report to the list that I've upgraded my ipa1 and ipa2 machines from
> F19 to F20 via "yum upgrade" in SELinux permissive mode and things went 
> swimmingly.

I always like to hear user reports like this one :) Thanks!

> 
> As far as my concerns above, I added the following to /etc/krb5.conf after
> the upgrade, but before the reboot:
> 
> default_ccache_name = KEYRING:persistent:%{uid}
> 
> And I did not issue "ipactl stop" prior to the upgrade.
> 
> The only post-upgrade issue I am seeing is invalid characters passed to
> dirsrv queries when using FreeIPA web interface:
> 
> https://fedorahosted.org/freeipa/ticket/4214

Thanks for the report. I think I found the root cause, patch sent.

Martin



From mkosek at redhat.com  Fri Mar  7 09:18:09 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Fri, 07 Mar 2014 10:18:09 +0100
Subject: [Freeipa-users] HTTP Service: STOPPED
In-Reply-To: <53161E57.4010204@redhat.com>
References: <1393957711.59955.YahooMailNeo@web160102.mail.bf1.yahoo.com>
	<53161E57.4010204@redhat.com>
Message-ID: <53198ED1.5060903@redhat.com>

On 03/04/2014 07:41 PM, Dmitri Pal wrote:
> On 03/04/2014 01:28 PM, Shree wrote:
>> Not sure what is going on?
>>
>> I get the following error.
>> ---------------
>> Starting httpd: (98)Address already in use: make_sock: could not bind to
>> address [::]:443
>> ---------------
>>
>> I have a feeling our puppet is causing some problem. I get the following when
>> I run "puppet agent -t"
>> ------------------
>> notice: /Stage[main]//Node[a-za-z0-9]/Service[httpd]/ensure: ensure changed
>> 'stopped' to 'running'
>> ------------------
>>
>>
>> ipa-server-3.0.0-26.el6_4.4.x86_64
>>
>> Shreeraj
>> ----------------------------------------------------------------------------------------
>>
>>
>>
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
> 
> This might be a collision between to services using the same port. IPA uses
> this port for HTTPS. If any other application is trying to use this port there
> will be a collision.

I would also check that puppet for example did not install mod_ssl on the same
machine as FreeIPA after it's installation as it is known to simply bind to
this port without asking.

Martin



From mkosek at redhat.com  Fri Mar  7 09:23:35 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Fri, 07 Mar 2014 10:23:35 +0100
Subject: [Freeipa-users] incompatibility Operative systems
In-Reply-To: <00c001cf3956$73093e30$591bba90$@ife.org.mx>
References: <00c001cf3956$73093e30$591bba90$@ife.org.mx>
Message-ID: <53199017.3090304@redhat.com>

On 03/06/2014 05:09 PM, Juan Antonio wrote:
>  
> 
>  
> 
> I have a conflict with a configuration of free-ipa.
> The problem is an incompatibility between the client operating system with
> fedora 19 and the ipa server with Red hat 6.4 operating system.
> When executing the command: 
> 
> ipa add-service cifs/ipaserver.example.com
> 
> Generates the error:
> ipa: ERROR: Unknown option: no_members
> 
> For this reason I would like to know if there is a specific configuration or
> patch that solution problem.

Older "ipa" tool can communicate with newer FreeIPA server but not the other
way around - thus this failure is expected.

Just the error message is not right, we have a ticket planning to fix it:
https://fedorahosted.org/freeipa/ticket/3963

Hint: use "ipa" tool on 6.4 to control 6.4 FreeIPA server.

Martin

PS: we are talking only about "ipa" tool incompatibility, you can of course
enroll F19 clients to 6.4 and have all client functions (identity,
authentication) working - SSSD is compatible.



From devel at jasonwoods.me.uk  Fri Mar  7 10:14:52 2014
From: devel at jasonwoods.me.uk (Jason Woods)
Date: Fri, 7 Mar 2014 10:14:52 +0000
Subject: [Freeipa-users] Patch for ipa-sam: ipa-server-trust-ad samba
	server valid users =@groupname
In-Reply-To: <531985A4.6010505@redhat.com>
References: <2EF3F569-081B-46EB-9188-FB7349450479@jasonwoods.me.uk>
	<20140306220615.GQ16644@redhat.com> <531985A4.6010505@redhat.com>
Message-ID: <D23503A3-43F9-4168-9C57-669B16C2F05B@jasonwoods.me.uk>

Hi,

On 6.3.2014 23:06, Alexander Bokovoy wrote:
> For the record, it is ipa-adtrust-install --add-sids and the task is
> called sidgen task.

Absolutely. Sorry for the confusion - too late and swimming in the code had me mix up the terminology :-) All sorted for the bugzilla ticket.

On 6.3.2014 23:06, Alexander Bokovoy wrote:
> Since we are comparing values of the attribute, we are on our own and
> cannot rely on attribute name canonicalization here. This means
> strncasecmp() is for the job. I've looked at other options like using
> ber_bvcmp() macro but we are really can't guarantee that objectClass
> attribute values are in any specific string case because the only matching
> rule defined for them is objectIdentifierMatch -- we would have
> to turn the value to oid first and then compare which is probably too
> much for this specific case.

Sure, I was thinking the simplest fix is probably the best fix. Thanks for the time to look over the problem!

On 7 Mar 2014, at 08.39, Petr Spacek <pspacek at redhat.com> wrote:
> On 6.3.2014 23:06, Alexander Bokovoy wrote:
>> This is valid bug. Could you please raise it in bugzilla.redhat.com or,
>> alternatively, at FreeIPA's trac?
> 
> To simply it for you:
> 
> The right place is
> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%206

All done and raised, hopefully with enough information, at: https://bugzilla.redhat.com/show_bug.cgi?id=1073829

Thanks for you time!

Regards,

Jason




From artjazz at free.fr  Fri Mar  7 13:16:07 2014
From: artjazz at free.fr (artjazz at free.fr)
Date: Fri, 07 Mar 2014 14:16:07 +0100
Subject: [Freeipa-users] install IPA replica multi-hosts (ipa packages
	version 3.3.3-18)
Message-ID: <1394198167.5319c6977ca6d@imp.free.fr>


Hi,

I want to install ipa server with a replica. The replica has 2 NICs : the ipa
server is connected on the first interface and all the clients are connected on
the second interface. The two networks are completely separated, 2 subnets and
not routed.

I'am wondering if this kind of configuration is supported with IPA.

Ipa server has been installed with success on the first interface:


First, I prepared the replica on its first interface name (that which is on the
same network as the ipa server), install it with success. In this case the
ipa-client-install fails;
See below ==== errors ipacli1 ====

Second, I prepared the replica on its second interface name (that which is on
the same network as the ipa client). This case is worst I'm even not able to
install the replica. The installation fails with the following errors , see
below ==== errors iparpl2 ====

Thanks a lot for your help.

===================================== errors ipacli1
=====================================
- messages in screen or std output:
Skip iparpl1.blue.mydomain: cannot verify if this is an IPA server
Failed to verify that iparpl1.blue.mydomain is an IPA Server.

- messages in log /var/log/ipaclient-install.log:
2014-03-07T12:20:24Z DEBUG [LDAP server check]
2014-03-07T12:20:24Z DEBUG Verifying that iparpl1.blue.mydomain (realm None) is
an IPA server
2014-03-07T12:20:24Z DEBUG Init LDAP connection to: iparpl1.blue.mydomain
2014-03-07T12:20:29Z DEBUG wait_for_open_ports: iparpl1.blue.mydomain [389]
timeout 10
2014-03-07T12:20:34Z DEBUG Error checking LDAP: [Errno -2] Name or service not
known
2014-03-07T12:20:34Z WARNING Skip iparpl1.blue.mydomain: cannot verify if this
is an IPA server

- check in iparpl1
[root at iparpl1 ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa: INFO: The ipactl command was successful

[root at iparpl1 ~]# ldapsearch -x -H ldap://iparpl1.blue.mydomain:389 -W -ZZ
ldap_start_tls: Connect error (-11)
	additional info: TLS error -8157:Certificate extension not found.
[root at iparpl1 ~]# ldapsearch -x -H ldap://iparpl1.mydomain:389 -W &#8211;ZZ
OK

===================================== errors iparpl2
=====================================
- messages in screen or std output
KO normal because the master doesn't connect to replica in second interface
Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'iparpl2.green.mydomain':
   Directory Service: Unsecure port (389): FAILED
   Directory Service: Secure port (636): FAILED
   Kerberos KDC: TCP (88): FAILED
   Kerberos KDC: UDP (88): WARNING
   Kerberos Kpasswd: TCP (464): FAILED
   Kerberos Kpasswd: UDP (464): WARNING
   HTTP Server: Unsecure port (80): FAILED
   HTTP Server: Secure port (443): FAILED
The following UDP ports could not be verified as open: 88, 464
This can happen if they are already bound to an application
and ipa-replica-conncheck cannot attach own UDP responder.

Remote master check failed with following error message(s):
Warning: Permanently added 'ipasrv.mydomain,110.0.0.2' (ECDSA) to the list of
known hosts.
Port check failed! Inaccessible port(s): 389 (TCP), 636 (TCP), 88 (TCP), 464
(TCP), 80 (TCP), 443 (TCP)
Connection check failed!
Please fix your network settings according to error messages above.
If the check results are not valid it can be skipped with --skip-conncheck
parameter.




From pspacek at redhat.com  Fri Mar  7 14:45:46 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Fri, 07 Mar 2014 15:45:46 +0100
Subject: [Freeipa-users] install IPA replica multi-hosts (ipa packages
 version 3.3.3-18)
In-Reply-To: <1394198167.5319c6977ca6d@imp.free.fr>
References: <1394198167.5319c6977ca6d@imp.free.fr>
Message-ID: <5319DB9A.2090809@redhat.com>

On 7.3.2014 14:16, artjazz at free.fr wrote:
> I want to install ipa server with a replica. The replica has 2 NICs : the ipa
> server is connected on the first interface and all the clients are connected on
> the second interface. The two networks are completely separated, 2 subnets and
> not routed.
I'm curious - what is the reasoning behind this? :-)

> I'am wondering if this kind of configuration is supported with IPA.
>
> Ipa server has been installed with success on the first interface:
>
>
> First, I prepared the replica on its first interface name (that which is on the
> same network as the ipa server), install it with success. In this case the
> ipa-client-install fails;
> See below ==== errors ipacli1 ====
See my reply below :-)

> Second, I prepared the replica on its second interface name (that which is on
> the same network as the ipa client). This case is worst I'm even not able to
> install the replica. The installation fails with the following errors , see
> below ==== errors iparpl2 ====
I'm not sure I understand what you did.

You have installed the replica on one machine and then you have tried to 
install the replica again on the same machine? I guess I have misunderstood 
something ...

> Thanks a lot for your help.
>
> ===================================== errors ipacli1
> =====================================
> - messages in screen or std output:
> Skip iparpl1.blue.mydomain: cannot verify if this is an IPA server
> Failed to verify that iparpl1.blue.mydomain is an IPA Server.
>
> - messages in log /var/log/ipaclient-install.log:
> 2014-03-07T12:20:24Z DEBUG [LDAP server check]
> 2014-03-07T12:20:24Z DEBUG Verifying that iparpl1.blue.mydomain (realm None) is
> an IPA server
> 2014-03-07T12:20:24Z DEBUG Init LDAP connection to: iparpl1.blue.mydomain
> 2014-03-07T12:20:29Z DEBUG wait_for_open_ports: iparpl1.blue.mydomain [389]
> timeout 10
> 2014-03-07T12:20:34Z DEBUG Error checking LDAP: [Errno -2] Name or service not
> known
The problem is that your client can't resolve name of the server.

> 2014-03-07T12:20:34Z WARNING Skip iparpl1.blue.mydomain: cannot verify if this
> is an IPA server
>
> - check in iparpl1
> [root at iparpl1 ~]# ipactl status
> Directory Service: RUNNING
> krb5kdc Service: RUNNING
> kadmin Service: RUNNING
> ipa_memcached Service: RUNNING
> httpd Service: RUNNING
> pki-tomcatd Service: RUNNING
> ipa-otpd Service: RUNNING
> ipa: INFO: The ipactl command was successful
>
> [root at iparpl1 ~]# ldapsearch -x -H ldap://iparpl1.blue.mydomain:389 -W -ZZ
> ldap_start_tls: Connect error (-11)
> 	additional info: TLS error -8157:Certificate extension not found.
> [root at iparpl1 ~]# ldapsearch -x -H ldap://iparpl1.mydomain:389 -W &#8211;ZZ
> OK
>
> ===================================== errors iparpl2
> =====================================
> - messages in screen or std output
> KO normal because the master doesn't connect to replica in second interface
> Connection from replica to master is OK.
> Start listening on required ports for remote master check
> Get credentials to log in to remote master
> Check SSH connection to remote master
> Execute check on remote master
> Check connection from master to remote replica 'iparpl2.green.mydomain':
>     Directory Service: Unsecure port (389): FAILED
>     Directory Service: Secure port (636): FAILED
>     Kerberos KDC: TCP (88): FAILED
>     Kerberos KDC: UDP (88): WARNING
>     Kerberos Kpasswd: TCP (464): FAILED
>     Kerberos Kpasswd: UDP (464): WARNING
>     HTTP Server: Unsecure port (80): FAILED
>     HTTP Server: Secure port (443): FAILED
> The following UDP ports could not be verified as open: 88, 464
> This can happen if they are already bound to an application
> and ipa-replica-conncheck cannot attach own UDP responder.
>
> Remote master check failed with following error message(s):
> Warning: Permanently added 'ipasrv.mydomain,110.0.0.2' (ECDSA) to the list of
> known hosts.
> Port check failed! Inaccessible port(s): 389 (TCP), 636 (TCP), 88 (TCP), 464
> (TCP), 80 (TCP), 443 (TCP)
> Connection check failed!
> Please fix your network settings according to error messages above.
> If the check results are not valid it can be skipped with --skip-conncheck
> parameter.

My guess is that you use different name for each interface, right? I'm afraid 
that it can't work, FreeIPA doesn't support that.

Generally, setups like this do not work very well when Kerberos is in the mix.

You can try to add both IP addresses to A record for the multi-homed replica 
but then you will depend on failover between those two IP addresses etc...

-- 
Petr^2 Spacek



From mkosek at redhat.com  Fri Mar  7 14:55:32 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Fri, 07 Mar 2014 15:55:32 +0100
Subject: [Freeipa-users] install IPA replica multi-hosts (ipa packages
 version 3.3.3-18)
In-Reply-To: <5319DB9A.2090809@redhat.com>
References: <1394198167.5319c6977ca6d@imp.free.fr>
	<5319DB9A.2090809@redhat.com>
Message-ID: <5319DDE4.8000305@redhat.com>

On 03/07/2014 03:45 PM, Petr Spacek wrote:
> On 7.3.2014 14:16, artjazz at free.fr wrote:
>> I want to install ipa server with a replica. The replica has 2 NICs : the ipa
>> server is connected on the first interface and all the clients are connected on
>> the second interface. The two networks are completely separated, 2 subnets and
>> not routed.
> I'm curious - what is the reasoning behind this? :-)
> 
>> I'am wondering if this kind of configuration is supported with IPA.
>>
>> Ipa server has been installed with success on the first interface:
>>
>>
>> First, I prepared the replica on its first interface name (that which is on the
>> same network as the ipa server), install it with success. In this case the
>> ipa-client-install fails;
>> See below ==== errors ipacli1 ====
> See my reply below :-)
> 
>> Second, I prepared the replica on its second interface name (that which is on
>> the same network as the ipa client). This case is worst I'm even not able to
>> install the replica. The installation fails with the following errors , see
>> below ==== errors iparpl2 ====
> I'm not sure I understand what you did.
> 
> You have installed the replica on one machine and then you have tried to
> install the replica again on the same machine? I guess I have misunderstood
> something ...
> 
>> Thanks a lot for your help.
>>
>> ===================================== errors ipacli1
>> =====================================
>> - messages in screen or std output:
>> Skip iparpl1.blue.mydomain: cannot verify if this is an IPA server
>> Failed to verify that iparpl1.blue.mydomain is an IPA Server.
>>
>> - messages in log /var/log/ipaclient-install.log:
>> 2014-03-07T12:20:24Z DEBUG [LDAP server check]
>> 2014-03-07T12:20:24Z DEBUG Verifying that iparpl1.blue.mydomain (realm None) is
>> an IPA server
>> 2014-03-07T12:20:24Z DEBUG Init LDAP connection to: iparpl1.blue.mydomain
>> 2014-03-07T12:20:29Z DEBUG wait_for_open_ports: iparpl1.blue.mydomain [389]
>> timeout 10
>> 2014-03-07T12:20:34Z DEBUG Error checking LDAP: [Errno -2] Name or service not
>> known
> The problem is that your client can't resolve name of the server.
> 
>> 2014-03-07T12:20:34Z WARNING Skip iparpl1.blue.mydomain: cannot verify if this
>> is an IPA server
>>
>> - check in iparpl1
>> [root at iparpl1 ~]# ipactl status
>> Directory Service: RUNNING
>> krb5kdc Service: RUNNING
>> kadmin Service: RUNNING
>> ipa_memcached Service: RUNNING
>> httpd Service: RUNNING
>> pki-tomcatd Service: RUNNING
>> ipa-otpd Service: RUNNING
>> ipa: INFO: The ipactl command was successful
>>
>> [root at iparpl1 ~]# ldapsearch -x -H ldap://iparpl1.blue.mydomain:389 -W -ZZ
>> ldap_start_tls: Connect error (-11)
>>     additional info: TLS error -8157:Certificate extension not found.
>> [root at iparpl1 ~]# ldapsearch -x -H ldap://iparpl1.mydomain:389 -W &#8211;ZZ
>> OK
>>
>> ===================================== errors iparpl2
>> =====================================
>> - messages in screen or std output
>> KO normal because the master doesn't connect to replica in second interface
>> Connection from replica to master is OK.
>> Start listening on required ports for remote master check
>> Get credentials to log in to remote master
>> Check SSH connection to remote master
>> Execute check on remote master
>> Check connection from master to remote replica 'iparpl2.green.mydomain':
>>     Directory Service: Unsecure port (389): FAILED
>>     Directory Service: Secure port (636): FAILED
>>     Kerberos KDC: TCP (88): FAILED
>>     Kerberos KDC: UDP (88): WARNING
>>     Kerberos Kpasswd: TCP (464): FAILED
>>     Kerberos Kpasswd: UDP (464): WARNING
>>     HTTP Server: Unsecure port (80): FAILED
>>     HTTP Server: Secure port (443): FAILED
>> The following UDP ports could not be verified as open: 88, 464
>> This can happen if they are already bound to an application
>> and ipa-replica-conncheck cannot attach own UDP responder.
>>
>> Remote master check failed with following error message(s):
>> Warning: Permanently added 'ipasrv.mydomain,110.0.0.2' (ECDSA) to the list of
>> known hosts.
>> Port check failed! Inaccessible port(s): 389 (TCP), 636 (TCP), 88 (TCP), 464
>> (TCP), 80 (TCP), 443 (TCP)
>> Connection check failed!
>> Please fix your network settings according to error messages above.
>> If the check results are not valid it can be skipped with --skip-conncheck
>> parameter.
> 
> My guess is that you use different name for each interface, right? I'm afraid
> that it can't work, FreeIPA doesn't support that.
> 
> Generally, setups like this do not work very well when Kerberos is in the mix.
> 
> You can try to add both IP addresses to A record for the multi-homed replica
> but then you will depend on failover between those two IP addresses etc...
> 

Posting a related RFE ticket, for reference:

[RFE] IPA install does not bind services to an particular IP/interface
https://fedorahosted.org/freeipa/ticket/3338

Martin



From dpal at redhat.com  Fri Mar  7 15:12:43 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 07 Mar 2014 10:12:43 -0500
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <53189A86.7000707@redhat.com>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
Message-ID: <5319E1EB.1060304@redhat.com>

On 03/06/2014 10:55 AM, Petr Spacek wrote:
> On 6.3.2014 14:32, Petr Spacek wrote:
>> now it is the right time to propose topics for theses in the next 
>> university
>> year.
>
> I propose "[RFE] IPA should support and manage DNS sites"
> https://fedorahosted.org/freeipa/ticket/2008
>
> It is rotting in the backlog and we are not going to touch it any time 
> soon.
>
> There is very low amount of 'theory' behind it but IMHO it is complex 
> enough:
> - Some theoretical analysis of our proposal sounds like a good idea. 
> We don't know if it is the best way or not.
> - Some testing with various *real* non-SSSD clients will be helpful.
> - Analysis how this can work with DNSSEC will be helpful.
> - This feature needs API/CLI/UI design. It is not clear how the 
> workflow should look like etc.
> - Support for roaming clients (in bind-dyndb-ldap) is missing.
>
> The scope can be changed as necessary.
>

We need to check if those are still relevant
* 
https://thesis-managementsystem.rhcloud.com/topic/show/179/java-loginmodule-using-gssapi 
<- I heard JBoss guys are fixing it
* We are talking to Mongo about this: 
https://thesis-managementsystem.rhcloud.com/topic/show/95/gssapi-auth-plugin-for-mongodb- 
I would consider pushing it lower in priority
* Is this still not implemented: 
https://thesis-managementsystem.rhcloud.com/topic/show/14/support-the-native-ipa-sudo-schema- 
?
* Is this really needed any more? 
https://thesis-managementsystem.rhcloud.com/topic/show/13/document-the-internals-of-libldb-and-create-an-example-module-and-example-back-end 
It looks like Yassir's document covers a lot.
* This 
https://thesis-managementsystem.rhcloud.com/topic/show/12/implement-support-for-additional-maps-for-the-sssd-fast-cache 
is still relevant but not a super high priority.
* It is unclear whether this is needed any more: 
https://thesis-managementsystem.rhcloud.com/topic/show/11/implement-3rd-party-id-mapper-in-sssd- 
seems like people can either use existing mapper (green field case) or 
already have UID/GID that they need to put into the central server.
* This one is taken: 
https://thesis-managementsystem.rhcloud.com/topic/show/10/create-openlmi-provider-for-management-of-the-client-components 
right?
* 
https://thesis-managementsystem.rhcloud.com/topic/show/7/central-management-of-automount-locations-in-freeipa 
- does not seem like something worth time
* This one would be really nice: 
https://thesis-managementsystem.rhcloud.com/topic/show/6/reporting-capability-in-freeipa
* And this one would be nice too: 
https://thesis-managementsystem.rhcloud.com/topic/show/5/time-based-account-policies-in-freeipa

Here are couple more IPA ones that came to mind:
https://fedorahosted.org/freeipa/ticket/4008
https://fedorahosted.org/freeipa/ticket/3656
https://fedorahosted.org/freeipa/ticket/4062
https://fedorahosted.org/freeipa/ticket/1225 <- came up 3 times during 
this week (registering external certs, uploading XML token files etc.) 
May be it is a special IPA command like: ipa upload-and-run that would 
use scp to copy file to the server and then call a command on the server 
side using this file. Details need to be worked out.

On SSSD side I used a keyword to try to group all the tickets related to 
the state/status/health of SSSD.
Here is what I got: 
https://fedorahosted.org/sssd/query?status=assigned&status=new&status=reopened&keywords=~Status&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&order=priority 
most in 1.13 so too soon but still there may be some work we can offer.


GNOME Keyring work
https://fedorahosted.org/sssd/ticket/2221
https://fedorahosted.org/sssd/ticket/2222

UID/GID solution
https://fedorahosted.org/sssd/ticket/1715

Chaining access providers:
https://fedorahosted.org/sssd/ticket/1326

One can dig more into 14-15 releases to see if there is anything else 
worth looking into.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From artjazz at free.fr  Fri Mar  7 15:29:14 2014
From: artjazz at free.fr (artjazz at free.fr)
Date: Fri, 07 Mar 2014 16:29:14 +0100
Subject: [Freeipa-users] install IPA replica multi-hosts (ipa packages
	version 3.3.3-18)
In-Reply-To: <5319DB9A.2090809@redhat.com>
References: <1394198167.5319c6977ca6d@imp.free.fr>
	<5319DB9A.2090809@redhat.com>
Message-ID: <1394206154.5319e5ca7b4be@imp.free.fr>

Selon Petr Spacek <pspacek at redhat.com>:

> On 7.3.2014 14:16, artjazz at free.fr wrote:
> > I want to install ipa server with a replica. The replica has 2 NICs : the
> ipa
> > server is connected on the first interface and all the clients are
> connected on
> > the second interface. The two networks are completely separated, 2 subnets
> and
> > not routed.
> I'm curious - what is the reasoning behind this? :-)

The goal is to separate the administration flux and the userland flux.

>
> > I'am wondering if this kind of configuration is supported with IPA.
> >
> > Ipa server has been installed with success on the first interface:
> >
> >
> > First, I prepared the replica on its first interface name (that which is on
> the
> > same network as the ipa server), install it with success. In this case the
> > ipa-client-install fails;
> > See below ==== errors ipacli1 ====
> See my reply below :-)
>
> > Second, I prepared the replica on its second interface name (that which is
> on
> > the same network as the ipa client). This case is worst I'm even not able
> to
> > install the replica. The installation fails with the following errors , see
> > below ==== errors iparpl2 ====
> I'm not sure I understand what you did.
>
> You have installed the replica on one machine and then you have tried to
> install the replica again on the same machine? I guess I have misunderstood
> something ...

No, to test it and show the difference between installation of my replica, I use
a 2nd one (iparpl2).

>
> > Thanks a lot for your help.
> >
> > ===================================== errors ipacli1
> > =====================================
> > - messages in screen or std output:
> > Skip iparpl1.blue.mydomain: cannot verify if this is an IPA server
> > Failed to verify that iparpl1.blue.mydomain is an IPA Server.
> >
> > - messages in log /var/log/ipaclient-install.log:
> > 2014-03-07T12:20:24Z DEBUG [LDAP server check]
> > 2014-03-07T12:20:24Z DEBUG Verifying that iparpl1.blue.mydomain (realm
> None) is
> > an IPA server
> > 2014-03-07T12:20:24Z DEBUG Init LDAP connection to: iparpl1.blue.mydomain
> > 2014-03-07T12:20:29Z DEBUG wait_for_open_ports: iparpl1.blue.mydomain [389]
> > timeout 10
> > 2014-03-07T12:20:34Z DEBUG Error checking LDAP: [Errno -2] Name or service
> not
> > known
> The problem is that your client can't resolve name of the server.

I agree and it's showed below by ldapsearch command.

>
> > 2014-03-07T12:20:34Z WARNING Skip iparpl1.blue.mydomain: cannot verify if
> this
> > is an IPA server
> >
> > - check in iparpl1
> > [root at iparpl1 ~]# ipactl status
> > Directory Service: RUNNING
> > krb5kdc Service: RUNNING
> > kadmin Service: RUNNING
> > ipa_memcached Service: RUNNING
> > httpd Service: RUNNING
> > pki-tomcatd Service: RUNNING
> > ipa-otpd Service: RUNNING
> > ipa: INFO: The ipactl command was successful
> >
> > [root at iparpl1 ~]# ldapsearch -x -H ldap://iparpl1.blue.mydomain:389 -W -ZZ
> > ldap_start_tls: Connect error (-11)
> > 	additional info: TLS error -8157:Certificate extension not found.
> > [root at iparpl1 ~]# ldapsearch -x -H ldap://iparpl1.mydomain:389 -W &#8211;ZZ
> > OK
> >
> > ===================================== errors iparpl2
> > =====================================
> > - messages in screen or std output
> > KO normal because the master doesn't connect to replica in second interface
> > Connection from replica to master is OK.
> > Start listening on required ports for remote master check
> > Get credentials to log in to remote master
> > Check SSH connection to remote master
> > Execute check on remote master
> > Check connection from master to remote replica 'iparpl2.green.mydomain':
> >     Directory Service: Unsecure port (389): FAILED
> >     Directory Service: Secure port (636): FAILED
> >     Kerberos KDC: TCP (88): FAILED
> >     Kerberos KDC: UDP (88): WARNING
> >     Kerberos Kpasswd: TCP (464): FAILED
> >     Kerberos Kpasswd: UDP (464): WARNING
> >     HTTP Server: Unsecure port (80): FAILED
> >     HTTP Server: Secure port (443): FAILED
> > The following UDP ports could not be verified as open: 88, 464
> > This can happen if they are already bound to an application
> > and ipa-replica-conncheck cannot attach own UDP responder.
> >
> > Remote master check failed with following error message(s):
> > Warning: Permanently added 'ipasrv.mydomain,110.0.0.2' (ECDSA) to the list
> of
> > known hosts.
> > Port check failed! Inaccessible port(s): 389 (TCP), 636 (TCP), 88 (TCP),
> 464
> > (TCP), 80 (TCP), 443 (TCP)
> > Connection check failed!
> > Please fix your network settings according to error messages above.
> > If the check results are not valid it can be skipped with --skip-conncheck
> > parameter.
>
> My guess is that you use different name for each interface, right? I'm afraid
> that it can't work, FreeIPA doesn't support that.

Right about using different name for each interface.
I would like to be sure that this architecture is not supported by FreeIPA.

>
> Generally, setups like this do not work very well when Kerberos is in the
> mix.

I think so !!!

>
> You can try to add both IP addresses to A record for the multi-homed replica
> but then you will depend on failover between those two IP addresses etc...

You're right with round robin included in bind.
I can recompile bind packages without round robin but my goal is to be very
close to the standard distribution.

>
> --
> Petr^2 Spacek
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>




From rmeggins at redhat.com  Fri Mar  7 15:34:08 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Fri, 07 Mar 2014 08:34:08 -0700
Subject: [Freeipa-users] IPA DNS command line tools and JSON interface
Message-ID: <5319E6F0.5040708@redhat.com>

tl;dr - A lot of detail about working with the IPA DNS command line 
interfaces and JSON interfaces.

I'm working on integrating IPA with OpenStack Designate (DNSaaS), using 
the /ipa/json interface.  I've had some Q&A with the IPA DNS developer 
(Thanks Petr Spacek!) that I thought would be useful to share.

1) How to specify hosts and domains with the ipa dnsrecord-* commands

IPA uses standard conventions used in DNS 'master files':
http://tools.ietf.org/html/rfc1035#section-5

[Quote, *emphasis* was added.]
<domain-name>s make up a large share of the data in the master file.
The labels in the domain name are expressed as character strings and
separated by dots.  Quoting conventions allow arbitrary characters to be
stored in domain names.  *Domain names that end in a dot are called
absolute, and are taken as complete.  Domain names which do not end in a
dot are called relative; the actual domain name is the concatenation of
the relative part with an origin specified in a $ORIGIN*, $INCLUDE, or as
an argument to the master file loading routine.  A relative name is an
error when no origin is available.

<character-string> is expressed in one or two ways: as a contiguous set
of characters without interior spaces, or as a string beginning with a "
and ending with a ".  Inside a " delimited string any character can
occur, except for a " itself, which must be quoted using \ (back slash).

Because these files are text files several special encodings are
necessary to allow arbitrary data to be loaded.  In particular:

                 of the root.

@               A free standing @ is used to denote the current origin.
[End of quotation.]

Please note that this convention applies to *all* names including names 
inside record data (the 'right side').

IPA provides implicit $ORIGIN = name of the zone. It is not possible to 
change this origin explicitly because $ORIGIN value is derived from 
object structure in LDAP.

I.e. all records inside zone example.com. have implicit $ORIGIN = 
example.com.

$ORIGIN *for zone names* is always root domain (.) so it doesn't make 
any difference if you append the trailing dot to zone name or not.

 > However, if I do something like this:
 >
 > $ ipa dnsrecord-add testdomain.com. testdomain.com --mx-rec="5 
mx.testdomain.com."
This effectively creates record:
testdomain.com.testdomain.com. MX 5 mx.testdomain.com.
(All names without trailing dot have been expanded with $ORIGIN = zone 
name.)

 > $ ipa dnsrecord-add testdomain.com. testdomain.com --mx-rec="5 
mx.testdomain.com"
And this:
testdomain.com.testdomain.com. MX 5 mx.testdomain.com.testdomain.com.

 > This creates two MX records for testdomain.com
Because you have specified two distinct records. The $ORIGIN (= zone 
name) was appended automatically to all names without trailing dot.

 > NOTE that this does not work:
 > $ ipa dnsrecord-add testdomain.com. testdomain.com. --mx-rec="5 
mx.testdomain.com"
 > ipa: ERROR: invalid 'name': empty DNS label
This is a bug in IPA CLI. Please open an IPA ticket.

https://fedorahosted.org/freeipa/ticket/4232

This command should create record like this:
testdomain.com. MX 5 mx.testdomain.com.testdomain.com.

I think that this is not what you expect (see the value on on the right 
side).

You should either use relative names
$ ipa dnsrecord-add testdomain.com. @ --mx-rec="5 mx"

or use FQDN with trailing dot:
$ ipa dnsrecord-add testdomain.com. @ --mx-rec="5 mx.testdomain.com."

Character @ is a special trick from RFC to specify "origin", i.e. in 
context of IPA the zone name.

2) How to modify DNS records
 > Let's say I have
 > Record name: testdomain.com.
 > MX record: 5 mx1.testdomain.com., 10 mx2.testdomain.com.
 >
 > How would I use ipa dnsrecord-mod to change the preference for
 > mx2.testdomain.com. from 10 to 6?
ipa dnsrecord-mod testdomain.com. @ --mx-rec="10 mx2.testdomain.com." 
--mx-pref="6"

In case with multiple records of the same type you have to specify which 
record should be modified.

3) The JSON interface - 
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/

The best JSON API documentation I have found is at 
https://git.fedorahosted.org/cgit/freeipa.git/tree/install/ui/test/data. 
The array argument part of "params" isn't documented, but the dict part is.

The ipa command line tools use RPC, but they use XML.  If you run ipa 
-vv dnsrecord-add ... you can see the XML sent and received. There is a 
bit of work converting from XML to JSON.  e.g.
<array><data><value><string>testdomain.com.</string></value><value><string>testdomain.com</string></value></data></array>
is
["testdomain.com.", "testdomain.com."]

a struct in xml is a json dict:
<struct><member><name>method</name><value><string>dnsrecord_add</string></value></member></struct>
is
{"method":"dnsrecord_add"}

Example JSON for adding a record:
{
     "method": "dnsrecord_add",
     "id": 0,
     "params": [
         ["testdomain.com.", "testdomain.com."],
         {"mxrecord", ["10 mx1.testdomain.com", "20 mx2.testdomain.com."],
           "version", "2.65"}
     ]
}

Example JSON for modifying a record:
{
     "method": "dnsrecord_mod",
     "id": 0,
     "params": [
         ["testdomain.com.", "testdomain.com."],
         {"mxrecord", ["10 mx1.testdomain.com."],
           "mx_part_preference": 5,
           "version", "2.65"}
     ]
}

Example JSON for deleting a record:
{
     "method": "dnsrecord_del",
     "id": 0,
     "params": [
         ["testdomain.com.", "testdomain.com."],
         {"mxrecord", ["10 mx1.testdomain.com."],
           "version", "2.65"}
     ]
}

The JSON response dict contains a key called "errors".  If the value for 
this key is None, the command succeeded, otherwise, the value will 
contain detailed error information about one or more errors encountered.



From dpal at redhat.com  Fri Mar  7 15:57:21 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 07 Mar 2014 10:57:21 -0500
Subject: [Freeipa-users] install IPA replica multi-hosts (ipa packages
 version 3.3.3-18)
In-Reply-To: <1394206154.5319e5ca7b4be@imp.free.fr>
References: <1394198167.5319c6977ca6d@imp.free.fr>
	<5319DB9A.2090809@redhat.com>
	<1394206154.5319e5ca7b4be@imp.free.fr>
Message-ID: <5319EC61.6020105@redhat.com>

On 03/07/2014 10:29 AM, artjazz at free.fr wrote:
> Selon Petr Spacek<pspacek at redhat.com>:
>
>> >  On 7.3.2014 14:16,artjazz at free.fr  wrote:
>>> >  >  I want to install ipa server with a replica. The replica has 2 NICs : the
>> >  ipa
>>> >  >  server is connected on the first interface and all the clients are
>> >  connected on
>>> >  >  the second interface. The two networks are completely separated, 2 subnets
>> >  and
>>> >  >  not routed.
>> >  I'm curious - what is the reasoning behind this?:-)
> The goal is to separate the administration flux and the userland flux.
>
The problem is that it is not that clean.
One server can connect to another on different ports and using different 
protocols for different purposes. And client can actually be a proxy 
that does some admin tasks via LDAP or executes remote administrative 
commands.

I think may be it is better to explore FW rules.
For example create a FW rule that would allow only Kerberos and LDAP 
connections from a set of hosts that would be clients. Hm but that again 
would prevent you from enrolling new systems since the 
ipa-client-install connects to IPA via admin interface during the 
enrollment stage.

May be there is some magic that can be done using DNS zones but I am not 
sure...

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From pviktori at redhat.com  Fri Mar  7 15:57:29 2014
From: pviktori at redhat.com (Petr Viktorin)
Date: Fri, 07 Mar 2014 16:57:29 +0100
Subject: [Freeipa-users] JSON interface (Was: IPA DNS command line tools
 and ~)
In-Reply-To: <5319E6F0.5040708@redhat.com>
References: <5319E6F0.5040708@redhat.com>
Message-ID: <5319EC69.4070808@redhat.com>

On 03/07/2014 04:34 PM, Rich Megginson wrote:
[...]
> The ipa command line tools use RPC, but they use XML.  If you run ipa
> -vv dnsrecord-add ... you can see the XML sent and received. There is a
> bit of work converting from XML to JSON.  e.g.
> <array><data><value><string>testdomain.com.</string></value><value><string>testdomain.com</string></value></data></array> is
["testdomain.com.", "testdomain.com."]
[...]

Note that FreeIPA 4.0 (current git master) will use JSON-RPC by default, 
so you'll no longer need to convert from XML.




It seems the -vv option is quickly becoming very useful for API users. 
Currently the logging is very low-level; in current master I get:

$ ipa -vv ping
ipa: INFO: trying https://vm-244.idm.lab.eng.brq.redhat.com/ipa/session/json
ipa: INFO: Forwarding 'ping' to json server 
'https://vm-244.idm.lab.eng.brq.redhat.com/ipa/session/json'
send: u'POST /ipa/session/json HTTP/1.1\r\nHost: 
vm-244.idm.lab.eng.brq.redhat.com\r\nAccept-Encoding: 
gzip\r\nAccept-Language: en-us\r\nReferer: 
https://vm-244.idm.lab.eng.brq.redhat.com/ipa/xml\r\nCookie: 
ipa_session=da66695e0c3a772a3fe649c3e1d11612;\r\nUser-Agent: 
xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: 
application/json\r\nContent-Length: 64\r\n\r\n{"params": [[], 
{"version": "2.77"}], "method": "ping", "id": 0}'
reply: 'HTTP/1.1 200 Success\r\n'
header: Date: Fri, 07 Mar 2014 15:48:31 GMT
header: Server: Apache/2.4.6 (Fedora) mod_auth_kerb/5.4 mod_nss/2.4.6 
NSS/3.15.3 Basic ECC mod_wsgi/3.4 Python/2.7.5
header: Set-Cookie: ipa_session=da66695e0c3a772a3fe649c3e1d11612; 
Domain=vm-244.idm.lab.eng.brq.redhat.com; Path=/ipa; Expires=Fri, 07 Mar 
2014 16:08:31 GMT; Secure; HttpOnly
header: Vary: Accept-Encoding
header: Content-Encoding: gzip
header: Content-Length: 176
header: Content-Type: application/json; charset=utf-8
body: '{\n    "error": null, \n    "id": 0, \n    "principal": 
"admin at IDM.LAB.ENG.BRQ.REDHAT.COM", \n    "result": {\n 
"summary": "IPA server version 3.3.90GITcb4dcd8. API version 2.77"\n 
}, \n    "version": "3.3.90GITcb4dcd8"\n}'
-----------------------------------------------------
IPA server version 3.3.90GITcb4dcd8. API version 2.77
-----------------------------------------------------

Would it be useful to also log pretty-printed JSON with `-vvv`, so 
adventurous API explorers can just copy and paste?


-- 
Petr?



From jhrozek at redhat.com  Fri Mar  7 15:59:21 2014
From: jhrozek at redhat.com (Jakub Hrozek)
Date: Fri, 7 Mar 2014 16:59:21 +0100
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <5319E1EB.1060304@redhat.com>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>
Message-ID: <20140307155921.GI19071@hendrix.redhat.com>

On Fri, Mar 07, 2014 at 10:12:43AM -0500, Dmitri Pal wrote:
> We need to check if those are still relevant
> * https://thesis-managementsystem.rhcloud.com/topic/show/179/java-loginmodule-using-gssapi
> <- I heard JBoss guys are fixing it
> * We are talking to Mongo about this: https://thesis-managementsystem.rhcloud.com/topic/show/95/gssapi-auth-plugin-for-mongodb-
> I would consider pushing it lower in priority
> * Is this still not implemented: https://thesis-managementsystem.rhcloud.com/topic/show/14/support-the-native-ipa-sudo-schema-
> ?

This topic is being worked on actively. Me and Pavel have been mentoring
the student.

> * Is this really needed any more? https://thesis-managementsystem.rhcloud.com/topic/show/13/document-the-internals-of-libldb-and-create-an-example-module-and-example-back-end
> It looks like Yassir's document covers a lot.

This topic is about ldb, not SSSD, but I agree it's not terribly important.

> * This https://thesis-managementsystem.rhcloud.com/topic/show/12/implement-support-for-additional-maps-for-the-sssd-fast-cache
> is still relevant but not a super high priority.
> * It is unclear whether this is needed any more: https://thesis-managementsystem.rhcloud.com/topic/show/11/implement-3rd-party-id-mapper-in-sssd-
> seems like people can either use existing mapper (green field case)
> or already have UID/GID that they need to put into the central
> server.

I agree.

> * This one is taken: https://thesis-managementsystem.rhcloud.com/topic/show/10/create-openlmi-provider-for-management-of-the-client-components
> right?

This is being worked on by Pavel.

> 
> On SSSD side I used a keyword to try to group all the tickets
> related to the state/status/health of SSSD.
> Here is what I got: https://fedorahosted.org/sssd/query?status=assigned&status=new&status=reopened&keywords=~Status&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&order=priority
> most in 1.13 so too soon but still there may be some work we can
> offer.
> 
> 
> GNOME Keyring work
> https://fedorahosted.org/sssd/ticket/2221
> https://fedorahosted.org/sssd/ticket/2222

These two sounds OK to me, altough they'd require quite a bit of
mentoring.

> 
> UID/GID solution
> https://fedorahosted.org/sssd/ticket/1715
> 
> Chaining access providers:
> https://fedorahosted.org/sssd/ticket/1326

I'm not sure these two are enough for a thesis..

> 
> One can dig more into 14-15 releases to see if there is anything
> else worth looking into.

What about the validator in ding-libs?

What about developing a set of tests using cwrap?



From dpal at redhat.com  Fri Mar  7 16:04:45 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 07 Mar 2014 11:04:45 -0500
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <20140307155921.GI19071@hendrix.redhat.com>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>
	<20140307155921.GI19071@hendrix.redhat.com>
Message-ID: <5319EE1D.1010207@redhat.com>

On 03/07/2014 10:59 AM, Jakub Hrozek wrote:
> On Fri, Mar 07, 2014 at 10:12:43AM -0500, Dmitri Pal wrote:
>> We need to check if those are still relevant
>> * https://thesis-managementsystem.rhcloud.com/topic/show/179/java-loginmodule-using-gssapi
>> <- I heard JBoss guys are fixing it
>> * We are talking to Mongo about this: https://thesis-managementsystem.rhcloud.com/topic/show/95/gssapi-auth-plugin-for-mongodb-
>> I would consider pushing it lower in priority
>> * Is this still not implemented: https://thesis-managementsystem.rhcloud.com/topic/show/14/support-the-native-ipa-sudo-schema-
>> ?
> This topic is being worked on actively. Me and Pavel have been mentoring
> the student.
>
>> * Is this really needed any more? https://thesis-managementsystem.rhcloud.com/topic/show/13/document-the-internals-of-libldb-and-create-an-example-module-and-example-back-end
>> It looks like Yassir's document covers a lot.
> This topic is about ldb, not SSSD, but I agree it's not terribly important.
>
>> * This https://thesis-managementsystem.rhcloud.com/topic/show/12/implement-support-for-additional-maps-for-the-sssd-fast-cache
>> is still relevant but not a super high priority.
>> * It is unclear whether this is needed any more: https://thesis-managementsystem.rhcloud.com/topic/show/11/implement-3rd-party-id-mapper-in-sssd-
>> seems like people can either use existing mapper (green field case)
>> or already have UID/GID that they need to put into the central
>> server.
> I agree.
>
>> * This one is taken: https://thesis-managementsystem.rhcloud.com/topic/show/10/create-openlmi-provider-for-management-of-the-client-components
>> right?
> This is being worked on by Pavel.
>
>> On SSSD side I used a keyword to try to group all the tickets
>> related to the state/status/health of SSSD.
>> Here is what I got: https://fedorahosted.org/sssd/query?status=assigned&status=new&status=reopened&keywords=~Status&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&order=priority
>> most in 1.13 so too soon but still there may be some work we can
>> offer.
>>
>>
>> GNOME Keyring work
>> https://fedorahosted.org/sssd/ticket/2221
>> https://fedorahosted.org/sssd/ticket/2222
> These two sounds OK to me, altough they'd require quite a bit of
> mentoring.
>
>> UID/GID solution
>> https://fedorahosted.org/sssd/ticket/1715
>>
>> Chaining access providers:
>> https://fedorahosted.org/sssd/ticket/1326
> I'm not sure these two are enough for a thesis..

I think at least the first one is.
You change UID and/or GID on the server. And then you need a mechanism 
to signal to the clients that they need to do cleanup. I was thinking 
about OpenLMI integration in this case and this sounds like a research 
topic to me.

>
>> One can dig more into 14-15 releases to see if there is anything
>> else worth looking into.
> What about the validator in ding-libs?

I am planning to do some prototyping and publish a design, would it rain 
the parade?

>
> What about developing a set of tests using cwrap?

+1

>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/





From abokovoy at redhat.com  Fri Mar  7 16:18:50 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Fri, 7 Mar 2014 18:18:50 +0200
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <5319E1EB.1060304@redhat.com>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>
Message-ID: <20140307161850.GU16644@redhat.com>

On Fri, 07 Mar 2014, Dmitri Pal wrote:
>On 03/06/2014 10:55 AM, Petr Spacek wrote:
>>On 6.3.2014 14:32, Petr Spacek wrote:
>>>now it is the right time to propose topics for theses in the next 
>>>university
>>>year.
>>
>>I propose "[RFE] IPA should support and manage DNS sites"
>>https://fedorahosted.org/freeipa/ticket/2008
>>
>>It is rotting in the backlog and we are not going to touch it any 
>>time soon.
>>
>>There is very low amount of 'theory' behind it but IMHO it is 
>>complex enough:
>>- Some theoretical analysis of our proposal sounds like a good 
>>idea. We don't know if it is the best way or not.
>>- Some testing with various *real* non-SSSD clients will be helpful.
>>- Analysis how this can work with DNSSEC will be helpful.
>>- This feature needs API/CLI/UI design. It is not clear how the 
>>workflow should look like etc.
>>- Support for roaming clients (in bind-dyndb-ldap) is missing.
>>
>>The scope can be changed as necessary.
>>
>
>We need to check if those are still relevant
>* https://thesis-managementsystem.rhcloud.com/topic/show/179/java-loginmodule-using-gssapi 
><- I heard JBoss guys are fixing it
>* We are talking to Mongo about this: https://thesis-managementsystem.rhcloud.com/topic/show/95/gssapi-auth-plugin-for-mongodb- 
>I would consider pushing it lower in priority
There is already SASL support in MongoDB, though existing SASL GSSAPI authentication
is only available in MongoDB Enterprise.
http://docs.mongodb.org/manual/tutorial/control-access-to-mongodb-with-kerberos-authentication/

-- 
/ Alexander Bokovoy



From jhrozek at redhat.com  Fri Mar  7 16:24:19 2014
From: jhrozek at redhat.com (Jakub Hrozek)
Date: Fri, 7 Mar 2014 17:24:19 +0100
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <5319EE1D.1010207@redhat.com>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>
	<20140307155921.GI19071@hendrix.redhat.com>
	<5319EE1D.1010207@redhat.com>
Message-ID: <20140307162419.GL19071@hendrix.redhat.com>

On Fri, Mar 07, 2014 at 11:04:45AM -0500, Dmitri Pal wrote:
> On 03/07/2014 10:59 AM, Jakub Hrozek wrote:
> >On Fri, Mar 07, 2014 at 10:12:43AM -0500, Dmitri Pal wrote:
> >>We need to check if those are still relevant
> >>* https://thesis-managementsystem.rhcloud.com/topic/show/179/java-loginmodule-using-gssapi
> >><- I heard JBoss guys are fixing it
> >>* We are talking to Mongo about this: https://thesis-managementsystem.rhcloud.com/topic/show/95/gssapi-auth-plugin-for-mongodb-
> >>I would consider pushing it lower in priority
> >>* Is this still not implemented: https://thesis-managementsystem.rhcloud.com/topic/show/14/support-the-native-ipa-sudo-schema-
> >>?
> >This topic is being worked on actively. Me and Pavel have been mentoring
> >the student.
> >
> >>* Is this really needed any more? https://thesis-managementsystem.rhcloud.com/topic/show/13/document-the-internals-of-libldb-and-create-an-example-module-and-example-back-end
> >>It looks like Yassir's document covers a lot.
> >This topic is about ldb, not SSSD, but I agree it's not terribly important.
> >
> >>* This https://thesis-managementsystem.rhcloud.com/topic/show/12/implement-support-for-additional-maps-for-the-sssd-fast-cache
> >>is still relevant but not a super high priority.
> >>* It is unclear whether this is needed any more: https://thesis-managementsystem.rhcloud.com/topic/show/11/implement-3rd-party-id-mapper-in-sssd-
> >>seems like people can either use existing mapper (green field case)
> >>or already have UID/GID that they need to put into the central
> >>server.
> >I agree.
> >
> >>* This one is taken: https://thesis-managementsystem.rhcloud.com/topic/show/10/create-openlmi-provider-for-management-of-the-client-components
> >>right?
> >This is being worked on by Pavel.
> >
> >>On SSSD side I used a keyword to try to group all the tickets
> >>related to the state/status/health of SSSD.
> >>Here is what I got: https://fedorahosted.org/sssd/query?status=assigned&status=new&status=reopened&keywords=~Status&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&order=priority
> >>most in 1.13 so too soon but still there may be some work we can
> >>offer.
> >>
> >>
> >>GNOME Keyring work
> >>https://fedorahosted.org/sssd/ticket/2221
> >>https://fedorahosted.org/sssd/ticket/2222
> >These two sounds OK to me, altough they'd require quite a bit of
> >mentoring.
> >
> >>UID/GID solution
> >>https://fedorahosted.org/sssd/ticket/1715
> >>
> >>Chaining access providers:
> >>https://fedorahosted.org/sssd/ticket/1326
> >I'm not sure these two are enough for a thesis..
> 
> I think at least the first one is.
> You change UID and/or GID on the server. And then you need a
> mechanism to signal to the clients that they need to do cleanup. I
> was thinking about OpenLMI integration in this case and this sounds
> like a research topic to me.

I see, this might be an interesting topic. I was initiall only thinking
about the change of the ID itself.

> 
> >
> >>One can dig more into 14-15 releases to see if there is anything
> >>else worth looking into.
> >What about the validator in ding-libs?
> 
> I am planning to do some prototyping and publish a design, would it
> rain the parade?

Ah, I remember you said something along these lines yesterday on our
meeting. In that case it makes little sense to add the validation as a
topic.

> 
> >
> >What about developing a set of tests using cwrap?
> 
> +1

I filed https://fedorahosted.org/sssd/ticket/2277



From erinn.looneytriggs at gmail.com  Fri Mar  7 16:31:09 2014
From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs)
Date: Fri, 07 Mar 2014 09:31:09 -0700
Subject: [Freeipa-users] JSON interface (Was: IPA DNS command line tools
 and ~)
In-Reply-To: <5319EC69.4070808@redhat.com>
References: <5319E6F0.5040708@redhat.com> <5319EC69.4070808@redhat.com>
Message-ID: <5319F44D.20506@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/07/2014 08:57 AM, Petr Viktorin wrote:
> On 03/07/2014 04:34 PM, Rich Megginson wrote: [...]
>> The ipa command line tools use RPC, but they use XML.  If you run
>> ipa -vv dnsrecord-add ... you can see the XML sent and received.
>> There is a bit of work converting from XML to JSON.  e.g. 
>> <array><data><value><string>testdomain.com.</string></value><value><string>testdomain.com</string></value></data></array>
>>
>> 
is
> ["testdomain.com.", "testdomain.com."] [...]
> 
> Note that FreeIPA 4.0 (current git master) will use JSON-RPC by
> default, so you'll no longer need to convert from XML.
> 
> 
> 
> 
> It seems the -vv option is quickly becoming very useful for API
> users. Currently the logging is very low-level; in current master I
> get:
> 
> $ ipa -vv ping ipa: INFO: trying 
> https://vm-244.idm.lab.eng.brq.redhat.com/ipa/session/json ipa:
> INFO: Forwarding 'ping' to json server 
> 'https://vm-244.idm.lab.eng.brq.redhat.com/ipa/session/json' send:
> u'POST /ipa/session/json HTTP/1.1\r\nHost: 
> vm-244.idm.lab.eng.brq.redhat.com\r\nAccept-Encoding: 
> gzip\r\nAccept-Language: en-us\r\nReferer: 
> https://vm-244.idm.lab.eng.brq.redhat.com/ipa/xml\r\nCookie: 
> ipa_session=da66695e0c3a772a3fe649c3e1d11612;\r\nUser-Agent: 
> xmlrpclib.py/1.0.1 (by www.pythonware.com)\r\nContent-Type: 
> application/json\r\nContent-Length: 64\r\n\r\n{"params": [[], 
> {"version": "2.77"}], "method": "ping", "id": 0}' reply: 'HTTP/1.1
> 200 Success\r\n' header: Date: Fri, 07 Mar 2014 15:48:31 GMT 
> header: Server: Apache/2.4.6 (Fedora) mod_auth_kerb/5.4
> mod_nss/2.4.6 NSS/3.15.3 Basic ECC mod_wsgi/3.4 Python/2.7.5 
> header: Set-Cookie: ipa_session=da66695e0c3a772a3fe649c3e1d11612; 
> Domain=vm-244.idm.lab.eng.brq.redhat.com; Path=/ipa; Expires=Fri,
> 07 Mar 2014 16:08:31 GMT; Secure; HttpOnly header: Vary:
> Accept-Encoding header: Content-Encoding: gzip header:
> Content-Length: 176 header: Content-Type: application/json;
> charset=utf-8 body: '{\n    "error": null, \n    "id": 0, \n
> "principal": "admin at IDM.LAB.ENG.BRQ.REDHAT.COM", \n    "result":
> {\n "summary": "IPA server version 3.3.90GITcb4dcd8. API version
> 2.77"\n }, \n    "version": "3.3.90GITcb4dcd8"\n}' 
> ----------------------------------------------------- IPA server
> version 3.3.90GITcb4dcd8. API version 2.77 
> -----------------------------------------------------
> 
> Would it be useful to also log pretty-printed JSON with `-vvv`, so 
> adventurous API explorers can just copy and paste?
> 
> 

Umm, yes please!

- -Erinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJTGfRMAAoJEFg7BmJL2iPOUxkH/jk0mRZugXGbYVFyKxBRflfa
1VSbqPt91kUdruePkD9frixl8PCZAm/p32BjPNR/S7j8t2S0r7INMDyDIM08gu4v
ZXlTl6i46WUdnDWExeOqX6Cg4PV3DXThcEsGq/bFQ2rFoIw84ehkD5EV3b1lw3dw
ybKphlwi68+9ks6588s1HeQQYUzixNcFNE+/I0yXdI8lga0xnob5m6EixVYR+FOH
kwB4KWr8JXRPJMq+qtpRPoUNspFtTHoQxGU2M3qSBJ/QmkK05cFVVA+viqvgKdJ/
zF7tZXc15QxDXI3yqkEnqClet8CU6PplUK3ma6BjPm5yznI/TiiXb1g8YA97Qks=
=GiYE
-----END PGP SIGNATURE-----



From pviktori at redhat.com  Fri Mar  7 16:45:30 2014
From: pviktori at redhat.com (Petr Viktorin)
Date: Fri, 07 Mar 2014 17:45:30 +0100
Subject: [Freeipa-users] JSON interface
In-Reply-To: <5319F44D.20506@gmail.com>
References: <5319E6F0.5040708@redhat.com> <5319EC69.4070808@redhat.com>
	<5319F44D.20506@gmail.com>
Message-ID: <5319F7AA.3020308@redhat.com>

On 03/07/2014 05:31 PM, Erinn Looney-Triggs wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/07/2014 08:57 AM, Petr Viktorin wrote:
>> On 03/07/2014 04:34 PM, Rich Megginson wrote: [...]
>>> The ipa command line tools use RPC, but they use XML.  If you run
>>> ipa -vv dnsrecord-add ... you can see the XML sent and received.
>>> There is a bit of work converting from XML to JSON.  e.g.
>>> <array><data><value><string>testdomain.com.</string></value><value><string>testdomain.com</string></value></data></array>
>>>
>>>
> is
>> ["testdomain.com.", "testdomain.com."] [...]
>>
>> Note that FreeIPA 4.0 (current git master) will use JSON-RPC by
>> default, so you'll no longer need to convert from XML.
>>
>>
>>
>>
>> It seems the -vv option is quickly becoming very useful for API
>> users. Currently the logging is very low-level; [...]
>>
>> Would it be useful to also log pretty-printed JSON with `-vvv`, so
>> adventurous API explorers can just copy and paste?
>>
>>
>
> Umm, yes please!

Filed as: https://fedorahosted.org/freeipa/ticket/4233


To the ticket I attached a crude patch I've been using; it can act as a 
starting point if someone wants to jump on this.

-- 
Petr?



From bnordgren at fs.fed.us  Fri Mar  7 20:38:29 2014
From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS)
Date: Fri, 7 Mar 2014 20:38:29 +0000
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <20140307162419.GL19071@hendrix.redhat.com>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>	<20140307155921.GI19071@hendrix.redhat.com>
	<5319EE1D.1010207@redhat.com>
	<20140307162419.GL19071@hendrix.redhat.com>
Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6926F2@001FSN2MPN1-045.001f.mgd2.msft.net>


> > >>UID/GID solution
> > >>https://fedorahosted.org/sssd/ticket/1715
> > >>
> > >>Chaining access providers:
> > >>https://fedorahosted.org/sssd/ticket/1326
> > >I'm not sure these two are enough for a thesis..
> >
> > I think at least the first one is.
> > You change UID and/or GID on the server. And then you need a
> mechanism
> > to signal to the clients that they need to do cleanup. I was thinking
> > about OpenLMI integration in this case and this sounds like a research
> > topic to me.
>
> I see, this might be an interesting topic. I was initiall only thinking about the
> change of the ID itself.

Something perhaps more worthy of thesis attention may be an examination of what it would take to start treating UID/GID as a completely internal machine representation which does not need to be shared. That is, it is important to have a common set of principal names for users, hosts and services in the Kerberos store; within an organization, it's important to have common groups of these principals in an LDAP store; but the importance of having all UIDs and GIDs be identical seems to be dwindling.

Authentication via Kerberos doesn't require it.
Authorization using Kerberos principals doesn't require it.
Moving files back and forth with SCP doesn't require it.
An NFSv4 fileserver w/krb5 security doesn't require it.
A CIFS fileserver doesn't require it.

What still requires that UID/GIDs need to be synchronized?

(I'm not necessarily asking you all right now. I think it might be a good thesis question, along with the follow-on: how much work would it take to migrate off of UID/GID synchronization for good?)

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.




From mail at willsheldon.com  Fri Mar  7 20:44:45 2014
From: mail at willsheldon.com (Will Sheldon)
Date: Fri, 7 Mar 2014 12:44:45 -0800
Subject: [Freeipa-users] Change user login name? (uid in LDAP)
Message-ID: <04BCB0C7DFC9406DAE31D564574D472D@willsheldon.com>


Hello all :)

We have an internal process that requires the renaming of users from time to time (user gets married, changes name). This requires changing the "login name? as it?s called in the GUI, (or uid in LDAP).

There doesn?t currently appear to be any method for doing so other than to delete the user and create a new one, then update the uidNumber and gidNumber to the old values using the ipa modify-user command.

Is there a better way? I?ve looked through all the docs and hunted through the mailing list archives but can?t find anything...


W.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140307/d51a5b30/attachment.htm>

From rcritten at redhat.com  Fri Mar  7 22:25:43 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Fri, 07 Mar 2014 17:25:43 -0500
Subject: [Freeipa-users] Change user login name? (uid in LDAP)
In-Reply-To: <04BCB0C7DFC9406DAE31D564574D472D@willsheldon.com>
References: <04BCB0C7DFC9406DAE31D564574D472D@willsheldon.com>
Message-ID: <531A4767.1040908@redhat.com>

Will Sheldon wrote:
>
> Hello all :)
>
> We have an internal process that requires the renaming of users from
> time to time (user gets married, changes name). This requires changing
> the "login name? as it?s called in the GUI, (or uid in LDAP).
>
> There doesn?t currently appear to be any method for doing so other than
> to delete the user and create a new one, then update the uidNumber and
> gidNumber to the old values using the ipa modify-user command.
>
> Is there a better way? I?ve looked through all the docs and hunted
> through the mailing list archives but can?t find anything...
>
>
> W.

I'm not really a GUI guy but you can do it on the CLI using the --rename 
option (I forget when we added this but it's in 3.0+):

Here I'll add a single woman named Sarah Robertson who finds Mr. Right 
and takes his name, Jacobs.

$ ipa user-add --first=Sarah --last=Robertson sroberts
---------------------
Added user "sroberts"
---------------------
   User login: sroberts
   First name: Sarah
   Last name: Robertson
   Full name: Sarah Robertson
   Display name: Sarah Robertson
   Initials: SR
   Home directory: /home/sroberts
   GECOS field: Sarah Robertson
   Login shell: /bin/sh
   Kerberos principal: sroberts at EXAMPLE.COM
   Email address: sroberts at example.com
   UID: 1717600001
   GID: 1717600001
   Password: False
   Kerberos keys available: False
$ ipa user-mod --rename=sjacobs sroberts
------------------------
Modified user "sroberts"
------------------------
   User login: sjacobs
   First name: Sarah
   Last name: Roberts
   Home directory: /home/sroberts
   Login shell: /bin/sh
   Email address: sroberts at example.com
   UID: 1717600001
   GID: 1717600001
   Account disabled: False
   Password: False
   Member of groups: ipausers
   Kerberos keys available: False

Note that there are a bunch of values left to be updated including the 
last name, GECOS, Full Name and potentially homedir and e-mail addr.

rob



From treydock at gmail.com  Fri Mar  7 22:26:46 2014
From: treydock at gmail.com (Trey Dockendorf)
Date: Fri, 7 Mar 2014 16:26:46 -0600
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <53191ED7.1000502@redhat.com>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>
	<53191ED7.1000502@redhat.com>
Message-ID: <CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>

On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal <dpal at redhat.com> wrote:
> On 03/05/2014 06:24 PM, Trey Dockendorf wrote:
>>
>> Correction from my email, the condition that sets if a 389DS user is
>> proxied to pam_krb5 is the "pamFilter", sorry.
>>
>> On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorf<treydock at gmail.com>
>> wrote:
>>>
>>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<dpal at redhat.com>  wrote:
>>>>
>>>> On 03/03/2014 07:47 PM, Simo Sorce wrote:
>>>>>
>>>>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
>>>>>>
>>>>>> Is it possible with FreeIPA to use an external KDC or pass some or all
>>>>>> authentication to an external KDC?  The KDC at our University may give
>>>>>> me a one way trust if I describe my implementation plan for FreeIPA.
>>>>>> Currently I use 389DS with PAM pass through using untrusted pam_krb5.
>>>>>> I'd like to fully utilize FreeIPA without managing passwords since all
>>>>>> my users already have University accounts.  I just want to manage
>>>>>> authorization for my systems, not authentication.
>>>>>
>>>>> You could set up a kerberos trust manually but at the moment we do not
>>>>> support it in the code or the utilities.
>>>>>
>>>>> SSSD in particular will have no place to find identity information if
>>>>> all you have is a kerberos trust, you'd need also an external identity
>>>>> store to point to, but there is no builtin code in SSSD to link the 2
>>>>> domain at this point.
>>>>>
>>>>> We are planning on working on IPA-to-IPA trust, and possibly
>>>>> IPA-to-*other* so any requirements you can throw at us will be made
>>>>> part
>>>>> of the consideration and planning to add this kind of functionality in
>>>>> the future.
>>>>>
>>>>> NM B HTH,
>>>>> Simo.
>>>>>
>>>> Can you describe your workflows because I have some idea in mind?
>>>
>>> Right now the workflow I have with 389ds using PAM Pass Through Auth
>>> is the following:
>>>
>>> For users with the proper attribute defined in 'pamIDAttr'
>>>
>>> client --->  389DS --->  389DS server's pam_krb5 --->  Campus KDC
>>>
>>> For users lacking the attribute for 'pamIDAttr'
>>>
>>> client --->  389DS
>>>
>>> The Kerberos setup currently on the 389DS server is untrusted (no
>>> krb5.keytab).
>>>
>>> The ideal workflow with FreeIPA would be
>>>
>>> client ---->  IPA --->  Campus KDC
>>>
>>>> Would you be OK if your accounts would be in IPA but the authentication
>>>> would be proxied out?
>>>
>>> This is fine with me.  Does the idea you describe allow for some
>>> authentication (ie system accounts or internal accounts) to be handled
>>> by FreeIPA?  That's the benefit to us when using PAM Pass Through
>>> Auth, is that we can conditionally proxy out the authentication.
>>>
>>>> The idea is that you can use OTP RADIUS capability to proxy passwords to
>>>> your main KDC.
>>>>
>>>> client ---OTP--->  IPA --->  OTP Proxy --->  RADIUS --->  Your KDC
>>>>
>>>> Disclaimer: that would defeat the purpose of Kerberos and the password
>>>> will
>>>> be sent over the wire but it seems that you are already in this setup.
>>>>
>>>> Would you be interested to give it a try?
>>>
>>> Absolutely.  Right now I need to contact our campus IT group and let
>>> them know what I require to make our setup work.  I have been told a
>>> one way trust is the most I can get.  Will that facilitate what you
>>> described?
>
>
> You do not need trust for that setup. Any user account (i am not sure about
> special system accounts that are not created in cn=users) would be able to
> go to external RADIUS server.
>
>
>>>
>>>> Would require latest SSSD and kerberos library on the client though but
>>>> would work with LDAP binds too.
>>>
>>> Latest SSSD and Kerberos that's available in EL6, or latest upstream?
>
>
> Upstream.
>

Is it possible use these latest versions in EL6, or is using Fedora
19+ the only feasible way to do this?  If using EL6 is not possible,
is it going to be something possible in EL7?

> Please take a look at the design page: http://www.freeipa.org/page/V3/OTP -
> that will give you an idea about the internals.
>
> Latest upstream UI should be able to allow to configure external RADIUS
> servers and then change per user policy to proxy via RADIUS. Then you can
> try binding with LDAP to IPA using password from your main KDC.
> Then you can use SSSD on the same system to try to authenticate using
> Kerberos. You will create a new user, set him to use RADIUS server for
> authentication and then try to su to this user or ssh into the box as that
> user. It should work and klist should report a TGT for this user on the box.
>

Thanks for the info.  I'll see if I can piece together how to make this work.

>
>>>
>>>>
>>>> --
>>>> 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 at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users



From simo at redhat.com  Fri Mar  7 22:32:05 2014
From: simo at redhat.com (Simo Sorce)
Date: Fri, 07 Mar 2014 17:32:05 -0500
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6926F2@001FSN2MPN1-045.001f.mgd2.msft.net>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>	<20140307155921.GI19071@hendrix.redhat.com>
	<5319EE1D.1010207@redhat.com>
	<20140307162419.GL19071@hendrix.redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6926F2@001FSN2MPN1-045.001f.mgd2.msft.net>
Message-ID: <1394231525.14651.146.camel@willson.li.ssimo.org>

On Fri, 2014-03-07 at 20:38 +0000, Nordgren, Bryce L -FS wrote:
> > > >>UID/GID solution
> > > >>https://fedorahosted.org/sssd/ticket/1715
> > > >>
> > > >>Chaining access providers:
> > > >>https://fedorahosted.org/sssd/ticket/1326
> > > >I'm not sure these two are enough for a thesis..
> > >
> > > I think at least the first one is.
> > > You change UID and/or GID on the server. And then you need a
> > mechanism
> > > to signal to the clients that they need to do cleanup. I was thinking
> > > about OpenLMI integration in this case and this sounds like a research
> > > topic to me.
> >
> > I see, this might be an interesting topic. I was initiall only thinking about the
> > change of the ID itself.
> 
> Something perhaps more worthy of thesis attention may be an examination of what it would take to start treating UID/GID as a completely internal machine representation which does not need to be shared. That is, it is important to have a common set of principal names for users, hosts and services in the Kerberos store; within an organization, it's important to have common groups of these principals in an LDAP store; but the importance of having all UIDs and GIDs be identical seems to be dwindling.
> 
> Authentication via Kerberos doesn't require it.
> Authorization using Kerberos principals doesn't require it.
> Moving files back and forth with SCP doesn't require it.
> An NFSv4 fileserver w/krb5 security doesn't require it.
> A CIFS fileserver doesn't require it.
> 
> What still requires that UID/GIDs need to be synchronized?
> 
> (I'm not necessarily asking you all right now. I think it might be a good thesis question, along with the follow-on: how much work would it take to migrate off of UID/GID synchronization for good?)

Hi Bryce,
a very thought provoking question, and it would be very nice if we
could, indeed, get rid of Posix IDs, however we can't.

One of the reasons is the dreaded 'legacy' applications and protocols.

You *could* build a system that can work w/o synchronization, if you
carefully restrict what protocols and applications you use (think about
distributed filesystems) although you'd still need a local persistent
map at least. Backups and restore to other machines would need to be
done carefully though, and so on.

However there are also issues with operations like 'renames', what
happen when you change a user name or a group name ? You do not want to
lose access to files when that happen, so you still need a unique
identifier that is not the everyday name (or forbid renames).

This is not an exhaustive list of course, and every problem can be
probably worked around one way or another, however at the moment it is
till "easier" to synchronize IDs than not ...

HTH,
Simo.

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



From dpal at redhat.com  Fri Mar  7 22:38:47 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 07 Mar 2014 17:38:47 -0500
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>
	<53191ED7.1000502@redhat.com>
	<CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>
Message-ID: <531A4A77.6010201@redhat.com>

On 03/07/2014 05:26 PM, Trey Dockendorf wrote:
> On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal<dpal at redhat.com>  wrote:
>> On 03/05/2014 06:24 PM, Trey Dockendorf wrote:
>>> Correction from my email, the condition that sets if a 389DS user is
>>> proxied to pam_krb5 is the "pamFilter", sorry.
>>>
>>> On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorf<treydock at gmail.com>
>>> wrote:
>>>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<dpal at redhat.com>   wrote:
>>>>> On 03/03/2014 07:47 PM, Simo Sorce wrote:
>>>>>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
>>>>>>> Is it possible with FreeIPA to use an external KDC or pass some or all
>>>>>>> authentication to an external KDC?  The KDC at our University may give
>>>>>>> me a one way trust if I describe my implementation plan for FreeIPA.
>>>>>>> Currently I use 389DS with PAM pass through using untrusted pam_krb5.
>>>>>>> I'd like to fully utilize FreeIPA without managing passwords since all
>>>>>>> my users already have University accounts.  I just want to manage
>>>>>>> authorization for my systems, not authentication.
>>>>>> You could set up a kerberos trust manually but at the moment we do not
>>>>>> support it in the code or the utilities.
>>>>>>
>>>>>> SSSD in particular will have no place to find identity information if
>>>>>> all you have is a kerberos trust, you'd need also an external identity
>>>>>> store to point to, but there is no builtin code in SSSD to link the 2
>>>>>> domain at this point.
>>>>>>
>>>>>> We are planning on working on IPA-to-IPA trust, and possibly
>>>>>> IPA-to-*other* so any requirements you can throw at us will be made
>>>>>> part
>>>>>> of the consideration and planning to add this kind of functionality in
>>>>>> the future.
>>>>>>
>>>>>> NM B HTH,
>>>>>> Simo.
>>>>>>
>>>>> Can you describe your workflows because I have some idea in mind?
>>>> Right now the workflow I have with 389ds using PAM Pass Through Auth
>>>> is the following:
>>>>
>>>> For users with the proper attribute defined in 'pamIDAttr'
>>>>
>>>> client --->   389DS --->   389DS server's pam_krb5 --->   Campus KDC
>>>>
>>>> For users lacking the attribute for 'pamIDAttr'
>>>>
>>>> client --->   389DS
>>>>
>>>> The Kerberos setup currently on the 389DS server is untrusted (no
>>>> krb5.keytab).
>>>>
>>>> The ideal workflow with FreeIPA would be
>>>>
>>>> client ---->   IPA --->   Campus KDC
>>>>
>>>>> Would you be OK if your accounts would be in IPA but the authentication
>>>>> would be proxied out?
>>>> This is fine with me.  Does the idea you describe allow for some
>>>> authentication (ie system accounts or internal accounts) to be handled
>>>> by FreeIPA?  That's the benefit to us when using PAM Pass Through
>>>> Auth, is that we can conditionally proxy out the authentication.
>>>>
>>>>> The idea is that you can use OTP RADIUS capability to proxy passwords to
>>>>> your main KDC.
>>>>>
>>>>> client ---OTP--->   IPA --->   OTP Proxy --->   RADIUS --->   Your KDC
>>>>>
>>>>> Disclaimer: that would defeat the purpose of Kerberos and the password
>>>>> will
>>>>> be sent over the wire but it seems that you are already in this setup.
>>>>>
>>>>> Would you be interested to give it a try?
>>>> Absolutely.  Right now I need to contact our campus IT group and let
>>>> them know what I require to make our setup work.  I have been told a
>>>> one way trust is the most I can get.  Will that facilitate what you
>>>> described?
>>
>> You do not need trust for that setup. Any user account (i am not sure about
>> special system accounts that are not created in cn=users) would be able to
>> go to external RADIUS server.
>>
>>
>>>>> Would require latest SSSD and kerberos library on the client though but
>>>>> would work with LDAP binds too.
>>>> Latest SSSD and Kerberos that's available in EL6, or latest upstream?
>>
>> Upstream.
>>
> Is it possible use these latest versions in EL6, or is using Fedora
> 19+ the only feasible way to do this?  If using EL6 is not possible,
> is it going to be something possible in EL7?


Latest RHEL7 beta snapshots might be a good starting point.
This will not be a part of RHEL6, sorry.

>
>> Please take a look at the design page: http://www.freeipa.org/page/V3/OTP -
>> that will give you an idea about the internals.
>>
>> Latest upstream UI should be able to allow to configure external RADIUS
>> servers and then change per user policy to proxy via RADIUS. Then you can
>> try binding with LDAP to IPA using password from your main KDC.
>> Then you can use SSSD on the same system to try to authenticate using
>> Kerberos. You will create a new user, set him to use RADIUS server for
>> authentication and then try to su to this user or ssh into the box as that
>> user. It should work and klist should report a TGT for this user on the box.
>>
> Thanks for the info.  I'll see if I can piece together how to make this work.

Let me know if you need any help or guidance with this POC.

>
>>>>> --
>>>>> 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 at 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 at 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/





From bnordgren at fs.fed.us  Sat Mar  8 01:19:12 2014
From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS)
Date: Sat, 8 Mar 2014 01:19:12 +0000
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <1394231525.14651.146.camel@willson.li.ssimo.org>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>	<20140307155921.GI19071@hendrix.redhat.com>
	<5319EE1D.1010207@redhat.com>
	<20140307162419.GL19071@hendrix.redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6926F2@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394231525.14651.146.camel@willson.li.ssimo.org>
Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E69284E@001FSN2MPN1-045.001f.mgd2.msft.net>

> You *could* build a system that can work w/o synchronization, if you
> carefully restrict what protocols and applications you use (think about
> distributed filesystems) although you'd still need a local persistent map at
> least. Backups and restore to other machines would need to be done
> carefully though, and so on.

I'm not suggesting that POSIX machines stop using UIDs internally. The local persistent map to a machine dependent representation will be necessary. It will also be necessary on Windows machines. And on mobile platforms. And within web applications. The shared items (principal names) would be common to all OSes and platforms though.

People trying to create heterogeneous environments are already carefully restricting protocols and applications to those which don't require sharing a UID map. File sharing via: Samba/CIFS, NFSv4, WebDAV, sftp (and sshfs(linux)/swish(Windows)). Logging into multiple machines has never involved knowing your UID, and ssh key pairs makes it more or less effortless to execute commands on another machine whether or not your username is the same, much less your UID. Kerberos SSO is more or less the same, but ensures that a common set of identities are recognized.

Ideally, if realm admins delegate authorization to the individual machines, the machines (regardless of OS) should be capable of functioning with only Kerberos authentication and without any centralized directory services. Minimal directory services could add group definitions via LDAP. A full AD/IPA solution would be needed to centralize authorization and/or enforce policy. Yet I still am not seeing the requirement for new deployments of cross-platform environments to manage internal user representations for a single os.

> However there are also issues with operations like 'renames', what happen
> when you change a user name or a group name ? You do not want to lose
> access to files when that happen, so you still need a unique identifier that is
> not the everyday name (or forbid renames).

Presumably, you also would not want your Windows users to lose access to files after a rename, and Windows doesn't use UIDs. You also would not want to lose access to web apps, which do not use UIDs. You also don't want stale usernames to be sitting in access control lists (filesystem based or web app based). Retaining UIDs does nothing to make renaming more acceptable, because principal names are a realm-wide platform independent property, and UIDs are not.

> This is not an exhaustive list of course, and every problem can be probably
> worked around one way or another, however at the moment it is till "easier"
> to synchronize IDs than not ...

As I see it, for a cross-platform environment, every problem must be worked around regardless of whether you have to synchronize UIDs. Managing UIDs is just more work at the end, and it might be busywork. Determining whether it's busywork or not may make a good thesis topic. :)

It makes a good thesis topic because the central question is paradigm shifting: Draw a line between realm-wide properties and local machine representations of those properties, and ask "Can each machine be made responsible for performing their own localizations for internal bookkeeping purposes?" This would seem to be of particular interest to the type of crowd which would download and use a FreeIPA/sssd solution, but it may not be something they have the time to pursue.

:)
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.



From Rashard.Kelly at sita.aero  Sat Mar  8 06:32:22 2014
From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero)
Date: Sat, 8 Mar 2014 01:32:22 -0500
Subject: [Freeipa-users] Joining realm failed: SASL Bind failed Local error
	(-2)
In-Reply-To: <531A4A77.6010201@redhat.com>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>	<53191ED7.1000502@redhat.com>
	<CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>
	<531A4A77.6010201@redhat.com>
Message-ID: <OF6F1E7DA3.25CF791A-ON85257C95.0022C9B0-85257C95.0023EC2A@sita.aero>

Hello all!!

I cannot get a RHEL5.10 client to install!

[root at hostname ~]# ipa-client-install --hostname=hostname.domain.com 
--no-ntp  --ca-cert-file=/etc/ipa/ca.crt
DNS domain 'doman.com' is not configured for automatic KDC address lookup.
KDC address will be set to fixed value.

Discovery was successful!
Hostname:hostname.com
Realm:DOMAIN.COM
DNS Domain: domain.com
IPA Server: ipaserver.com
BaseDN: dc=ipa,dc=dc,dc=sita,dc=com

Joining realm failed: SASL Bind failed Local error (-2) !
child exited with 9
Installation failed. Rolling back changes.


This is what the krb log had to say

Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29358](info): TGS_REQ (1 
etypes {18}) 10.226.124.10: ISSUE: authtime 1394259840, etypes {rep=18 
tkt=18 ses=18}, rkelly at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM
Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29357](info): TGS_REQ (4 
etypes {18 17 16 23}) 10.226.20.31: ISSUE: authtime 1394259840, etypes 
{rep=18 tkt=18 ses=18}, rkelly at DOMAIN.COM for 
ldap/ipaserver.domain.com at DOMAIN.COM
krb5kdc: Cannot determine realm for numeric host address - unable to find 
realm of host
Mar 08 06:24:00 ipaserver at domain.como krb5kdc[29358](info): TGS_REQ (7 
etypes {18 17 16 23 1 3 2}) 10.22.22.10: UNKNOWN_SERVER: authtime 0, 
rkelly at IPA2.DC.SITA.AERO for ldap/10.226.20.31 at DOMAIN.COM, Server not 
found in Kerberos database
Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29357](info): TGS_REQ (7 
etypes {18 17 16 23 1 3 2}) 10.22.22.10: UNKNOWN_SERVER: authtime 0, 
rkelly at IPA2.DC.SITA.AERO for ldap/10.226.20.31 at DOMAIN.COM, Server not 
found in Kerberos database


After reviewing the https://access.redhat.com/site/solutions/231543 post 
IPA: Joining realm failed: SASL Bind failed Local error (-2) ! child 
exited with 9. I checked all my DNS info via dig and took a working DNS 
config from another server. Everything appears to be setup right. What 
could I be overlooking?

Thank You,
Rashard Kelly
SITA  Senior Linux Specialist



From:   Dmitri Pal <dpal at redhat.com>
To:     Trey Dockendorf <treydock at gmail.com>
Cc:     freeipa-users at redhat.com
Date:   03/07/2014 05:43 PM
Subject:        Re: [Freeipa-users] Using external KDC
Sent by:        freeipa-users-bounces at redhat.com



On 03/07/2014 05:26 PM, Trey Dockendorf wrote:
> On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal<dpal at redhat.com>  wrote:
>> On 03/05/2014 06:24 PM, Trey Dockendorf wrote:
>>> Correction from my email, the condition that sets if a 389DS user is
>>> proxied to pam_krb5 is the "pamFilter", sorry.
>>>
>>> On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorf<treydock at gmail.com>
>>> wrote:
>>>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<dpal at redhat.com>   wrote:
>>>>> On 03/03/2014 07:47 PM, Simo Sorce wrote:
>>>>>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
>>>>>>> Is it possible with FreeIPA to use an external KDC or pass some or 
all
>>>>>>> authentication to an external KDC?  The KDC at our University may 
give
>>>>>>> me a one way trust if I describe my implementation plan for 
FreeIPA.
>>>>>>> Currently I use 389DS with PAM pass through using untrusted 
pam_krb5.
>>>>>>> I'd like to fully utilize FreeIPA without managing passwords since 
all
>>>>>>> my users already have University accounts.  I just want to manage
>>>>>>> authorization for my systems, not authentication.
>>>>>> You could set up a kerberos trust manually but at the moment we do 
not
>>>>>> support it in the code or the utilities.
>>>>>>
>>>>>> SSSD in particular will have no place to find identity information 
if
>>>>>> all you have is a kerberos trust, you'd need also an external 
identity
>>>>>> store to point to, but there is no builtin code in SSSD to link the 
2
>>>>>> domain at this point.
>>>>>>
>>>>>> We are planning on working on IPA-to-IPA trust, and possibly
>>>>>> IPA-to-*other* so any requirements you can throw at us will be made
>>>>>> part
>>>>>> of the consideration and planning to add this kind of functionality 
in
>>>>>> the future.
>>>>>>
>>>>>> NM B HTH,
>>>>>> Simo.
>>>>>>
>>>>> Can you describe your workflows because I have some idea in mind?
>>>> Right now the workflow I have with 389ds using PAM Pass Through Auth
>>>> is the following:
>>>>
>>>> For users with the proper attribute defined in 'pamIDAttr'
>>>>
>>>> client --->   389DS --->   389DS server's pam_krb5 --->   Campus KDC
>>>>
>>>> For users lacking the attribute for 'pamIDAttr'
>>>>
>>>> client --->   389DS
>>>>
>>>> The Kerberos setup currently on the 389DS server is untrusted (no
>>>> krb5.keytab).
>>>>
>>>> The ideal workflow with FreeIPA would be
>>>>
>>>> client ---->   IPA --->   Campus KDC
>>>>
>>>>> Would you be OK if your accounts would be in IPA but the 
authentication
>>>>> would be proxied out?
>>>> This is fine with me.  Does the idea you describe allow for some
>>>> authentication (ie system accounts or internal accounts) to be 
handled
>>>> by FreeIPA?  That's the benefit to us when using PAM Pass Through
>>>> Auth, is that we can conditionally proxy out the authentication.
>>>>
>>>>> The idea is that you can use OTP RADIUS capability to proxy 
passwords to
>>>>> your main KDC.
>>>>>
>>>>> client ---OTP--->   IPA --->   OTP Proxy --->   RADIUS --->   Your 
KDC
>>>>>
>>>>> Disclaimer: that would defeat the purpose of Kerberos and the 
password
>>>>> will
>>>>> be sent over the wire but it seems that you are already in this 
setup.
>>>>>
>>>>> Would you be interested to give it a try?
>>>> Absolutely.  Right now I need to contact our campus IT group and let
>>>> them know what I require to make our setup work.  I have been told a
>>>> one way trust is the most I can get.  Will that facilitate what you
>>>> described?
>>
>> You do not need trust for that setup. Any user account (i am not sure 
about
>> special system accounts that are not created in cn=users) would be able 
to
>> go to external RADIUS server.
>>
>>
>>>>> Would require latest SSSD and kerberos library on the client though 
but
>>>>> would work with LDAP binds too.
>>>> Latest SSSD and Kerberos that's available in EL6, or latest upstream?
>>
>> Upstream.
>>
> Is it possible use these latest versions in EL6, or is using Fedora
> 19+ the only feasible way to do this?  If using EL6 is not possible,
> is it going to be something possible in EL7?


Latest RHEL7 beta snapshots might be a good starting point.
This will not be a part of RHEL6, sorry.

>
>> Please take a look at the design page: 
http://www.freeipa.org/page/V3/OTP -
>> that will give you an idea about the internals.
>>
>> Latest upstream UI should be able to allow to configure external RADIUS
>> servers and then change per user policy to proxy via RADIUS. Then you 
can
>> try binding with LDAP to IPA using password from your main KDC.
>> Then you can use SSSD on the same system to try to authenticate using
>> Kerberos. You will create a new user, set him to use RADIUS server for
>> authentication and then try to su to this user or ssh into the box as 
that
>> user. It should work and klist should report a TGT for this user on the 
box.
>>
> Thanks for the info.  I'll see if I can piece together how to make this 
work.

Let me know if you need any help or guidance with this POC.

>
>>>>> --
>>>>> 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 at 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 at 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 at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


This document is strictly confidential and intended only for use by the
addressee unless otherwise stated.  If you are not the intended recipient,
please notify the sender immediately and delete it from your system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140308/ae4aa9b9/attachment.htm>

From Rashard.Kelly at sita.aero  Sat Mar  8 06:39:49 2014
From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero)
Date: Sat, 8 Mar 2014 01:39:49 -0500
Subject: [Freeipa-users] Joining realm failed: SASL Bind failed Local error
	(-2)
Message-ID: <OF4B05E951.91821A39-ON85257C95.002482B3-85257C95.00249AF0@sita.aero>

Hello all!!

I cannot get a RHEL5.10 client to install!

[root at hostname ~]# ipa-client-install --hostname=hostname.domain.com 
--no-ntp  --ca-cert-file=/etc/ipa/ca.crt
DNS domain 'doman.com' is not configured for automatic KDC address lookup.
KDC address will be set to fixed value.

Discovery was successful!
Hostname:hostname.com
Realm:DOMAIN.COM
DNS Domain: domain.com
IPA Server: ipaserver.com
BaseDN: dc=ipa,dc=dc,dc=sita,dc=com

Joining realm failed: SASL Bind failed Local error (-2) !
child exited with 9
Installation failed. Rolling back changes.


This is what the krb log had to say

Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29358](info): TGS_REQ (1 
etypes {18}) 10.226.124.10: ISSUE: authtime 1394259840, etypes {rep=18 
tkt=18 ses=18}, rkelly at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM
Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29357](info): TGS_REQ (4 
etypes {18 17 16 23}) 10.226.20.31: ISSUE: authtime 1394259840, etypes 
{rep=18 tkt=18 ses=18}, rkelly at DOMAIN.COM for 
ldap/ipaserver.domain.com at DOMAIN.COM
krb5kdc: Cannot determine realm for numeric host address - unable to find 
realm of host
Mar 08 06:24:00 ipaserver at domain.como krb5kdc[29358](info): TGS_REQ (7 
etypes {18 17 16 23 1 3 2}) 10.22.22.10: UNKNOWN_SERVER: authtime 0, 
rkelly at IPA2.DC.SITA.AERO for ldap/10.226.20.31 at DOMAIN.COM, Server not 
found in Kerberos database
Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29357](info): TGS_REQ (7 
etypes {18 17 16 23 1 3 2}) 10.22.22.10: UNKNOWN_SERVER: authtime 0, 
rkelly at IPA2.DC.SITA.AERO for ldap/10.226.20.31 at DOMAIN.COM, Server not 
found in Kerberos database


After reviewing the https://access.redhat.com/site/solutions/231543 post 
IPA: Joining realm failed: SASL Bind failed Local error (-2) ! child 
exited with 9. I checked all my DNS info via dig and took a working DNS 
config from another server. Everything appears to be setup right. 


What could I be overlooking?

Thank You,
Rashard Kelly
SITA  Senior Linux Specialist


This document is strictly confidential and intended only for use by the
addressee unless otherwise stated.  If you are not the intended recipient,
please notify the sender immediately and delete it from your system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140308/83ddf298/attachment.htm>

From simo at redhat.com  Sat Mar  8 20:52:34 2014
From: simo at redhat.com (Simo Sorce)
Date: Sat, 08 Mar 2014 15:52:34 -0500
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E69284E@001FSN2MPN1-045.001f.mgd2.msft.net>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>	<20140307155921.GI19071@hendrix.redhat.com>
	<5319EE1D.1010207@redhat.com>
	<20140307162419.GL19071@hendrix.redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6926F2@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394231525.14651.146.camel@willson.li.ssimo.org>
	<82E7C9A01FD0764CACDD35D10F5DFB6E69284E@001FSN2MPN1-045.001f.mgd2.msft.net>
Message-ID: <1394311954.14651.195.camel@willson.li.ssimo.org>

On Sat, 2014-03-08 at 01:19 +0000, Nordgren, Bryce L -FS wrote:
> I'm not suggesting that POSIX machines stop using UIDs internally. The
> local persistent map to a machine dependent representation will be
> necessary. It will also be necessary on Windows machines. And on
> mobile platforms. And within web applications. The shared items
> (principal names) would be common to all OSes and platforms though.

True, however posix information carry also other data, notably home
directory, gecos and shell. If you never share home directories you can
synthesize a home dire locally. And you could claim that everyone uses
bash and has to change the shell on each machine independently.
Gecos could also be ignored, although it is used in most desktops to
show a 'nice' name when your login is something like kxy3456yt ...

So yes you can probably forfeit all the user related information,
however it is rarely ok to forfeit groups, so you still need to
synchronize those around at least in homogeneous islands of activity.

> People trying to create heterogeneous environments are already
> carefully restricting protocols and applications to those which don't
> require sharing a UID map. File sharing via: Samba/CIFS, NFSv4,
> WebDAV, sftp (and sshfs(linux)/swish(Windows)). Logging into multiple
> machines has never involved knowing your UID, and ssh key pairs makes
> it more or less effortless to execute commands on another machine
> whether or not your username is the same, much less your UID. Kerberos
> SSO is more or less the same, but ensures that a common set of
> identities are recognized.

True, but the ability to successfully login does not exhaust the reason
why you have a common directory, there is other data that is
synchronized and shared.

> Ideally, if realm admins delegate authorization to the individual
> machines, the machines (regardless of OS) should be capable of
> functioning with only Kerberos authentication and without any
> centralized directory services.

Only if you think grouping mechanism are not necessary, I do not think
that's the case in any current deployment.

>  Minimal directory services could add group definitions via LDAP.

I guess you need to define what 'minimal' would mean here :)

>  A full AD/IPA solution would be needed to centralize authorization
> and/or enforce policy. Yet I still am not seeing the requirement for
> new deployments of cross-platform environments to manage internal user
> representations for a single os.

I am not sure I understand what you mean by 'single os' here, they
manage IDs as a single domain. Now, Posix is unfortunately limited by
the fact that it has a single user space and a single group space
because it was standardized when networks where rare and there were no
concepts of groups of machines with homogeneous identity stores. It
would be nice to fix this problem, but it is not simple to do it right,
and it would require kernel support to do it right.

> > However there are also issues with operations like 'renames', what
> > happen when you change a user name or a group name ? You do not
> > want to lose access to files when that happen, so you still need a
> > unique identifier that is not the everyday name (or forbid renames).
> 
> Presumably, you also would not want your Windows users to lose access
> to files after a rename, and Windows doesn't use UIDs.

Windows uses SIDs, they are perfectly equivalent to UIDs in this
discussion, although they have better properties when it comes to
networked machines.

In fact, over CIFS, SIDs are used to set ACLs, and in general you cannot
properly operate a Windows-centric domain if you do not have SID<->Name
translation services provided by the Domain Controller.

>  You also would not want to lose access to web apps, which do not use
> UIDs.

Web apps often duplicate the whole user database and have their own
groups, yet in enterprises they are also commonly integrated with a
directory for authentication and groups. They can ignore UIDs, just
like any other application, indeed.

>  You also don't want stale usernames to be sitting in access control
> lists (filesystem based or web app based).

Indeed which is why all filesystems tend to use UIDs (or SIDs for NTFS)
to perform access control. Unfortunately web applications almost always
do use usernames for access control, which is why renames are harder
there.

>  Retaining UIDs does nothing to make renaming more acceptable, because
> principal names are a realm-wide platform independent property, and
> UIDs are not.

This is debatable, but I do grant renames always need to be treated
carefully, however homogeneous UIDs/SIDs allow renames to happen.
Without UIDs stored in filesystems renames would simply not be possible,
w/o administrators running on every single machine and operating local
changes.

> > This is not an exhaustive list of course, and every problem can be
> probably
> > worked around one way or another, however at the moment it is till
> "easier"
> > to synchronize IDs than not ...
> 
> As I see it, for a cross-platform environment, every problem must be
> worked around regardless of whether you have to synchronize UIDs.
> Managing UIDs is just more work at the end, and it might be busywork.
> Determining whether it's busywork or not may make a good thesis
> topic. :)

Well, we try to make it so you, administrator, do not have to deal with
it if not rarely in freeIPA. So it shouldn't be busywork for sure. Would
like to know if anyone has a different experience and found themselves
in need to tinker for long with UIDs in an IPA environment.

> It makes a good thesis topic because the central question is paradigm
> shifting: Draw a line between realm-wide properties and local machine
> representations of those properties, and ask "Can each machine be made
> responsible for performing their own localizations for internal
> bookkeeping purposes?" This would seem to be of particular interest to
> the type of crowd which would download and use a FreeIPA/sssd
> solution, but it may not be something they have the time to pursue.

In abstract I think there isn't much to research, this kind of operation
has been experimented for a while for real.
Local mappings have been done for as long as Samba/Winbindd have
existed, as in the old days there was no "central" LDAP servers, and NT4
Domains were not extensible, so you had to create local ids for users.
However the fact each machine had a different view of the UIDs caused
issues when said machine needed to share files. Granted, "some" of this
would be easier today, but not hugely so.
This is why idmapping in the samba project has been a long and thorny
issue with multiple backends being invented and the most successful ones
being the ones that can predictably map Windows SIDs so that all Linux
machines get the same UIDs for the same users after mapping.

Going forward it is possible that local network file systems will become
less and less relevant, and groups will become more and more localized
into applications instead of being enterprise-wide, with enterprises
asserting properties of users instead of their groupings and deferring
to applications to deal with what to do with these attributes.

Eventually we may get to a point where multiple machines do not need to
share and synchronize much user data in the traditional way. But that
time has not arrived yet, IMHO. (Which is not to say I wouldn't want to
get there, it would be nice to get rid of this nasty problem :-)

Simo.

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



From treydock at gmail.com  Sat Mar  8 21:36:40 2014
From: treydock at gmail.com (Trey Dockendorf)
Date: Sat, 8 Mar 2014 15:36:40 -0600
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <531A4A77.6010201@redhat.com>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>
	<53191ED7.1000502@redhat.com>
	<CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>
	<531A4A77.6010201@redhat.com>
Message-ID: <CAN0oX1ZwbPf6n_KkLOnbURg0Qic6y9QP6H7OJ8LRBH5BXfAAag@mail.gmail.com>

I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no NTP).

IPA is 3.3.3-5.el7
SSSD is 1.11.2-1.el7
krb5 is 1.11.3-31.el7

Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted
the CLI commands under "Feature Management", with no luck.

For example:

---
# ipa config-mod --user-auth-type=['password', 'otp', 'radius']
Usage: ipa [global-options] config-mod [options]

ipa: error: no such option: --user-auth-type
---

The ipa subcommands "radiusproxy-*" do not exist either.

What version of IPA should I use to test this proof of concept?  The
docs mention needing Kerberos no earlier than 1.12, which isn't
available in EL7.

My understanding of Kerberos is not great, but is FreeIPA simply not
designed for external Kerberos (like the use of an external CA)?  Is
there possibly a way to utilize FreeIPA without Kerberos, and just
manage 389DS while still using the web interface (hard to find good
Identity Management Web UI) and CLI tools?  I'd still like to get this
working in FreeIPA, but am working on upgrading our HPC cluster to EL6
(or EL7) and moving to FreeIPA would be a great improvement over 389DS
in terms of manageability.

Thanks
- Trey

On Fri, Mar 7, 2014 at 4:38 PM, Dmitri Pal <dpal at redhat.com> wrote:
> On 03/07/2014 05:26 PM, Trey Dockendorf wrote:
>>
>> On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal<dpal at redhat.com>  wrote:
>>>
>>> On 03/05/2014 06:24 PM, Trey Dockendorf wrote:
>>>>
>>>> Correction from my email, the condition that sets if a 389DS user is
>>>> proxied to pam_krb5 is the "pamFilter", sorry.
>>>>
>>>> On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorf<treydock at gmail.com>
>>>> wrote:
>>>>>
>>>>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<dpal at redhat.com>   wrote:
>>>>>>
>>>>>> On 03/03/2014 07:47 PM, Simo Sorce wrote:
>>>>>>>
>>>>>>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
>>>>>>>>
>>>>>>>> Is it possible with FreeIPA to use an external KDC or pass some or
>>>>>>>> all
>>>>>>>> authentication to an external KDC?  The KDC at our University may
>>>>>>>> give
>>>>>>>> me a one way trust if I describe my implementation plan for FreeIPA.
>>>>>>>> Currently I use 389DS with PAM pass through using untrusted
>>>>>>>> pam_krb5.
>>>>>>>> I'd like to fully utilize FreeIPA without managing passwords since
>>>>>>>> all
>>>>>>>> my users already have University accounts.  I just want to manage
>>>>>>>> authorization for my systems, not authentication.
>>>>>>>
>>>>>>> You could set up a kerberos trust manually but at the moment we do
>>>>>>> not
>>>>>>> support it in the code or the utilities.
>>>>>>>
>>>>>>> SSSD in particular will have no place to find identity information if
>>>>>>> all you have is a kerberos trust, you'd need also an external
>>>>>>> identity
>>>>>>> store to point to, but there is no builtin code in SSSD to link the 2
>>>>>>> domain at this point.
>>>>>>>
>>>>>>> We are planning on working on IPA-to-IPA trust, and possibly
>>>>>>> IPA-to-*other* so any requirements you can throw at us will be made
>>>>>>> part
>>>>>>> of the consideration and planning to add this kind of functionality
>>>>>>> in
>>>>>>> the future.
>>>>>>>
>>>>>>> NM B HTH,
>>>>>>> Simo.
>>>>>>>
>>>>>> Can you describe your workflows because I have some idea in mind?
>>>>>
>>>>> Right now the workflow I have with 389ds using PAM Pass Through Auth
>>>>> is the following:
>>>>>
>>>>> For users with the proper attribute defined in 'pamIDAttr'
>>>>>
>>>>> client --->   389DS --->   389DS server's pam_krb5 --->   Campus KDC
>>>>>
>>>>> For users lacking the attribute for 'pamIDAttr'
>>>>>
>>>>> client --->   389DS
>>>>>
>>>>> The Kerberos setup currently on the 389DS server is untrusted (no
>>>>> krb5.keytab).
>>>>>
>>>>> The ideal workflow with FreeIPA would be
>>>>>
>>>>> client ---->   IPA --->   Campus KDC
>>>>>
>>>>>> Would you be OK if your accounts would be in IPA but the
>>>>>> authentication
>>>>>> would be proxied out?
>>>>>
>>>>> This is fine with me.  Does the idea you describe allow for some
>>>>> authentication (ie system accounts or internal accounts) to be handled
>>>>> by FreeIPA?  That's the benefit to us when using PAM Pass Through
>>>>> Auth, is that we can conditionally proxy out the authentication.
>>>>>
>>>>>> The idea is that you can use OTP RADIUS capability to proxy passwords
>>>>>> to
>>>>>> your main KDC.
>>>>>>
>>>>>> client ---OTP--->   IPA --->   OTP Proxy --->   RADIUS --->   Your KDC
>>>>>>
>>>>>> Disclaimer: that would defeat the purpose of Kerberos and the password
>>>>>> will
>>>>>> be sent over the wire but it seems that you are already in this setup.
>>>>>>
>>>>>> Would you be interested to give it a try?
>>>>>
>>>>> Absolutely.  Right now I need to contact our campus IT group and let
>>>>> them know what I require to make our setup work.  I have been told a
>>>>> one way trust is the most I can get.  Will that facilitate what you
>>>>> described?
>>>
>>>
>>> You do not need trust for that setup. Any user account (i am not sure
>>> about
>>> special system accounts that are not created in cn=users) would be able
>>> to
>>> go to external RADIUS server.
>>>
>>>
>>>>>> Would require latest SSSD and kerberos library on the client though
>>>>>> but
>>>>>> would work with LDAP binds too.
>>>>>
>>>>> Latest SSSD and Kerberos that's available in EL6, or latest upstream?
>>>
>>>
>>> Upstream.
>>>
>> Is it possible use these latest versions in EL6, or is using Fedora
>> 19+ the only feasible way to do this?  If using EL6 is not possible,
>> is it going to be something possible in EL7?
>
>
>
> Latest RHEL7 beta snapshots might be a good starting point.
> This will not be a part of RHEL6, sorry.
>
>
>>
>>> Please take a look at the design page: http://www.freeipa.org/page/V3/OTP
>>> -
>>> that will give you an idea about the internals.
>>>
>>> Latest upstream UI should be able to allow to configure external RADIUS
>>> servers and then change per user policy to proxy via RADIUS. Then you can
>>> try binding with LDAP to IPA using password from your main KDC.
>>> Then you can use SSSD on the same system to try to authenticate using
>>> Kerberos. You will create a new user, set him to use RADIUS server for
>>> authentication and then try to su to this user or ssh into the box as
>>> that
>>> user. It should work and klist should report a TGT for this user on the
>>> box.
>>>
>> Thanks for the info.  I'll see if I can piece together how to make this
>> work.
>
>
> Let me know if you need any help or guidance with this POC.
>
>
>>
>>>>>> --
>>>>>> 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 at 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 at 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/
>
>
>



From dpal at redhat.com  Sat Mar  8 23:51:15 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sat, 08 Mar 2014 18:51:15 -0500
Subject: [Freeipa-users] Joining realm failed: SASL Bind failed Local
 error (-2)
In-Reply-To: <OF6F1E7DA3.25CF791A-ON85257C95.0022C9B0-85257C95.0023EC2A@sita.aero>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>	<53191ED7.1000502@redhat.com>
	<CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>
	<531A4A77.6010201@redhat.com>
	<OF6F1E7DA3.25CF791A-ON85257C95.0022C9B0-85257C95.0023EC2A@sita.aero>
Message-ID: <531BACF3.50107@redhat.com>

On 03/08/2014 01:32 AM, Rashard.Kelly at sita.aero wrote:
> Hello all!!
>
> I cannot get a RHEL5.10 client to install!
>
> [root at hostname ~]# ipa-client-install --hostname=hostname.domain.com 
> --no-ntp  --ca-cert-file=/etc/ipa/ca.crt
> DNS domain 'doman.com' is not configured for automatic KDC address 
> lookup.
> KDC address will be set to fixed value.
>
> Discovery was successful!
> Hostname:hostname.com
> Realm:DOMAIN.COM
> DNS Domain: domain.com
> IPA Server: ipaserver.com
> BaseDN: dc=ipa,dc=dc,dc=sita,dc=com
>
> Joining realm failed: SASL Bind failed Local error (-2) !
> child exited with 9
> Installation failed. Rolling back changes.
>
>
> This is what the krb log had to say
>
> Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29358](info): TGS_REQ (1 
> etypes {18}) 10.226.124.10: ISSUE: authtime 1394259840, etypes {rep=18 
> tkt=18 ses=18}, rkelly at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM
> Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29357](info): TGS_REQ (4 
> etypes {18 17 16 23}) 10.226.20.31: ISSUE: authtime 1394259840, etypes 
> {rep=18 tkt=18 ses=18}, rkelly at DOMAIN.COM for 
> ldap/ipaserver.domain.com at DOMAIN.COM
> krb5kdc: Cannot determine realm for numeric host address - unable to 
> find realm of host

Check your DNS. It seems that the client can't resolve the server. It 
should be either in /etc/hosts or resolve.conf should include DNS server 
that has records about the server.

> Mar 08 06:24:00 ipaserver at domain.como krb5kdc[29358](info): TGS_REQ (7 
> etypes {18 17 16 23 1 3 2}) 10.22.22.10: UNKNOWN_SERVER: authtime 0, 
>  rkelly at IPA2.DC.SITA.AERO for ldap/10.226.20.31 at DOMAIN.COM, Server not 
> found in Kerberos database
> Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29357](info): TGS_REQ (7 
> etypes {18 17 16 23 1 3 2}) 10.22.22.10: UNKNOWN_SERVER: authtime 0, 
>  rkelly at IPA2.DC.SITA.AERO for ldap/10.226.20.31 at DOMAIN.COM, Server not 
> found in Kerberos database
>
>
> After reviewing the 
> https://access.redhat.com/site/solutions/231543post IPA: Joining realm 
> failed: SASL Bind failed Local error (-2) ! child exited with 9. I 
> checked all my DNS info via dig and took a working DNS config from 
> another server. Everything appears to be setup right. What could I be 
> overlooking?
>
> Thank You,
> *Rashard Kelly**
> **SITA** S*enior Linux Specialist
>
>
>
> From: Dmitri Pal <dpal at redhat.com>
> To: Trey Dockendorf <treydock at gmail.com>
> Cc: freeipa-users at redhat.com
> Date: 03/07/2014 05:43 PM
> Subject: Re: [Freeipa-users] Using external KDC
> Sent by: freeipa-users-bounces at redhat.com
> ------------------------------------------------------------------------
>
>
>
> On 03/07/2014 05:26 PM, Trey Dockendorf wrote:
> > On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal<dpal at redhat.com>  wrote:
> >> On 03/05/2014 06:24 PM, Trey Dockendorf wrote:
> >>> Correction from my email, the condition that sets if a 389DS user is
> >>> proxied to pam_krb5 is the "pamFilter", sorry.
> >>>
> >>> On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorf<treydock at gmail.com>
> >>> wrote:
> >>>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<dpal at redhat.com>   wrote:
> >>>>> On 03/03/2014 07:47 PM, Simo Sorce wrote:
> >>>>>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
> >>>>>>> Is it possible with FreeIPA to use an external KDC or pass 
> some or all
> >>>>>>> authentication to an external KDC?  The KDC at our University 
> may give
> >>>>>>> me a one way trust if I describe my implementation plan for 
> FreeIPA.
> >>>>>>> Currently I use 389DS with PAM pass through using untrusted 
> pam_krb5.
> >>>>>>> I'd like to fully utilize FreeIPA without managing passwords 
> since all
> >>>>>>> my users already have University accounts.  I just want to manage
> >>>>>>> authorization for my systems, not authentication.
> >>>>>> You could set up a kerberos trust manually but at the moment we 
> do not
> >>>>>> support it in the code or the utilities.
> >>>>>>
> >>>>>> SSSD in particular will have no place to find identity 
> information if
> >>>>>> all you have is a kerberos trust, you'd need also an external 
> identity
> >>>>>> store to point to, but there is no builtin code in SSSD to link 
> the 2
> >>>>>> domain at this point.
> >>>>>>
> >>>>>> We are planning on working on IPA-to-IPA trust, and possibly
> >>>>>> IPA-to-*other* so any requirements you can throw at us will be made
> >>>>>> part
> >>>>>> of the consideration and planning to add this kind of 
> functionality in
> >>>>>> the future.
> >>>>>>
> >>>>>> NM B HTH,
> >>>>>> Simo.
> >>>>>>
> >>>>> Can you describe your workflows because I have some idea in mind?
> >>>> Right now the workflow I have with 389ds using PAM Pass Through Auth
> >>>> is the following:
> >>>>
> >>>> For users with the proper attribute defined in 'pamIDAttr'
> >>>>
> >>>> client --->   389DS --->   389DS server's pam_krb5 --->   Campus KDC
> >>>>
> >>>> For users lacking the attribute for 'pamIDAttr'
> >>>>
> >>>> client --->   389DS
> >>>>
> >>>> The Kerberos setup currently on the 389DS server is untrusted (no
> >>>> krb5.keytab).
> >>>>
> >>>> The ideal workflow with FreeIPA would be
> >>>>
> >>>> client ---->   IPA --->   Campus KDC
> >>>>
> >>>>> Would you be OK if your accounts would be in IPA but the 
> authentication
> >>>>> would be proxied out?
> >>>> This is fine with me.  Does the idea you describe allow for some
> >>>> authentication (ie system accounts or internal accounts) to be 
> handled
> >>>> by FreeIPA?  That's the benefit to us when using PAM Pass Through
> >>>> Auth, is that we can conditionally proxy out the authentication.
> >>>>
> >>>>> The idea is that you can use OTP RADIUS capability to proxy 
> passwords to
> >>>>> your main KDC.
> >>>>>
> >>>>> client ---OTP--->   IPA --->   OTP Proxy --->   RADIUS --->   
> Your KDC
> >>>>>
> >>>>> Disclaimer: that would defeat the purpose of Kerberos and the 
> password
> >>>>> will
> >>>>> be sent over the wire but it seems that you are already in this 
> setup.
> >>>>>
> >>>>> Would you be interested to give it a try?
> >>>> Absolutely.  Right now I need to contact our campus IT group and let
> >>>> them know what I require to make our setup work.  I have been told a
> >>>> one way trust is the most I can get.  Will that facilitate what you
> >>>> described?
> >>
> >> You do not need trust for that setup. Any user account (i am not 
> sure about
> >> special system accounts that are not created in cn=users) would be 
> able to
> >> go to external RADIUS server.
> >>
> >>
> >>>>> Would require latest SSSD and kerberos library on the client 
> though but
> >>>>> would work with LDAP binds too.
> >>>> Latest SSSD and Kerberos that's available in EL6, or latest upstream?
> >>
> >> Upstream.
> >>
> > Is it possible use these latest versions in EL6, or is using Fedora
> > 19+ the only feasible way to do this?  If using EL6 is not possible,
> > is it going to be something possible in EL7?
>
>
> Latest RHEL7 beta snapshots might be a good starting point.
> This will not be a part of RHEL6, sorry.
>
> >
> >> Please take a look at the design page: 
> http://www.freeipa.org/page/V3/OTP-
> >> that will give you an idea about the internals.
> >>
> >> Latest upstream UI should be able to allow to configure external RADIUS
> >> servers and then change per user policy to proxy via RADIUS. Then 
> you can
> >> try binding with LDAP to IPA using password from your main KDC.
> >> Then you can use SSSD on the same system to try to authenticate using
> >> Kerberos. You will create a new user, set him to use RADIUS server for
> >> authentication and then try to su to this user or ssh into the box 
> as that
> >> user. It should work and klist should report a TGT for this user on 
> the box.
> >>
> > Thanks for the info.  I'll see if I can piece together how to make 
> this work.
>
> Let me know if you need any help or guidance with this POC.
>
> >
> >>>>> --
> >>>>> 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 at 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 at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
> This document is strictly confidential and intended only for use by 
> the addressee unless otherwise stated. If you are not the intended 
> recipient, please notify the sender immediately and delete it from 
> your system.
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140308/9bbd5435/attachment.htm>

From dpal at redhat.com  Sat Mar  8 23:53:50 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sat, 08 Mar 2014 18:53:50 -0500
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <CAN0oX1ZwbPf6n_KkLOnbURg0Qic6y9QP6H7OJ8LRBH5BXfAAag@mail.gmail.com>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>
	<53191ED7.1000502@redhat.com>
	<CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>
	<531A4A77.6010201@redhat.com>
	<CAN0oX1ZwbPf6n_KkLOnbURg0Qic6y9QP6H7OJ8LRBH5BXfAAag@mail.gmail.com>
Message-ID: <531BAD8E.5020502@redhat.com>

On 03/08/2014 04:36 PM, Trey Dockendorf wrote:
> I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no NTP).
>
> IPA is 3.3.3-5.el7
> SSSD is 1.11.2-1.el7
> krb5 is 1.11.3-31.el7
>
> Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted
> the CLI commands under "Feature Management", with no luck.
>
> For example:
>
> ---
> # ipa config-mod --user-auth-type=['password', 'otp', 'radius']
> Usage: ipa [global-options] config-mod [options]
>
> ipa: error: no such option: --user-auth-type
> ---
>
> The ipa subcommands "radiusproxy-*" do not exist either.
>
> What version of IPA should I use to test this proof of concept?  The
> docs mention needing Kerberos no earlier than 1.12, which isn't
> available in EL7.
>
> My understanding of Kerberos is not great, but is FreeIPA simply not
> designed for external Kerberos (like the use of an external CA)?  Is
> there possibly a way to utilize FreeIPA without Kerberos, and just
> manage 389DS while still using the web interface (hard to find good
> Identity Management Web UI) and CLI tools?  I'd still like to get this
> working in FreeIPA, but am working on upgrading our HPC cluster to EL6
> (or EL7) and moving to FreeIPA would be a great improvement over 389DS
> in terms of manageability.
>

Nathaniel, do we have a build of the latest bits for RHEL7 somewhere?
Can you help with this POC please?

> Thanks
> - Trey
>
> On Fri, Mar 7, 2014 at 4:38 PM, Dmitri Pal<dpal at redhat.com>  wrote:
>> On 03/07/2014 05:26 PM, Trey Dockendorf wrote:
>>> On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal<dpal at redhat.com>   wrote:
>>>> On 03/05/2014 06:24 PM, Trey Dockendorf wrote:
>>>>> Correction from my email, the condition that sets if a 389DS user is
>>>>> proxied to pam_krb5 is the "pamFilter", sorry.
>>>>>
>>>>> On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorf<treydock at gmail.com>
>>>>> wrote:
>>>>>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<dpal at redhat.com>    wrote:
>>>>>>> On 03/03/2014 07:47 PM, Simo Sorce wrote:
>>>>>>>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
>>>>>>>>> Is it possible with FreeIPA to use an external KDC or pass some or
>>>>>>>>> all
>>>>>>>>> authentication to an external KDC?  The KDC at our University may
>>>>>>>>> give
>>>>>>>>> me a one way trust if I describe my implementation plan for FreeIPA.
>>>>>>>>> Currently I use 389DS with PAM pass through using untrusted
>>>>>>>>> pam_krb5.
>>>>>>>>> I'd like to fully utilize FreeIPA without managing passwords since
>>>>>>>>> all
>>>>>>>>> my users already have University accounts.  I just want to manage
>>>>>>>>> authorization for my systems, not authentication.
>>>>>>>> You could set up a kerberos trust manually but at the moment we do
>>>>>>>> not
>>>>>>>> support it in the code or the utilities.
>>>>>>>>
>>>>>>>> SSSD in particular will have no place to find identity information if
>>>>>>>> all you have is a kerberos trust, you'd need also an external
>>>>>>>> identity
>>>>>>>> store to point to, but there is no builtin code in SSSD to link the 2
>>>>>>>> domain at this point.
>>>>>>>>
>>>>>>>> We are planning on working on IPA-to-IPA trust, and possibly
>>>>>>>> IPA-to-*other* so any requirements you can throw at us will be made
>>>>>>>> part
>>>>>>>> of the consideration and planning to add this kind of functionality
>>>>>>>> in
>>>>>>>> the future.
>>>>>>>>
>>>>>>>> NM B HTH,
>>>>>>>> Simo.
>>>>>>>>
>>>>>>> Can you describe your workflows because I have some idea in mind?
>>>>>> Right now the workflow I have with 389ds using PAM Pass Through Auth
>>>>>> is the following:
>>>>>>
>>>>>> For users with the proper attribute defined in 'pamIDAttr'
>>>>>>
>>>>>> client --->    389DS --->    389DS server's pam_krb5 --->    Campus KDC
>>>>>>
>>>>>> For users lacking the attribute for 'pamIDAttr'
>>>>>>
>>>>>> client --->    389DS
>>>>>>
>>>>>> The Kerberos setup currently on the 389DS server is untrusted (no
>>>>>> krb5.keytab).
>>>>>>
>>>>>> The ideal workflow with FreeIPA would be
>>>>>>
>>>>>> client ---->    IPA --->    Campus KDC
>>>>>>
>>>>>>> Would you be OK if your accounts would be in IPA but the
>>>>>>> authentication
>>>>>>> would be proxied out?
>>>>>> This is fine with me.  Does the idea you describe allow for some
>>>>>> authentication (ie system accounts or internal accounts) to be handled
>>>>>> by FreeIPA?  That's the benefit to us when using PAM Pass Through
>>>>>> Auth, is that we can conditionally proxy out the authentication.
>>>>>>
>>>>>>> The idea is that you can use OTP RADIUS capability to proxy passwords
>>>>>>> to
>>>>>>> your main KDC.
>>>>>>>
>>>>>>> client ---OTP--->    IPA --->    OTP Proxy --->    RADIUS --->    Your KDC
>>>>>>>
>>>>>>> Disclaimer: that would defeat the purpose of Kerberos and the password
>>>>>>> will
>>>>>>> be sent over the wire but it seems that you are already in this setup.
>>>>>>>
>>>>>>> Would you be interested to give it a try?
>>>>>> Absolutely.  Right now I need to contact our campus IT group and let
>>>>>> them know what I require to make our setup work.  I have been told a
>>>>>> one way trust is the most I can get.  Will that facilitate what you
>>>>>> described?
>>>>
>>>> You do not need trust for that setup. Any user account (i am not sure
>>>> about
>>>> special system accounts that are not created in cn=users) would be able
>>>> to
>>>> go to external RADIUS server.
>>>>
>>>>
>>>>>>> Would require latest SSSD and kerberos library on the client though
>>>>>>> but
>>>>>>> would work with LDAP binds too.
>>>>>> Latest SSSD and Kerberos that's available in EL6, or latest upstream?
>>>>
>>>> Upstream.
>>>>
>>> Is it possible use these latest versions in EL6, or is using Fedora
>>> 19+ the only feasible way to do this?  If using EL6 is not possible,
>>> is it going to be something possible in EL7?
>>
>>
>> Latest RHEL7 beta snapshots might be a good starting point.
>> This will not be a part of RHEL6, sorry.
>>
>>
>>>> Please take a look at the design page: http://www.freeipa.org/page/V3/OTP
>>>> -
>>>> that will give you an idea about the internals.
>>>>
>>>> Latest upstream UI should be able to allow to configure external RADIUS
>>>> servers and then change per user policy to proxy via RADIUS. Then you can
>>>> try binding with LDAP to IPA using password from your main KDC.
>>>> Then you can use SSSD on the same system to try to authenticate using
>>>> Kerberos. You will create a new user, set him to use RADIUS server for
>>>> authentication and then try to su to this user or ssh into the box as
>>>> that
>>>> user. It should work and klist should report a TGT for this user on the
>>>> box.
>>>>
>>> Thanks for the info.  I'll see if I can piece together how to make this
>>> work.
>>
>> Let me know if you need any help or guidance with this POC.
>>
>>
>>>>>>> --
>>>>>>> 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 at 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 at 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/
>>
>>
>>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From bnordgren at fs.fed.us  Sun Mar  9 01:28:57 2014
From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS)
Date: Sun, 9 Mar 2014 01:28:57 +0000
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <1394311954.14651.195.camel@willson.li.ssimo.org>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>	<20140307155921.GI19071@hendrix.redhat.com>
	<5319EE1D.1010207@redhat.com>
	<20140307162419.GL19071@hendrix.redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6926F2@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394231525.14651.146.camel@willson.li.ssimo.org>
	<82E7C9A01FD0764CACDD35D10F5DFB6E69284E@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394311954.14651.195.camel@willson.li.ssimo.org>
Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6929BF@001FSN2MPN1-045.001f.mgd2.msft.net>

So the bottom line, if I understand this conversation so far, allowing each machine to synthesize OS-specific information from pure Kerberos principal names:

* Breaks host-based authentication for file sharing (NFS3/2).
* Breaks CIFS ACLs (no central SIDs) (Does it also break CIFS completely?)
* Means there are consequences for renaming users/groups.
* Means the machine may not be able to display a friendly user name
* Means the machine will either have non-shared home directories, or require home directories be shared via NFSv4/sshfs.
* Allows filesharing via NFSv4 or sshfs/swish (realm-wide, project-wide, or point-to-point)
* Allows filesharing via WebDAV.
* Reusable groups may not be defined.
* May break Windows entirely due to a requirement for SID<->Principal name mapping on the directory server.
* Centralizes password management
* Allows SSO operation

If one adds groups but does not attempt to manage GIDs:
* Requires a directory solution (LDAP/AD/IPA)
* Allows group usage on local filesystems and shared NFSv4 filesystems.

> Well, we try to make it so you, administrator, do not have to deal with it if not
> rarely in freeIPA. So it shouldn't be busywork for sure. Would like to know if
> anyone has a different experience and found themselves in need to tinker
> for long with UIDs in an IPA environment.

IPA supplements (or hopefully will supplement) AD in my environment. I need to worry about colliding with UIDs in a directory I don't control. IPA can't solve this problem for me. Neither can my current LDAP solution. But machines which could generate their own mappings...many headaches would go away.


> In abstract I think there isn't much to research, this kind of operation has
> been experimented for a while for real.
>...
> Eventually we may get to a point where multiple machines do not need to
> share and synchronize much user data in the traditional way. But that time
> has not arrived yet, IMHO. (Which is not to say I wouldn't want to get there,
> it would be nice to get rid of this nasty problem :-)

The renaming thing you brought up (within a non-UID/SID-sharing environment) sounds like it could be a good thesis topic. "Going forward" probably means starting to use NFSv4, which also warns against renaming because it doesn?t use UID/SIDs. It sounds like a necessary and present issue to address.

Assembling a functional realm containing only platform-independent principals (could include groups, not GIDs), by extending the NFS idmapper could be another. (Or at least ensuring that the POSIX mappings and NFS mappings are the same...) Try the same thing on Windows and see what the showstoppers are. Success may simplify integration of Windows into IPA managed domains if you didn't have to emulate an AD instance so completely. Home users everywhere may love being able to make all their machines have the same password via a KDC (or IPA?) running on their wireless router.

If you're tired of this topic, how about a thesis which makes Kerberos KDCs function more like IP routers, collaboratively and automatically maintaining the connectivity topology between Kerberos realms? Clearly, its not the same: cross-realm connectivity (I will NOT use the word "trust") is inherently unidirectional. Also, the mapping from realm->dns and specific fqdns for the KDCs will need to be communicated. The KDC could potentially communicate this topology to interested clients, but why on earth would the clients want to know? IP routers made UUCP bang paths obsolete, something should do the same for Kerberos capaths.

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.



From josh at wrale.com  Sun Mar  9 03:47:16 2014
From: josh at wrale.com (Joshua Dotson)
Date: Sat, 8 Mar 2014 22:47:16 -0500
Subject: [Freeipa-users] Requesting Guidance on FreeIPA Replica Cluster
	across Six Nodes
Message-ID: <CAHWHj86pBAai1V-F8n7KPbvMgOemB8FAj8LR_Y4+S3M868aujQ@mail.gmail.com>

I posted the following in IRC.  The question was so involved that I decided
it would probably be best to just join the users mailing list and ask
here.  So, here I am.

Please let me know your thoughts/questions/comments.

Thanks,
Joshua

[22:29] <wrale-josh> hello.. i'm building an virtualization cluster of six
nodes [on a common 10GbE LAN] to house administrative functions (e.g.
logstash) for a mid-size environment.. i'm using gluster (replica 3), ovirt
self-hosted engine and freeipa.  fencing will be done via ipmi.  distro is
Fedora 19.  Anyway, because FreeIPA is so fundamental to the cluster and
the environment at large, I'm thinking of having replicas on all six
servers (bare metal).. (cont.)
[22:30] <wrale-josh> I read some about the trust relationships.  I read on
the mailing list that upwards of 20 server environments have been tested.  What
kind of method of trust should i use so that any two servers can be down at
any given time, with no loss of service?
[22:32] <wrale-josh> I think I'd need a minimum of three FreeIPA servers to
gain the ability to lose two servers without service interruption.  Should
I, for example, make nodes 2 and 3 have trust with node 1 but not each
other?
[22:33] <wrale-josh> And if I were to do six nodes, what should that look
like, so far as trust is conerned?
[22:36] <wrale-josh> Ahem.. And is there any odd vs. even quantity for
quorum analog here (ala gluster wanting even number of nodes, vs. zookeeper
wanting an odd number of nodes)?
[22:36] <wrale-josh> (i think i'll just send this to the mailing list).. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140308/7dfb0fd8/attachment.htm>

From devel at jasonwoods.me.uk  Sun Mar  9 17:42:28 2014
From: devel at jasonwoods.me.uk (Jason Woods)
Date: Sun, 9 Mar 2014 17:42:28 +0000
Subject: [Freeipa-users] Another patch for ipa-sam: Excessive LDAP calls by
	ipa-sam during file operations
Message-ID: <1B4C08F2-4EB6-4299-8374-4C406AD11EF7@jasonwoods.me.uk>

Hi,

A follow up from previous email regarding my patch for ipa-sam to fix "valid users = " group references in the samba server that comes with ipa-server-trust-ad.
(Found here: https://www.redhat.com/archives/freeipa-users/2014-March/msg00045.html )

I noticed that ns-slapd CPU was excessive during multi-file copies (like a git repository with thousands of files.)
Debug level 10 logs showed ipa-sam was performing multiple LDAP queries per file. One for the user and others for the groups. Specifically in order to perform gid/uid<->sid lookups.

I've pre-empted and raised as a bug with a proposed patch:
https://bugzilla.redhat.com/show_bug.cgi?id=1074314

It does a few things:
1. idmap caching so the ldap calls are significantly reduced
2. when gid lookup received for the primary user group (so where gid==uid), properly reflect behaviour of the initial lookup that happens during init by returning the Default SMB Group fallback group
3. don't bother ldap call for uidNumber=0 (root) - since it never will exist in FreeIPA according to my research
My CPU for ns-slapd is now 0. And file copies are much better and more like normal.

This seems to fix all issues for me at the moment - and I guess all what remains to do is extra features to make it more like the ldapsam.
It also looks like all that is needed to get the ipa-sam.so to work without FreeIPA master local - is to allow the service principal access to the ipaNTHash attribute. However, I can't see any current aci referring to principals at the moment or even grouping of them into types - probably because I'm taking the wrong though-path - but if anyone would like to discuss this that would be great.

Hope the patch helps!

Thanks,

Jason



From dpal at redhat.com  Sun Mar  9 18:21:25 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sun, 09 Mar 2014 14:21:25 -0400
Subject: [Freeipa-users] ipa-client-install fails on replica because of
 kinit cannot contact any KDC
In-Reply-To: <1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com>
References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<20140208092932.GA11564@mail.corp.redhat.com>	<1391876093.67760.YahooMailNeo@web160104.mail.bf1.yahoo.com>	<52F77815.1060100@redhat.com>	<52F93875.60504@redhat.com>	<1392156305.49155.YahooMailNeo@web160102.mail.bf1.yahoo.com>	<52FAA2B1.3090506@redhat.com>	<1392159226.39533.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<52FB349B.6020901@redhat.com>	<1392228657.73323.YahooMailNeo@web160102.mail.bf1.yahoo.com>	<52FBBE2E.9020904@redhat.com>	<1392230403.24294.YahooMailNeo@web160104.mail.bf1.yahoo.com>	<52FBC071.3050602@redhat.com>	<1392232194.61475.YahooMailNeo@web160104.mail.bf1.yahoo.com>
	<52FBCD8E.8060705@redhat.com>
	<1392237694.44875.YahooMailNeo@web160103.mail.bf1.yahoo.com>
	<52FBDCD8.2080800@redhat.com>
	<1392240578.15868.YahooMailNeo@web160101.mail.bf1.yahoo.com>
Message-ID: <531CB125.6010202@redhat.com>

On 02/12/2014 04:29 PM, Shree wrote:
> "getcert list" returned a bunch of info, see below
>
> root at ldap2 ~]# getcert list
> Number of certificates and requests being tracked: 2.
> Request ID '20140206184920':
> status: MONITORING
> stuck: no
> key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB'
> CA: dogtag-ipa-retrieve-agent-submit
> issuer: CN=Certificate Authority,......................
> .............................
>

It is listing the certs that are tracked locally. It is not going over 
the wire.
I suggested to request another cert to check the connection to the server.

> Shreeraj
> ---------------------------------------------------------------------------------------- 
>
>
> Change is the only Constant !
>
>
> On Wednesday, February 12, 2014 12:43 PM, Dmitri Pal <dpal at redhat.com> 
> wrote:
> On 02/12/2014 03:41 PM, Shree wrote:
>> So I uninstalled the ipa server and installed the client 
>> (ipa-client-install) on the same VM pointing at the master and 
>> everything seems to work OK. All the sudo rules etc. Are there any 
>> tests I can do check connectivity that could be helpful before I 
>> configure this as a "replica" again.
> Ask certmonger to get a certificate
>
>>
>> Shreeraj
>> ---------------------------------------------------------------------------------------- 
>>
>>
>> Change is the only Constant !
>>
>>
>> On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal 
>> <dpal at redhat.com> <mailto:dpal at redhat.com> wrote:
>> On 02/12/2014 02:09 PM, Shree wrote:
>>> Rob
>>> I really appreciate your help, please bear with me. At this point I 
>>> need to take you back to my  ipa-replica-install and what happened 
>>> there.
>>>
>>> [1] My command: ipa-replica-install --setup-ca 
>>> /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck
>>>  This ended with a
>>> Done configuring NTP daemon (ntpd).
>>> A CA is already configured on this system.
>>>
>>> [2] So did a pkiremove with the following command
>>> # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force
>>>
>>> [3] Re ran the ipa-replica-install command in step 1
>>> The install went a little further but ended below.
>>>
>>> Configuring directory server for the CA (pkids): Estimated time 30 
>>> seconds
>>>   [1/3]: creating directory server user
>>>   [2/3]: creating directory server instance
>>>   [3/3]: restarting directory server
>>> Done configuring directory server for the CA (pkids).
>>> ipa         : ERROR    certmonger failed starting to track 
>>> certificate: Command '/usr/bin/ipa-getcert start-tracking -d 
>>> /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p 
>>> /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C 
>>> /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero 
>>> exit status 1
>>> Configuring certificate server (pki-cad): Estimated time 3 minutes 
>>> 30 seconds
>>>   [1/17]: creating certificate server user
>>>   [2/17]: creating pki-ca instance
>>>   [3/17]: configuring certificate server instance
>>> ipa         : CRITICAL failed to configure ca instance Command 
>>> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname 
>>> .................
>>> ...........................
>>> Your system may be partly configured.
>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>
>>> Configuration of CA failed
>>>
>>> If I skip the "--setup-ca" option then the replica gets created 
>>> without any CA services. The "master" and "replica" are in sync but 
>>> I am unable to run a ipa-client-install using  the replica. Now I 
>>> need to fix this to get a replica in place correctly.
>>>
>>>
>>> Shreeraj
>>> ---------------------------------------------------------------------------------------- 
>>>
>>>
>>>
>>> On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden 
>>> <rcritten at redhat.com> <mailto:rcritten at redhat.com> wrote:
>>> Shree wrote:
>>> > OK I thought CA is a part of IPA ? Below is from my master IPA server
>>> >
>>> > [root at ldap <mailto:root at ldap> ~]# ipactl status
>>> > Directory Service: RUNNING
>>> > KDC Service: RUNNING
>>> > KPASSWD Service: RUNNING
>>> > MEMCACHE Service: RUNNING
>>> > HTTP Service: RUNNING
>>> > CA Service: RUNNING
>>> > [root at ldap <mailto:root at ldap> ~]#
>>> >
>>> > I can certainly send you a log if needed.
>>>
>>> It is part of IPA but the IPA server talks to it, not the clients 
>>> directly.
>>>
>>> I can only speculate what the client is doing without seeing the log
>>> files, but I suspect both masters are in DNS and IPA is trying to 
>>> enroll
>>> to the initial master which isn't available.
>>>
>>> rob
>>>
>>> > Shreeraj
>>> > 
>>> ----------------------------------------------------------------------------------------
>>> >
>>> >
>>> > Change is the only Constant !
>>> >
>>> >
>>> > On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden
>>> > <rcritten at redhat.com <mailto:rcritten at redhat.com>> wrote:
>>> > Shree wrote:
>>> > > Peter
>>> > > Actually I mentioned earlier that my clients are in a separate 
>>> VLAN and
>>> > > cannot access the master. We have made provisions for the master 
>>> and the
>>> > > replica to sync by opening the needed ports in the firewall. We have
>>> > > also opened up ports between the clients and the replica. I have 
>>> tested
>>> > > the connectivity for these ports.
>>> > > Perhaps you can tell me if what I am trying to achieve is even 
>>> possible?
>>> > > i.e
>>> > > I seem to get stuck with making the replica with the "--setup-ca"
>>> > > option. Wthout that option I am able to create a replica and 
>>> have it in
>>> > > sync with the master. However my ipa-client-install fails from 
>>> clients
>>> > > as they try looking for the master for CA part of the install.
>>> >
>>> > Clients don't talk to the CA, they talk to an IPA server which 
>>> talks to
>>> > the CA.
>>> >
>>> > I think we need to see /var/log/ipaclient-install.log to see what is
>>> > going on.
>>> >
>>> > rob
>>> >
>>> > > Shreeraj
>>> > >
>>> > 
>>> ----------------------------------------------------------------------------------------
>>> > >
>>> > >
>>> > > Change is the only Constant !
>>> > >
>>> > >
>>> > > On Wednesday, February 12, 2014 12:45 AM, Petr Spacek
>>> > > <pspacek at redhat.com <mailto:pspacek at redhat.com> 
>>> <mailto:pspacek at redhat.com <mailto:pspacek at redhat.com>>> wrote:
>>> > > On 11.2.2014 23:53, Shree wrote:
>>> > >
>>> > > > Following ports are opened between the
>>> > > > 1) Between the master and the replica (bi directional)
>>> > > > 2) client machine and the ipa replica (unidirectional).
>>> > > > When the replica was up it worked fine as far as syncing was
>>> > concerned.
>>> > > >
>>> > > >  80 tcp
>>> > > >  443 tcp
>>> > > >  389 tcp
>>> > > >  636 tcp
>>> > > >  88 tcp
>>> > > >  464 tcp
>>> > > >  88 udp
>>> > > >  464 udp
>>> > > >  123 udp
>>> > > >
>>> > > > Shreeraj
>>> > > >
>>> > >
>>> > 
>>> ----------------------------------------------------------------------------------------
>>> > > >
>>> > > > Change is the only Constant !
>>> > > >
>>> > > >
>>> > > >
>>> > > > On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal 
>>> <dpal at redhat.com <mailto:dpal at redhat.com>
>>> > <mailto:dpal at redhat.com <mailto:dpal at redhat.com>>
>>> > > <mailto:dpal at redhat.com <mailto:dpal at redhat.com> 
>>> <mailto:dpal at redhat.com <mailto:dpal at redhat.com>>>> wrote:
>>> > > >
>>> > > > On 02/11/2014 05:05 PM, Shree wrote:
>>> > > > Dimitri
>>> > > >> Sorry some the mail landed in my SPAM folder. Let answer your
>>> > > questions (thanks for your help man)
>>> > > > Please republish it on the list.
>>> > > > Do not reply to me directly.
>>> > > >
>>> > > > Did you set your first server with the CA? Does all ports that 
>>> need
>>> > > >      to be open in the firewall between primary or server are 
>>> actually
>>> > > >      open?
>>> > > >
>>> > > >
>>> > > >
>>> > > >>
>>> > > >> What I have done so far is uninstalled the replica and tried to
>>> > > install it again using the "--setup-ca" option. Previously I had
>>> > > failures and when I removed the "--setup-ca" option the installation
>>> > > succeeded (in a way). I understand now that I really need to fix 
>>> the CA
>>> > > installation errors first.
>>> > > >>
>>> > > >>
>>> > > >> 1)The workaround helped me go forward a bit but I got stuck 
>>> at this
>>> > > point see below
>>> > > >> ===========
>>> > > >>    [1/3]: creating directory server user
>>> > > >>    [2/3]: creating directory server instance
>>> > > >>    [3/3]: restarting directory server
>>> > > >> Done configuring directory server for the CA (pkids).
>>> > > >> ipa        : ERROR    certmonger failed starting to track
>>> > > certificate: Command '/usr/bin/ipa-getcert start-tracking -d
>>> > > /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p
>>> > > /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C
>>> > > /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned 
>>> non-zero exit
>>> > > status 1
>>> > > >> Configuring certificate server (pki-cad): Estimated time 3 
>>> minutes
>>> > > 30 seconds
>>> > > >>    [1/17]: creating certificate server user
>>> > > >>    [2/17]: creating pki-ca instance
>>> > > >>    [3/17]: configuring certificate server instance
>>> > > >> ipa        : CRITICAL failed to configure ca instance Command
>>> > > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
>>> > > ldap2.macosforge.org -cs_port 9445 -client_certdb_dir 
>>> /tmp/tmp-ipJSsT
>>> > > -client_certdb_pwd XXXXXXXX -preop_pin OlGXcjPVXoQcuuQkGgoG -
>>> > > >> ===========
>>> > > >> 2) No we do not use IPA for a DNS server.
>>> > > >>
>>> > > >>
>>> > > >> 3)The reason for this could be that I had installed the replica
>>> > > without the "--setup-ca".
>>> > > >>
>>> > > >> Shreeraj
>>> > > >>
>>> > >
>>> > 
>>> ----------------------------------------------------------------------------------------
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >> Change is the only Constant !
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >> On Monday, February 10, 2014 12:43 PM, Dmitri Pal
>>> > <dpal at redhat.com <mailto:dpal at redhat.com> <mailto:dpal at redhat.com 
>>> <mailto:dpal at redhat.com>>
>>> > > <mailto:dpal at redhat.com <mailto:dpal at redhat.com> 
>>> <mailto:dpal at redhat.com <mailto:dpal at redhat.com>>>> wrote:
>>> > > >>
>>> > > >> On 02/09/2014 07:44 AM, Rob Crittenden wrote:
>>> > > >>> Shree wrote:
>>> > > >>>> Lukas
>>> > > >>>> Perhaps I should explain the design a bit and
>>> > > >                  see if FreeIPA even
>>> > > >>>> supports this.Our replica is in a separate
>>> > > >                  network and all the
>>> > > >>>> appropriate ports are opened between the master
>>> > > >                  and the replica. The
>>> > > >>>> "replica" got created successfully and is in
>>> > > >                  sync with the master
>>> > > >>>> (except the CA services which I mentioned
>>> > > >                  earlier)
>>> > > >>>> Now,when I try to run ipa-client-install on
>>> > > >    hosts in the new network
>>> > > >>>> using the replica, it complains that about
>>> > > >                  "Cannot contact any KDC for
>>> > > >>>> realm".
>>> > > >>>> I am wondering it my hosts in the new network
>>> > > >                  are trying to access the
>>> > > >>>> "master" for certificates since the replica
>>> > > >                  does not have any CA
>>> > > >>>> services running? I couldn't find any obvious
>>> > > >                  proof of this even running
>>> > > >>>> the install in a debug mode. Do I need to open
>>> > > >                  ports between the new
>>> > > >>>> hosts and the master for CA services?
>>> > > >>>> At this point I cannot disable or  move the
>>> > > >                  master, it needs to function
>>> > > >>>> in its location but I need
>>> > > >>>
>>> > > >>> No, the clients don't directly talk to the CA.
>>> > > >>>
>>> > > >>> You'd need to look in
>>> > > >                  /var/log/ipaclient-install.log to see what KDC
>>> > > >>> was found and we were trying to use. If you have
>>> > > >                  SRV records for both
>>> > > >>> but we try to contact the hidden master this will
>>> > > >                  happen. You can try
>>> > > >>> specifying the server on the command-line with
>>> > > >                  --server but this will
>>> > > >>> be hardcoding things and make it less flexible
>>> > > >                  later.
>>> > > >>>
>>> > > >>> rob
>>> > > >>>
>>> > > >>>> Shreeraj
>>> > > >>>>
>>> > > >
>>> > >
>>> > 
>>> ----------------------------------------------------------------------------------------
>>> > > >>>>
>>> > > >>>>
>>> > > >>>>
>>> > > >>>> Change is the only Constant !
>>> > > >>>>
>>> > > >>>>
>>> > > >>>> On Saturday, February 8, 2014 1:29 AM, Lukas
>>> > > >                  Slebodnik
>>> > > >>>> <lslebodn at redhat.com <mailto:lslebodn at redhat.com> 
>>> <mailto:lslebodn at redhat.com <mailto:lslebodn at redhat.com>>
>>> > <mailto:lslebodn at redhat.com <mailto:lslebodn at redhat.com> 
>>> <mailto:lslebodn at redhat.com <mailto:lslebodn at redhat.com>>>> wrote:
>>> > > >>>> On (06/02/14 18:33), Shree wrote:
>>> > > >>>>
>>> > > >>>>> First of all, the ipa-replica-install did
>>> > > >                  not allow me to use
>>> > > >>>> the --setup-ca
>>> > > >>>>> option complaining that a cert already
>>> > > >                  exists, replicate creation was
>>> > > >>>>> successful after I skipped the option.
>>> > > >>>>> Seems like the replica is one except
>>> > > >>>>> 1) There is no CA Service running on the
>>> > > >                  replica (which I guess is
>>> > > >>>> expected)
>>> > > >>>>> and
>>> > > >>>>> 2) I am unable to run ipa-client-install
>>> > > >                  successfully on any clients
>>> > > >>>> using
>>> > > >>>>> the replica. (I don't have the option of
>>> > > >                  using the primary master as
>>> > > >>>> it is
>>> > > >>>>> configured in a segregated environment.
>>> > > >                  Only the master and replica
>>> > > >>>> are
>>> > > >>>>> allowed to sync.
>>> > > >>>>> Debug shows it fails at
>>> > > >>>>>
>>> > > >>>>> ipa        : DEBUG    stderr=kinit: Cannot
>>> > > >                  contact any KDC for realm
>>> > > >>>> 'mydomainname.com' while getting initial
>>> > > >                  credentials
>>> > > >>>>
>>> > > >>>>>
>>> > > >>>>>
>>> > > >>>>
>>> > > >>>> I was not able to install replica witch CA on
>>> > > >                  fedora 20,
>>> > > >>>> Bug is already reported https://fedorahosted.org/pki/ticket/816
>>> > > >>>>
>>> > > >>>> Guys from dogtag found a workaround
>>> > > >>>> https://fedorahosted.org/pki/ticket/816#comment:12
>>> > > >>>>
>>> > > >>>> Does it work for you?
>>> > > >>>>
>>> > > >>>> LS
>>> > > >>>>
>>> > > >>>>
>>> > > >>>>
>>> > > >>>>
>>> > > >>>>
>>> > > >>>> _______________________________________________
>>> > > >>>> Freeipa-users mailing list
>>> > > >>>> Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com> 
>>> <mailto:Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>>
>>> > <mailto:Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com> 
>>> <mailto:Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>>>
>>> > > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> > > >>>>
>>> > > >>>
>>> > > >>> _______________________________________________
>>> > > >>> Freeipa-users mailing list
>>> > > >>> Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com> 
>>> <mailto:Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>>
>>> > <mailto:Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com> 
>>> <mailto:Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>>>
>>> >
>>> > > >>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> > > >>
>>> > > >> What server provides DNS capabilities to the clients?
>>> > > >> Do you use IPA DNS or some other DNS?
>>> > > >> Clients seem to not be able to see replica KDC and try
>>> > > >                  to access hidden
>>> > > >> master but they can know about this master only via DNS.
>>> > >
>>> > >
>>> > > Shree, make sure that command
>>> > > $ dig -t SRV _kerberos._udp.ipa.example
>>> > > on the client returns both IPA servers (in ANSWER section).
>>> > >
>>> > > --
>>> > > Petr^2 Spacek
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > Freeipa-users mailing list
>>> > > Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com> 
>>> <mailto:Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>>
>>> > > https://www.redhat.com/mailman/listinfo/freeipa-users
>>> > >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com  <mailto:Freeipa-users at redhat.com>
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> I suggest that you temporarily try to install a client in place of 
>> the replica and see why it does not install.
>> The log above suggests that certmonger that is a part of the replica 
>> fails to connect to the first master. We need to understand the 
>> reason why it fails. Then we would be able to make your replica be a CA.
>> I suspect that CA related communication between replica and master is 
>> not going through for some reasons.
>> The install log would be really helpful.
>> Please see
>> http://www.freeipa.org/page/Troubleshooting to collect the right logs.
>>
>> -- 
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager for IdM portfolio
>> Red Hat Inc.
>>
>>
>> -------------------------------
>> Looking to carve out IT costs?
>> www.redhat.com/carveoutcosts/  <http://www.redhat.com/carveoutcosts/>
>>
>>
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com <mailto:Freeipa-users at 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/  <http://www.redhat.com/carveoutcosts/>
>
>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140309/2951fb7a/attachment.htm>

From dpal at redhat.com  Sun Mar  9 18:37:37 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sun, 09 Mar 2014 14:37:37 -0400
Subject: [Freeipa-users] Requesting Guidance on FreeIPA Replica Cluster
 across Six Nodes
In-Reply-To: <CAHWHj86pBAai1V-F8n7KPbvMgOemB8FAj8LR_Y4+S3M868aujQ@mail.gmail.com>
References: <CAHWHj86pBAai1V-F8n7KPbvMgOemB8FAj8LR_Y4+S3M868aujQ@mail.gmail.com>
Message-ID: <531CB4F1.6050803@redhat.com>

On 03/08/2014 10:47 PM, Joshua Dotson wrote:
> I posted the following in IRC.  The question was so involved that I 
> decided it would probably be best to just join the users mailing list 
> and ask here.  So, here I am.
>
> Please let me know your thoughts/questions/comments.
>
> Thanks,
> Joshua
>
> [22:29] <wrale-josh> hello.. i'm building an virtualization cluster of 
> six nodes [on a common 10GbE LAN] to house administrative functions 
> (e.g. logstash) for a mid-size environment.. i'm using gluster 
> (replica 3), ovirt self-hosted engine and freeipa.fencing will be done 
> via ipmi.distro is Fedora 19.Anyway, because FreeIPA is so fundamental 
> to the cluster and the environment at large, I'm thinking of having 
> replicas on all six servers (bare metal).. (cont.)
> [22:30] <wrale-josh> I read some about the trust relationships.I read 
> on the mailing list that upwards of 20 server environments have been 
> tested.What kind of method of trust should i use so that any two 
> servers can be down at any given time, with no loss of service?
> [22:32] <wrale-josh> I think I'd need a minimum of three FreeIPA 
> servers to gain the ability to lose two servers without service 
> interruption.Should I, for example, make nodes 2 and 3 have trust with 
> node 1 but not each other?
> [22:33] <wrale-josh> And if I were to do six nodes, what should that 
> look like, so far as trust is conerned?
> [22:36] <wrale-josh> Ahem.. And is there any odd vs. even quantity for 
> quorum analog here (ala gluster wanting even number of nodes, vs. 
> zookeeper wanting an odd number of nodes)?
> [22:36] <wrale-josh> (i think i'll just send this to the mailing 
> list).. :)
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
I think you are confusing trust and replication. You want to install 
several freeIPA replicas. Say you want 6 replicas and you want to make 
sure that the remaining replicas can talk to each other if any two are 
down. Then each replica should have at least 3 replication agreements. 
So you install replicas and then make sure that additional replication 
agreements are established.
You use ipa-replica-management  tool to do that.

Diagram shows how you would connect them.



-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140309/6144aaef/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fcegbbja.png
Type: image/png
Size: 9579 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140309/6144aaef/attachment.png>

From abokovoy at redhat.com  Sun Mar  9 19:22:52 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Sun, 9 Mar 2014 21:22:52 +0200
Subject: [Freeipa-users] Another patch for ipa-sam: Excessive LDAP calls
 by ipa-sam during file operations
In-Reply-To: <1B4C08F2-4EB6-4299-8374-4C406AD11EF7@jasonwoods.me.uk>
References: <1B4C08F2-4EB6-4299-8374-4C406AD11EF7@jasonwoods.me.uk>
Message-ID: <20140309192252.GW16644@redhat.com>

On Sun, 09 Mar 2014, Jason Woods wrote:
>Hi,
>
>A follow up from previous email regarding my patch for ipa-sam to fix
>"valid users = " group references in the samba server that comes with
>ipa-server-trust-ad.  (Found here:
>https://www.redhat.com/archives/freeipa-users/2014-March/msg00045.html
>)
>
>I noticed that ns-slapd CPU was excessive during multi-file copies
>(like a git repository with thousands of files.) Debug level 10 logs
>showed ipa-sam was performing multiple LDAP queries per file. One for
>the user and others for the groups. Specifically in order to perform
>gid/uid<->sid lookups.
>
>I've pre-empted and raised as a bug with a proposed patch:
>https://bugzilla.redhat.com/show_bug.cgi?id=1074314
>
>It does a few things:
>1. idmap caching so the ldap calls are significantly reduced
>2. when gid lookup received for the primary user group (so where
>gid==uid), properly reflect behaviour of the initial lookup that
>happens during init by returning the Default SMB Group fallback group
>3. don't bother ldap call for uidNumber=0 (root) - since it never will
>exist in FreeIPA according to my research
>My CPU for ns-slapd is now 0. And file copies are much better and more
>like normal.
>
>This seems to fix all issues for me at the moment - and I guess all
>what remains to do is extra features to make it more like the ldapsam.
>It also looks like all that is needed to get the ipa-sam.so to work
>without FreeIPA master local - is to allow the service principal access
>to the ipaNTHash attribute. However, I can't see any current aci
>referring to principals at the moment or even grouping of them into
>types - probably because I'm taking the wrong though-path - but if
>anyone would like to discuss this that would be great.
Good. I'll take that bug and will review your patch in my queue. It
will, perhaps, take some time as I have some load with stabilization
work for 3.3.x.

Anyway, you are correct that we need a service principal to be allowed
to access it. In FreeIPA 4.0 (former 3.4) we'll have new permission
management system that should make these things easier and also SSSD
1.12 is going to give us a bit more help with Samba -- there will be
talk by Sumit Bose at SambaXP in May.

I also plan to make packaging easier by creating a sub-package for
ipasam.so so that it could be installed on an IPA client, not only on 
a server. Ideally, with a tool that sets up Samba like
ipa-adtrust-server does, complete with creating all principals and
permissions.

-- 
/ Alexander Bokovoy



From devel at jasonwoods.me.uk  Sun Mar  9 22:04:43 2014
From: devel at jasonwoods.me.uk (Jason Woods)
Date: Sun, 9 Mar 2014 22:04:43 +0000
Subject: [Freeipa-users] Another patch for ipa-sam: Excessive LDAP calls
	by ipa-sam during file operations
In-Reply-To: <20140309192252.GW16644@redhat.com>
References: <1B4C08F2-4EB6-4299-8374-4C406AD11EF7@jasonwoods.me.uk>
	<20140309192252.GW16644@redhat.com>
Message-ID: <A175547C-2A73-4218-92BF-0EB334061480@jasonwoods.me.uk>

Hi,

On 9 Mar 2014, at 19.22, Alexander Bokovoy <abokovoy at redhat.com> wrote:

> Good. I'll take that bug and will review your patch in my queue. It
> will, perhaps, take some time as I have some load with stabilization
> work for 3.3.x.
Thanks.

> Anyway, you are correct that we need a service principal to be allowed
> to access it. In FreeIPA 4.0 (former 3.4) we'll have new permission
> management system that should make these things easier and also SSSD
> 1.12 is going to give us a bit more help with Samba -- there will be
> talk by Sumit Bose at SambaXP in May.

> I also plan to make packaging easier by creating a sub-package for
> ipasam.so so that it could be installed on an IPA client, not only on a server. Ideally, with a tool that sets up Samba like
> ipa-adtrust-server does, complete with creating all principals and
> permissions.

Sounds excellent, thanks. I'l look out for the talk, for sure.
If I see any other little issues I'll drop a line but all looks to be covered and in good hands. Keep up the good work!

Jason.



From mkosek at redhat.com  Mon Mar 10 07:42:19 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Mon, 10 Mar 2014 08:42:19 +0100
Subject: [Freeipa-users] Joining realm failed: SASL Bind failed Local
 error (-2)
In-Reply-To: <OF4B05E951.91821A39-ON85257C95.002482B3-85257C95.00249AF0@sita.aero>
References: <OF4B05E951.91821A39-ON85257C95.002482B3-85257C95.00249AF0@sita.aero>
Message-ID: <531D6CDB.5020009@redhat.com>

On 03/08/2014 07:39 AM, Rashard.Kelly at sita.aero wrote:
> Hello all!!
> 
> I cannot get a RHEL5.10 client to install!
> 
> [root at hostname ~]# ipa-client-install --hostname=hostname.domain.com 
> --no-ntp  --ca-cert-file=/etc/ipa/ca.crt
> DNS domain 'doman.com' is not configured for automatic KDC address lookup.
> KDC address will be set to fixed value.
> 
> Discovery was successful!
> Hostname:hostname.com
> Realm:DOMAIN.COM
> DNS Domain: domain.com
> IPA Server: ipaserver.com
> BaseDN: dc=ipa,dc=dc,dc=sita,dc=com
> 
> Joining realm failed: SASL Bind failed Local error (-2) !
> child exited with 9
> Installation failed. Rolling back changes.
> 
> 
> This is what the krb log had to say
> 
> Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29358](info): TGS_REQ (1 
> etypes {18}) 10.226.124.10: ISSUE: authtime 1394259840, etypes {rep=18 
> tkt=18 ses=18}, rkelly at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM
> Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29357](info): TGS_REQ (4 
> etypes {18 17 16 23}) 10.226.20.31: ISSUE: authtime 1394259840, etypes 
> {rep=18 tkt=18 ses=18}, rkelly at DOMAIN.COM for 
> ldap/ipaserver.domain.com at DOMAIN.COM
> krb5kdc: Cannot determine realm for numeric host address - unable to find 
> realm of host
> Mar 08 06:24:00 ipaserver at domain.como krb5kdc[29358](info): TGS_REQ (7 
> etypes {18 17 16 23 1 3 2}) 10.22.22.10: UNKNOWN_SERVER: authtime 0, 
> rkelly at IPA2.DC.SITA.AERO for ldap/10.226.20.31 at DOMAIN.COM, Server not 
> found in Kerberos database
> Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29357](info): TGS_REQ (7 
> etypes {18 17 16 23 1 3 2}) 10.22.22.10: UNKNOWN_SERVER: authtime 0, 
> rkelly at IPA2.DC.SITA.AERO for ldap/10.226.20.31 at DOMAIN.COM, Server not 
> found in Kerberos database
> 
> 
> After reviewing the https://access.redhat.com/site/solutions/231543 post 
> IPA: Joining realm failed: SASL Bind failed Local error (-2) ! child 
> exited with 9. I checked all my DNS info via dig and took a working DNS 
> config from another server. Everything appears to be setup right. 
> 
> 
> What could I be overlooking?

Looking at these error messages, I would bet that reverse records are not
right, notice the IPs instead of principal names in the KDC log. I would check
reverse records of both master and client, asked from both master and client.

Additional info here: http://www.freeipa.org/page/Troubleshooting#DNS_Issues

Martin



From pspacek at redhat.com  Mon Mar 10 08:11:23 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Mon, 10 Mar 2014 09:11:23 +0100
Subject: [Freeipa-users] install IPA replica multi-hosts (ipa packages
 version 3.3.3-18)
In-Reply-To: <5319EC61.6020105@redhat.com>
References: <1394198167.5319c6977ca6d@imp.free.fr>	<5319DB9A.2090809@redhat.com>	<1394206154.5319e5ca7b4be@imp.free.fr>
	<5319EC61.6020105@redhat.com>
Message-ID: <531D73AB.3010201@redhat.com>

On 7.3.2014 16:57, Dmitri Pal wrote:
> On 03/07/2014 10:29 AM, artjazz at free.fr wrote:
>> Selon Petr Spacek<pspacek at redhat.com>:
>>
>>> >  On 7.3.2014 14:16,artjazz at free.fr  wrote:
>>>> >  >  I want to install ipa server with a replica. The replica has 2 NICs
>>>> : the
>>> >  ipa
>>>> >  >  server is connected on the first interface and all the clients are
>>> >  connected on
>>>> >  >  the second interface. The two networks are completely separated, 2
>>>> subnets
>>> >  and
>>>> >  >  not routed.
>>> >  I'm curious - what is the reasoning behind this?:-)
>> The goal is to separate the administration flux and the userland flux.
>>
> The problem is that it is not that clean.
> One server can connect to another on different ports and using different
> protocols for different purposes. And client can actually be a proxy that does
> some admin tasks via LDAP or executes remote administrative commands.
>
> I think may be it is better to explore FW rules.
> For example create a FW rule that would allow only Kerberos and LDAP
> connections from a set of hosts that would be clients. Hm but that again would
> prevent you from enrolling new systems since the ipa-client-install connects
> to IPA via admin interface during the enrollment stage.
>
> May be there is some magic that can be done using DNS zones but I am not sure...

Let me summarize this thread to:
Sorry, this is not supported.

It becomes extremely complex very quickly and we don't have manpower to 
maintain support for this kind of scenarios.

Ideas and patches are welcome! :-)

-- 
Petr^2 Spacek



From jitseklomp at gmail.com  Mon Mar 10 12:55:57 2014
From: jitseklomp at gmail.com (Jitse Klomp)
Date: Mon, 10 Mar 2014 13:55:57 +0100
Subject: [Freeipa-users] Migration mode
Message-ID: <531DB65D.5050301@gmail.com>

Hello all,


I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
migrate-ds I used some custom scripts to import all of our users (~250)
and groups (~85) with IPA commands (ipa user-add etc.). To move
passwords I configured the ipa-server to run in migration mode and did
an ldapmodify like this:

     dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
     changetype: modify
     replace: userPassword
     userPassword: {SHA}hash

Logging in to a machine running CentOS and ipa-client for the first time
works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
works. However, logging in to Fedora 20 for the first time throws a 
'permission denied'. Logging in to Fedora works after logging in to 
CentOS or the IPA migration web ui.


sssd_domain.nl.log, loglevel 6
Fedora log: http://pastebin.centos.org/8281/
CentOS log: http://pastebin.centos.org/8286/


Additional details:
IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64

Both CentOS and Fedora are fully up-to-date using only the base repos. 
Config of the clients is done with ipa-client-install.


What am I doing wrong?

  - Jitse



From lslebodn at redhat.com  Mon Mar 10 13:35:48 2014
From: lslebodn at redhat.com (Lukas Slebodnik)
Date: Mon, 10 Mar 2014 14:35:48 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <531DB65D.5050301@gmail.com>
References: <531DB65D.5050301@gmail.com>
Message-ID: <20140310133547.GD21499@mail.corp.redhat.com>

On (10/03/14 13:55), Jitse Klomp wrote:
>Hello all,
>
>
>I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
>migrate-ds I used some custom scripts to import all of our users (~250)
>and groups (~85) with IPA commands (ipa user-add etc.). To move
>passwords I configured the ipa-server to run in migration mode and did
>an ldapmodify like this:
>
>    dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>    changetype: modify
>    replace: userPassword
>    userPassword: {SHA}hash
>
>Logging in to a machine running CentOS and ipa-client for the first time
>works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
>works. However, logging in to Fedora 20 for the first time throws a
>'permission denied'. Logging in to Fedora works after logging in to
>CentOS or the IPA migration web ui.
>
>
>sssd_domain.nl.log, loglevel 6
>Fedora log: http://pastebin.centos.org/8281/
>CentOS log: http://pastebin.centos.org/8286/
>
>
>Additional details:
>IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
    (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
    (0x0400): All data has been sent!
(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
    (0x0400): EOF received, client finished
(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [be_pam_handler_callback]
    (0x0100): Backend returned: (0, 4, <NULL>) [Success]
                                   ^^^
                                  It means  PAM_SYSTEM_ERR /* System error */

(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [be_pam_handler_callback]
    (0x0100): Sending result [4][domain.nl]
(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [be_pam_handler_callback]
    (0x0100): Sent result [4][domain.nl]
(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
    (0x0100): child [19510] finished successfully.

>
>Both CentOS and Fedora are fully up-to-date using only the base
>repos. Config of the clients is done with ipa-client-install.
>

Could you attach log files with debug_level 9?

LS



From jitseklomp at gmail.com  Mon Mar 10 13:59:44 2014
From: jitseklomp at gmail.com (Jitse Klomp)
Date: Mon, 10 Mar 2014 14:59:44 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <20140310133547.GD21499@mail.corp.redhat.com>
References: <531DB65D.5050301@gmail.com>
	<20140310133547.GD21499@mail.corp.redhat.com>
Message-ID: <531DC550.1070903@gmail.com>

On 10-03-14 14:35, Lukas Slebodnik wrote:
> On (10/03/14 13:55), Jitse Klomp wrote:
>> Hello all,
>>
>>
>> I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
>> migrate-ds I used some custom scripts to import all of our users (~250)
>> and groups (~85) with IPA commands (ipa user-add etc.). To move
>> passwords I configured the ipa-server to run in migration mode and did
>> an ldapmodify like this:
>>
>>     dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>     changetype: modify
>>     replace: userPassword
>>     userPassword: {SHA}hash
>>
>> Logging in to a machine running CentOS and ipa-client for the first time
>> works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
>> works. However, logging in to Fedora 20 for the first time throws a
>> 'permission denied'. Logging in to Fedora works after logging in to
>> CentOS or the IPA migration web ui.
>>
>>
>> sssd_domain.nl.log, loglevel 6
>> Fedora log: http://pastebin.centos.org/8281/
>> CentOS log: http://pastebin.centos.org/8286/
>>
>>
>> Additional details:
>> IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>> Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>> Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
>      (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
>      (0x0400): All data has been sent!
> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
>      (0x0400): EOF received, client finished
> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [be_pam_handler_callback]
>      (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>                                     ^^^
>                                    It means  PAM_SYSTEM_ERR /* System error */
>
> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [be_pam_handler_callback]
>      (0x0100): Sending result [4][domain.nl]
> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [be_pam_handler_callback]
>      (0x0100): Sent result [4][domain.nl]
> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
>      (0x0100): child [19510] finished successfully.
>
>>
>> Both CentOS and Fedora are fully up-to-date using only the base
>> repos. Config of the clients is done with ipa-client-install.
>>
>
> Could you attach log files with debug_level 9?
>
> LS
>

Sure. Just sssd_domain or do you need more?

sssd_domain.nl.log, loglevel 9
Fedora: http://pastebin.centos.org/8291/
CentOS: http://pastebin.centos.org/8296/

  - Jitse



From Rashard.Kelly at sita.aero  Mon Mar 10 14:11:13 2014
From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero)
Date: Mon, 10 Mar 2014 10:11:13 -0400
Subject: [Freeipa-users] Joining realm failed: SASL Bind failed Local
	error (-2)
In-Reply-To: <531D6CDB.5020009@redhat.com>
References: <OF4B05E951.91821A39-ON85257C95.002482B3-85257C95.00249AF0@sita.aero>
	<531D6CDB.5020009@redhat.com>
Message-ID: <OF36B7E745.9A0781BB-ON85257C97.004A1E25-85257C97.004DEE57@sita.aero>

Thanks for the response Martin. The DNS info is configured the same as it 
is on other clients. I did run the install in debug mode and failed at...

Starting nscd:                                             [  OK  ]

root        : DEBUG    stderr=
root        : DEBUG    args=/sbin/chkconfig nscd on
root        : DEBUG    stdout=
root        : DEBUG    stderr=
root        : DEBUG    args=/sbin/service nslcd status
root        : DEBUG    stdout=
root        : DEBUG    stderr=nslcd: unrecognized service

root        : INFO     nslcd daemon is not installed, skip configuration

what could this mean? Ldap is instslled


Thank You,
Rashard Kelly


This document is strictly confidential and intended only for use by the
addressee unless otherwise stated.  If you are not the intended recipient,
please notify the sender immediately and delete it from your system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140310/50780eec/attachment.htm>

From mkosek at redhat.com  Mon Mar 10 14:17:12 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Mon, 10 Mar 2014 15:17:12 +0100
Subject: [Freeipa-users] Joining realm failed: SASL Bind failed Local
 error (-2)
In-Reply-To: <OF36B7E745.9A0781BB-ON85257C97.004A1E25-85257C97.004DEE57@sita.aero>
References: <OF4B05E951.91821A39-ON85257C95.002482B3-85257C95.00249AF0@sita.aero>
	<531D6CDB.5020009@redhat.com>
	<OF36B7E745.9A0781BB-ON85257C97.004A1E25-85257C97.004DEE57@sita.aero>
Message-ID: <531DC968.1090303@redhat.com>

This service should be needed at all in default installation, did you maybe try
to run ipa-client-install with --no-sssd option and do not have nss-pam-ldapd
package installed?

Martin

On 03/10/2014 03:11 PM, Rashard.Kelly at sita.aero wrote:
> Thanks for the response Martin. The DNS info is configured the same as it 
> is on other clients. I did run the install in debug mode and failed at...
> 
> Starting nscd:                                             [  OK  ]
> 
> root        : DEBUG    stderr=
> root        : DEBUG    args=/sbin/chkconfig nscd on
> root        : DEBUG    stdout=
> root        : DEBUG    stderr=
> root        : DEBUG    args=/sbin/service nslcd status
> root        : DEBUG    stdout=
> root        : DEBUG    stderr=nslcd: unrecognized service
> 
> root        : INFO     nslcd daemon is not installed, skip configuration
> 
> what could this mean? Ldap is instslled
> 
> 
> Thank You,
> Rashard Kelly
> 
> 
> This document is strictly confidential and intended only for use by the
> addressee unless otherwise stated.  If you are not the intended recipient,
> please notify the sender immediately and delete it from your system.
> 
> 



From jitseklomp at gmail.com  Mon Mar 10 14:19:28 2014
From: jitseklomp at gmail.com (Jitse Klomp)
Date: Mon, 10 Mar 2014 15:19:28 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <531DC550.1070903@gmail.com>
References: <531DB65D.5050301@gmail.com>
	<20140310133547.GD21499@mail.corp.redhat.com>
	<531DC550.1070903@gmail.com>
Message-ID: <531DC9F0.4020405@gmail.com>

On 10-03-14 14:59, Jitse Klomp wrote:
> On 10-03-14 14:35, Lukas Slebodnik wrote:
>> On (10/03/14 13:55), Jitse Klomp wrote:
>>> Hello all,
>>>
>>>
>>> I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
>>> migrate-ds I used some custom scripts to import all of our users (~250)
>>> and groups (~85) with IPA commands (ipa user-add etc.). To move
>>> passwords I configured the ipa-server to run in migration mode and did
>>> an ldapmodify like this:
>>>
>>>     dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>>     changetype: modify
>>>     replace: userPassword
>>>     userPassword: {SHA}hash
>>>
>>> Logging in to a machine running CentOS and ipa-client for the first time
>>> works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
>>> works. However, logging in to Fedora 20 for the first time throws a
>>> 'permission denied'. Logging in to Fedora works after logging in to
>>> CentOS or the IPA migration web ui.
>>>
>>>
>>> sssd_domain.nl.log, loglevel 6
>>> Fedora log: http://pastebin.centos.org/8281/
>>> CentOS log: http://pastebin.centos.org/8286/
>>>
>>>
>>> Additional details:
>>> IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>>> Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>>> Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
>>      (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
>>      (0x0400): All data has been sent!
>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
>>      (0x0400): EOF received, client finished
>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>> [be_pam_handler_callback]
>>      (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>>                                     ^^^
>>                                    It means  PAM_SYSTEM_ERR /* System
>> error */
>>
>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>> [be_pam_handler_callback]
>>      (0x0100): Sending result [4][domain.nl]
>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>> [be_pam_handler_callback]
>>      (0x0100): Sent result [4][domain.nl]
>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
>>      (0x0100): child [19510] finished successfully.
>>
>>>
>>> Both CentOS and Fedora are fully up-to-date using only the base
>>> repos. Config of the clients is done with ipa-client-install.
>>>
>>
>> Could you attach log files with debug_level 9?
>>
>> LS
>>
>
> Sure. Just sssd_domain or do you need more?
>
> sssd_domain.nl.log, loglevel 9
> Fedora: http://pastebin.centos.org/8291/
> CentOS: http://pastebin.centos.org/8296/
>
>   - Jitse
>

The problem is also present in RHEL7b with ipa-client-3.3.3-5.el7.x86_64 
and sssd-1.11.2-1.el7.x86_64

sssd_domain.nl.log, loglevel 9
RHEL7b: http://pastebin.centos.org/8301/

  - Jitse



From npmccallum at redhat.com  Mon Mar 10 14:32:02 2014
From: npmccallum at redhat.com (Nathaniel McCallum)
Date: Mon, 10 Mar 2014 10:32:02 -0400
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <531BAD8E.5020502@redhat.com>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>
	<53191ED7.1000502@redhat.com>
	<CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>
	<531A4A77.6010201@redhat.com>
	<CAN0oX1ZwbPf6n_KkLOnbURg0Qic6y9QP6H7OJ8LRBH5BXfAAag@mail.gmail.com>
	<531BAD8E.5020502@redhat.com>
Message-ID: <1394461922.2147.6.camel@localhost.localdomain>

On Sat, 2014-03-08 at 18:53 -0500, Dmitri Pal wrote:
> On 03/08/2014 04:36 PM, Trey Dockendorf wrote:
> > I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no NTP).
> >
> > IPA is 3.3.3-5.el7
> > SSSD is 1.11.2-1.el7
> > krb5 is 1.11.3-31.el7
> >
> > Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted
> > the CLI commands under "Feature Management", with no luck.
> >
> > For example:
> >
> > ---
> > # ipa config-mod --user-auth-type=['password', 'otp', 'radius']
> > Usage: ipa [global-options] config-mod [options]
> >
> > ipa: error: no such option: --user-auth-type
> > ---
> >
> > The ipa subcommands "radiusproxy-*" do not exist either.
> >
> > What version of IPA should I use to test this proof of concept?  The
> > docs mention needing Kerberos no earlier than 1.12, which isn't
> > available in EL7.
> >
> > My understanding of Kerberos is not great, but is FreeIPA simply not
> > designed for external Kerberos (like the use of an external CA)?  Is
> > there possibly a way to utilize FreeIPA without Kerberos, and just
> > manage 389DS while still using the web interface (hard to find good
> > Identity Management Web UI) and CLI tools?  I'd still like to get this
> > working in FreeIPA, but am working on upgrading our HPC cluster to EL6
> > (or EL7) and moving to FreeIPA would be a great improvement over 389DS
> > in terms of manageability.
> >
> 
> Nathaniel, do we have a build of the latest bits for RHEL7 somewhere?
> Can you help with this POC please?

None of those commands will be present in EL 7.0 and we don't currently
have EL 7.0 builds of FreeIPA 4.0 master to my knowledge.

It would be possible to do this via manual manipulation of the LDAP
entries. You'd need to create an ipatokenRadiusConfiguration object and
then add the ipatokenRadiusProxyUser class (ipatokenRadiusConfigLink
attribute) to each user you'd like to proxy.

However, I don't think manual manipulation of LDAP like this is a
supported operation. I would also imagine that your University may look
down on an intentional man-in-the-middle password proxy.

Nathaniel



From jcholast at redhat.com  Mon Mar 10 14:44:01 2014
From: jcholast at redhat.com (Jan Cholasta)
Date: Mon, 10 Mar 2014 15:44:01 +0100
Subject: [Freeipa-users] install with external CA failed
In-Reply-To: <20140305234258.1641247f@ispx.vb.futz.org>
References: <20140305234258.1641247f@ispx.vb.futz.org>
Message-ID: <531DCFB1.9040506@redhat.com>

Hi,

On 6.3.2014 05:42, Robert Story wrote:
> Hi,
>
> I'm trying to install on CentOS 6.5 (ipa-server-3.0.0-37.el6.x86_64) and an
> external CA. I'm getting this error:
>
> Command '/usr/bin/sslget -v -n ipa-ca-agent -p XXXXXXXX -d /tmp/tmp-jNYt3P -r /ca/agent/ca/profileReview?requestId=6 auth.lan:9443' returned non-zero exit status 4
>
> I found a thread from back in 2012 with exact same symptoms:
>
>    https://www.redhat.com/archives/freeipa-users/2012-May/msg00357.html
>
> Unfortunately, the thread died out without any resolution/fix. When I run
> the suggested commands from that thread, I get the same results the OP did..
>
> #certutil -L -d /tmp/tmp-jNYt3P/
>
> Certificate Nickname                                         Trust Attributes
>                                                               SSL,S/MIME,JAR/XPI
>
> ipa-ca-agent                                                 u,u,u
> Certificate Authority - xxx                   CT,C,C
> testnick                                                     P,,
> xxx Certificate Authority - xxx            CT,C,C
>
> # certutil -V -u C -n ipa-ca-agent -d /tmp/tmp-jNYt3P/
> certutil: certificate is invalid: Issuer certificate is invalid.

Can you please run certutil -V on the issuer certificate (CN=Certificate 
Authority,O=xxx)? That might give us a clue why it is invalid.

>
> # certutil -L -n ipa-ca-agent -d /tmp/tmp-jNYt3P/
> Certificate:
>      Data:
>          Version: 3 (0x2)
>          Serial Number: 5 (0x5)
>          Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
>          Issuer: "CN=Certificate Authority,O=xxx"
>          Validity:
>              Not Before: Thu Mar 06 04:17:13 2014
>              Not After : Wed Feb 24 04:17:13 2016
>          Subject: "CN=ipa-ca-agent,O=xxx"
>          Subject Public Key Info:
>              Public Key Algorithm: PKCS #1 RSA Encryption
>              RSA Public Key:
>                  Modulus:
>                      bf:0c:5b:f0:14:9e:0f:26:91:21:66:62:95:0c:4d:04:
>                      e5:ec:96:6f:a1:3b:a8:05:de:1b:40:a7:7c:59:55:c4:
>                      1e:a0:62:3d:7a:50:e8:c4:8b:d7:5d:cd:55:b2:e7:f9:
>                      63:f6:43:75:1e:3d:3c:ac:51:a4:81:94:6b:e5:7f:94:
>                      d7:b2:aa:8d:e8:b6:50:f2:24:96:76:8d:5f:e9:aa:43:
>                      07:97:c8:06:2e:dc:22:9b:d1:2e:90:24:d8:07:94:33:
>                      d1:0f:44:e5:14:37:3c:96:ee:24:e0:07:91:f1:ee:c8:
>                      c4:01:e9:85:d8:35:eb:42:92:8a:58:c3:ae:e8:7d:27:
>                      4d:2d:cb:b8:97:0b:5d:e0:3c:99:8a:a8:a2:b7:e2:10:
>                      61:2b:77:33:87:ea:59:16:87:f7:f7:43:cf:c2:7b:60:
>                      3a:fc:44:2f:9e:9c:56:bc:99:0c:d0:e9:08:d6:db:f5:
>                      b1:d2:5e:28:45:d2:8f:71:1d:49:e9:41:c6:d2:e0:03:
>                      ac:85:ea:51:c6:17:5d:ed:eb:a5:11:86:40:37:cf:49:
>                      d3:cc:11:f1:3f:17:61:38:52:fa:12:a6:a0:bf:61:74:
>                      aa:3e:87:bd:ff:d1:eb:d7:c5:d7:d5:90:8f:d6:d6:e1:
>                      ab:d0:1f:db:91:8e:ff:d1:52:e3:6a:7a:fe:20:b3:53
>                  Exponent: 65537 (0x10001)
>          Signed Extensions:
>              Name: Certificate Authority Key Identifier
>              Key ID:
>                  b5:5e:45:9f:e9:71:c5:11:a2:6c:6c:06:00:be:02:ad:
>                  8e:ae:76:1b
>
>              Name: Authority Information Access
>              Method: PKIX Online Certificate Status Protocol
>              Location:
>                  URI: "http://auth.lan:80/ca/ocsp"
>
>              Name: Certificate Key Usage
>              Critical: True
>              Usages: Digital Signature
>                      Non-Repudiation
>                      Key Encipherment
>                      Data Encipherment
>
>              Name: Extended Key Usage
>                  TLS Web Client Authentication Certificate
>                  E-Mail Protection Certificate
>
>      Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
>      Signature:
>          91:e8:3c:26:1e:e6:24:35:64:95:92:10:79:9b:c3:3f:
>          3d:6c:7b:db:56:bd:98:85:31:4a:2c:6c:1f:76:e4:74:
>          8a:90:49:43:6d:16:63:f9:cc:9b:89:bd:bc:5c:fa:3b:
>          55:9e:a8:54:ce:61:fa:62:61:cf:b5:47:54:e5:70:f6:
>          d0:a0:a6:56:bf:1e:19:4d:f3:95:8a:70:1f:43:c2:6b:
>          85:bf:dd:90:6a:13:f7:58:9d:b2:40:88:d6:3a:d1:84:
>          2e:7f:b8:b8:e1:f9:5f:83:c5:d4:55:c4:a7:1a:28:a4:
>          64:fc:ac:78:3b:43:a0:00:78:db:f1:cc:a6:b6:11:70:
>          64:2f:43:d2:74:a5:2a:50:91:e0:8d:8c:82:c5:1a:5c:
>          dd:00:60:62:55:be:0a:ea:b9:75:0f:8d:0e:40:cd:26:
>          9c:63:08:3f:7d:79:c5:6b:73:fd:26:60:d3:e4:59:1e:
>          1d:0f:82:ea:eb:23:b3:b4:59:7f:a9:87:e8:01:c7:aa:
>          7b:c0:dd:0a:f0:4d:da:90:c9:57:00:4b:86:ea:58:22:
>          ff:45:11:18:25:de:09:ee:a4:7a:4a:ea:8f:17:c9:ad:
>          38:15:af:fa:c0:f3:fb:1c:6c:e1:69:1f:99:4e:fe:a2:
>          eb:66:92:77:3a:5d:8f:7a:63:9b:14:ea:95:3e:c7:e9
>      Fingerprint (MD5):
>          96:68:7A:76:9F:06:78:BC:67:85:0C:82:A8:43:14:6B
>      Fingerprint (SHA1):
>          99:7D:9F:1B:F4:A7:52:9F:CF:BF:23:4F:5B:1A:90:22:19:14:37:16
>
>      Certificate Trust Flags:
>          SSL Flags:
>              User
>          Email Flags:
>              User
>          Object Signing Flags:
>              User
>
> ... and so on...
>
> Any suggestions from anyone who has gotten an external-ca install to work?
>
>
> Robert
>
> --
> Senior Software Engineer @ Parsons

Honza

-- 
Jan Cholasta



From jhrozek at redhat.com  Mon Mar 10 15:10:18 2014
From: jhrozek at redhat.com (Jakub Hrozek)
Date: Mon, 10 Mar 2014 16:10:18 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <531DC9F0.4020405@gmail.com>
References: <531DB65D.5050301@gmail.com>
	<20140310133547.GD21499@mail.corp.redhat.com>
	<531DC550.1070903@gmail.com> <531DC9F0.4020405@gmail.com>
Message-ID: <20140310151018.GA3133@hendrix.redhat.com>

On Mon, Mar 10, 2014 at 03:19:28PM +0100, Jitse Klomp wrote:
> On 10-03-14 14:59, Jitse Klomp wrote:
> >On 10-03-14 14:35, Lukas Slebodnik wrote:
> >>On (10/03/14 13:55), Jitse Klomp wrote:
> >>>Hello all,
> >>>
> >>>
> >>>I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
> >>>migrate-ds I used some custom scripts to import all of our users (~250)
> >>>and groups (~85) with IPA commands (ipa user-add etc.). To move
> >>>passwords I configured the ipa-server to run in migration mode and did
> >>>an ldapmodify like this:
> >>>
> >>>    dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
> >>>    changetype: modify
> >>>    replace: userPassword
> >>>    userPassword: {SHA}hash
> >>>
> >>>Logging in to a machine running CentOS and ipa-client for the first time
> >>>works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
> >>>works. However, logging in to Fedora 20 for the first time throws a
> >>>'permission denied'. Logging in to Fedora works after logging in to
> >>>CentOS or the IPA migration web ui.
> >>>
> >>>
> >>>sssd_domain.nl.log, loglevel 6
> >>>Fedora log: http://pastebin.centos.org/8281/
> >>>CentOS log: http://pastebin.centos.org/8286/
> >>>
> >>>
> >>>Additional details:
> >>>IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
> >>>Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
> >>>Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
> >>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
> >>     (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
> >>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
> >>     (0x0400): All data has been sent!
> >>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
> >>     (0x0400): EOF received, client finished
> >>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
> >>[be_pam_handler_callback]
> >>     (0x0100): Backend returned: (0, 4, <NULL>) [Success]
> >>                                    ^^^
> >>                                   It means  PAM_SYSTEM_ERR /* System
> >>error */
> >>
> >>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
> >>[be_pam_handler_callback]
> >>     (0x0100): Sending result [4][domain.nl]
> >>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
> >>[be_pam_handler_callback]
> >>     (0x0100): Sent result [4][domain.nl]
> >>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
> >>     (0x0100): child [19510] finished successfully.
> >>
> >>>
> >>>Both CentOS and Fedora are fully up-to-date using only the base
> >>>repos. Config of the clients is done with ipa-client-install.
> >>>
> >>
> >>Could you attach log files with debug_level 9?
> >>
> >>LS
> >>
> >
> >Sure. Just sssd_domain or do you need more?
> >
> >sssd_domain.nl.log, loglevel 9
> >Fedora: http://pastebin.centos.org/8291/
> >CentOS: http://pastebin.centos.org/8296/
> >
> >  - Jitse
> >
> 
> The problem is also present in RHEL7b with
> ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
> 
> sssd_domain.nl.log, loglevel 9
> RHEL7b: http://pastebin.centos.org/8301/
> 
>  - Jitse

Any chance you could use the migrate-ds script to migrate users? I'm not
100% sure if your own upgrade method does the same thing..

To further analyze the System Error, we need the krb5_child.log



From lslebodn at redhat.com  Mon Mar 10 15:10:24 2014
From: lslebodn at redhat.com (Lukas Slebodnik)
Date: Mon, 10 Mar 2014 16:10:24 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <531DC9F0.4020405@gmail.com>
References: <531DB65D.5050301@gmail.com>
	<20140310133547.GD21499@mail.corp.redhat.com>
	<531DC550.1070903@gmail.com> <531DC9F0.4020405@gmail.com>
Message-ID: <20140310151023.GE21499@mail.corp.redhat.com>

On (10/03/14 15:19), Jitse Klomp wrote:
>On 10-03-14 14:59, Jitse Klomp wrote:
>>On 10-03-14 14:35, Lukas Slebodnik wrote:
>>>On (10/03/14 13:55), Jitse Klomp wrote:
>>>>Hello all,
>>>>
>>>>
>>>>I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
>>>>migrate-ds I used some custom scripts to import all of our users (~250)
>>>>and groups (~85) with IPA commands (ipa user-add etc.). To move
>>>>passwords I configured the ipa-server to run in migration mode and did
>>>>an ldapmodify like this:
>>>>
>>>>    dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>>>    changetype: modify
>>>>    replace: userPassword
>>>>    userPassword: {SHA}hash
>>>>
>>>>Logging in to a machine running CentOS and ipa-client for the first time
>>>>works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
>>>>works. However, logging in to Fedora 20 for the first time throws a
>>>>'permission denied'. Logging in to Fedora works after logging in to
>>>>CentOS or the IPA migration web ui.
>>>>
>>>>
>>>>sssd_domain.nl.log, loglevel 6
>>>>Fedora log: http://pastebin.centos.org/8281/
>>>>CentOS log: http://pastebin.centos.org/8286/
>>>>
>>>>
>>>>Additional details:
>>>>IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>>>>Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>>>>Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
>>>     (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
>>>     (0x0400): All data has been sent!
>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
>>>     (0x0400): EOF received, client finished
>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>[be_pam_handler_callback]
>>>     (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>>>                                    ^^^
>>>                                   It means  PAM_SYSTEM_ERR /* System
>>>error */
>>>
>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>[be_pam_handler_callback]
>>>     (0x0100): Sending result [4][domain.nl]
>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>[be_pam_handler_callback]
>>>     (0x0100): Sent result [4][domain.nl]
>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
>>>     (0x0100): child [19510] finished successfully.
>>>
>>>>
>>>>Both CentOS and Fedora are fully up-to-date using only the base
>>>>repos. Config of the clients is done with ipa-client-install.
>>>>
>>>
>>>Could you attach log files with debug_level 9?
>>>
>>>LS
>>>
>>
>>Sure. Just sssd_domain or do you need more?
>>
Are you using two different ipa servers?
ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl

>>sssd_domain.nl.log, loglevel 9
>>Fedora: http://pastebin.centos.org/8291/
Constructed uri 'ldap://vm-ipa.domain.nl'

>>CentOS: http://pastebin.centos.org/8296/
Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'

>>
>>  - Jitse
>>
>
>The problem is also present in RHEL7b with
>ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
>
>sssd_domain.nl.log, loglevel 9
>RHEL7b: http://pastebin.centos.org/8301/
Constructed uri 'ldap://vm-ipa.domain.nl'

Could you also provide krb5_child.log and ldap_child.log from fedora machine?
    (debug_level 9)

LS



From artjazz at free.fr  Mon Mar 10 15:16:05 2014
From: artjazz at free.fr (artjazz at free.fr)
Date: Mon, 10 Mar 2014 16:16:05 +0100
Subject: [Freeipa-users] install IPA replica multi-hosts (ipa packages
	version 3.3.3-18)
In-Reply-To: <531D73AB.3010201@redhat.com>
References: <1394198167.5319c6977ca6d@imp.free.fr>
	<5319DB9A.2090809@redhat.com>
	<1394206154.5319e5ca7b4be@imp.free.fr>
	<5319EC61.6020105@redhat.com> <531D73AB.3010201@redhat.com>
Message-ID: <1394464565.531dd73570eac@imp.free.fr>

Selon Petr Spacek <pspacek at redhat.com>:

> On 7.3.2014 16:57, Dmitri Pal wrote:
> > On 03/07/2014 10:29 AM, artjazz at free.fr wrote:
> >> Selon Petr Spacek<pspacek at redhat.com>:
> >>
> >>> >  On 7.3.2014 14:16,artjazz at free.fr  wrote:
> >>>> >  >  I want to install ipa server with a replica. The replica has 2
> NICs
> >>>> : the
> >>> >  ipa
> >>>> >  >  server is connected on the first interface and all the clients are
> >>> >  connected on
> >>>> >  >  the second interface. The two networks are completely separated, 2
> >>>> subnets
> >>> >  and
> >>>> >  >  not routed.
> >>> >  I'm curious - what is the reasoning behind this?:-)
> >> The goal is to separate the administration flux and the userland flux.
> >>
> > The problem is that it is not that clean.
> > One server can connect to another on different ports and using different
> > protocols for different purposes. And client can actually be a proxy that
> does
> > some admin tasks via LDAP or executes remote administrative commands.
> >
> > I think may be it is better to explore FW rules.
> > For example create a FW rule that would allow only Kerberos and LDAP
> > connections from a set of hosts that would be clients. Hm but that again
> would
> > prevent you from enrolling new systems since the ipa-client-install
> connects
> > to IPA via admin interface during the enrollment stage.
> >
> > May be there is some magic that can be done using DNS zones but I am not
> sure...
>
> Let me summarize this thread to:
> Sorry, this is not supported.

Thanks for your answer; It's clear for me now, I understand why my different
tests didn't work.

Just for my information because it's a little bit confusing when I read in the
FreeIPA_Guide (Fedora18)  the following sentence:
19.5. Setting DNS Entries for Multi-Homed Servers
Some server machines may support multiple network interface cards (NICs).
Multi-homed machines typically have multiple IPs, all assigned to the same
hostname. This works fine in FreeIPA most of the time because it listens on all
available interfaces, except localhost. For a server to be available through any
NIC, edit the DNS zone file and add entries for each IP address. For example:
ipaserver  IN A  192.168.1.100
ipaserver  IN A  192.168.1.101
ipaserver  IN A  192.168.1.102

What is the architecture of the Multi-Homed Servers in this case ?

> It becomes extremely complex very quickly and we don't have manpower to
> maintain support for this kind of scenarios.
I understand well.

> Ideas and patches are welcome! :-)
I can try to think about it.
Best Regards.

>
> --
> Petr^2 Spacek
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>




From jitseklomp at gmail.com  Mon Mar 10 15:35:31 2014
From: jitseklomp at gmail.com (Jitse Klomp)
Date: Mon, 10 Mar 2014 16:35:31 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <20140310151023.GE21499@mail.corp.redhat.com>
References: <531DB65D.5050301@gmail.com>
	<20140310133547.GD21499@mail.corp.redhat.com>
	<531DC550.1070903@gmail.com> <531DC9F0.4020405@gmail.com>
	<20140310151023.GE21499@mail.corp.redhat.com>
Message-ID: <531DDBC3.4060700@gmail.com>

On 10-03-14 16:10, Lukas Slebodnik wrote:
> On (10/03/14 15:19), Jitse Klomp wrote:
>> On 10-03-14 14:59, Jitse Klomp wrote:
>>> On 10-03-14 14:35, Lukas Slebodnik wrote:
>>>> On (10/03/14 13:55), Jitse Klomp wrote:
>>>>> Hello all,
>>>>>
>>>>>
>>>>> I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
>>>>> migrate-ds I used some custom scripts to import all of our users (~250)
>>>>> and groups (~85) with IPA commands (ipa user-add etc.). To move
>>>>> passwords I configured the ipa-server to run in migration mode and did
>>>>> an ldapmodify like this:
>>>>>
>>>>>     dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>>>>     changetype: modify
>>>>>     replace: userPassword
>>>>>     userPassword: {SHA}hash
>>>>>
>>>>> Logging in to a machine running CentOS and ipa-client for the first time
>>>>> works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
>>>>> works. However, logging in to Fedora 20 for the first time throws a
>>>>> 'permission denied'. Logging in to Fedora works after logging in to
>>>>> CentOS or the IPA migration web ui.
>>>>>
>>>>>
>>>>> sssd_domain.nl.log, loglevel 6
>>>>> Fedora log: http://pastebin.centos.org/8281/
>>>>> CentOS log: http://pastebin.centos.org/8286/
>>>>>
>>>>>
>>>>> Additional details:
>>>>> IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>>>>> Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>>>>> Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
>>>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
>>>>      (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
>>>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
>>>>      (0x0400): All data has been sent!
>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
>>>>      (0x0400): EOF received, client finished
>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>> [be_pam_handler_callback]
>>>>      (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>>>>                                     ^^^
>>>>                                    It means  PAM_SYSTEM_ERR /* System
>>>> error */
>>>>
>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>> [be_pam_handler_callback]
>>>>      (0x0100): Sending result [4][domain.nl]
>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>> [be_pam_handler_callback]
>>>>      (0x0100): Sent result [4][domain.nl]
>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
>>>>      (0x0100): child [19510] finished successfully.
>>>>
>>>>>
>>>>> Both CentOS and Fedora are fully up-to-date using only the base
>>>>> repos. Config of the clients is done with ipa-client-install.
>>>>>
>>>>
>>>> Could you attach log files with debug_level 9?
>>>>
>>>> LS
>>>>
>>>
>>> Sure. Just sssd_domain or do you need more?
>>>
> Are you using two different ipa servers?
> ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
>
>>> sssd_domain.nl.log, loglevel 9
>>> Fedora: http://pastebin.centos.org/8291/
> Constructed uri 'ldap://vm-ipa.domain.nl'
>
>>> CentOS: http://pastebin.centos.org/8296/
> Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
>
>>>
>>>   - Jitse
>>>
>>
>> The problem is also present in RHEL7b with
>> ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
>>
>> sssd_domain.nl.log, loglevel 9
>> RHEL7b: http://pastebin.centos.org/8301/
> Constructed uri 'ldap://vm-ipa.domain.nl'
>
> Could you also provide krb5_child.log and ldap_child.log from fedora machine?
>      (debug_level 9)
>
> LS
>

No, I'm using only one ipa server (vm-ipa). I accidentally copy-pasted 
without changing the domain name ;)

 > Any chance you could use the migrate-ds script to migrate users? I'm
 > not 100% sure if your own upgrade method does the same thing..
I don't think so, our old LDAP schema is a mess...

krb5_child.log: http://pastebin.centos.org/8306/
ldap_child.log: http://pastebin.centos.org/8311/

  - Jitse



From lslebodn at redhat.com  Mon Mar 10 15:58:10 2014
From: lslebodn at redhat.com (Lukas Slebodnik)
Date: Mon, 10 Mar 2014 16:58:10 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <531DDBC3.4060700@gmail.com>
References: <531DB65D.5050301@gmail.com>
	<20140310133547.GD21499@mail.corp.redhat.com>
	<531DC550.1070903@gmail.com> <531DC9F0.4020405@gmail.com>
	<20140310151023.GE21499@mail.corp.redhat.com>
	<531DDBC3.4060700@gmail.com>
Message-ID: <20140310155809.GG21499@mail.corp.redhat.com>

On (10/03/14 16:35), Jitse Klomp wrote:
>On 10-03-14 16:10, Lukas Slebodnik wrote:
>>On (10/03/14 15:19), Jitse Klomp wrote:
>>>On 10-03-14 14:59, Jitse Klomp wrote:
>>>>On 10-03-14 14:35, Lukas Slebodnik wrote:
>>>>>On (10/03/14 13:55), Jitse Klomp wrote:
>>>>>>Hello all,
>>>>>>
>>>>>>
>>>>>>I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
>>>>>>migrate-ds I used some custom scripts to import all of our users (~250)
>>>>>>and groups (~85) with IPA commands (ipa user-add etc.). To move
>>>>>>passwords I configured the ipa-server to run in migration mode and did
>>>>>>an ldapmodify like this:
>>>>>>
>>>>>>    dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>>>>>    changetype: modify
>>>>>>    replace: userPassword
>>>>>>    userPassword: {SHA}hash
>>>>>>
>>>>>>Logging in to a machine running CentOS and ipa-client for the first time
>>>>>>works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
>>>>>>works. However, logging in to Fedora 20 for the first time throws a
>>>>>>'permission denied'. Logging in to Fedora works after logging in to
>>>>>>CentOS or the IPA migration web ui.
>>>>>>
>>>>>>
>>>>>>sssd_domain.nl.log, loglevel 6
>>>>>>Fedora log: http://pastebin.centos.org/8281/
>>>>>>CentOS log: http://pastebin.centos.org/8286/
>>>>>>
>>>>>>
>>>>>>Additional details:
>>>>>>IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>>>>>>Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>>>>>>Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
>>>>>     (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
>>>>>     (0x0400): All data has been sent!
>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
>>>>>     (0x0400): EOF received, client finished
>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>[be_pam_handler_callback]
>>>>>     (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>>>>>                                    ^^^
>>>>>                                   It means  PAM_SYSTEM_ERR /* System
>>>>>error */
>>>>>
>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>[be_pam_handler_callback]
>>>>>     (0x0100): Sending result [4][domain.nl]
>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>[be_pam_handler_callback]
>>>>>     (0x0100): Sent result [4][domain.nl]
>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
>>>>>     (0x0100): child [19510] finished successfully.
>>>>>
>>>>>>
>>>>>>Both CentOS and Fedora are fully up-to-date using only the base
>>>>>>repos. Config of the clients is done with ipa-client-install.
>>>>>>
>>>>>
>>>>>Could you attach log files with debug_level 9?
>>>>>
>>>>>LS
>>>>>
>>>>
>>>>Sure. Just sssd_domain or do you need more?
>>>>
>>Are you using two different ipa servers?
>>ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
>>
>>>>sssd_domain.nl.log, loglevel 9
>>>>Fedora: http://pastebin.centos.org/8291/
>>Constructed uri 'ldap://vm-ipa.domain.nl'
>>
>>>>CentOS: http://pastebin.centos.org/8296/
>>Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
>>
>>>>
>>>>  - Jitse
>>>>
>>>
>>>The problem is also present in RHEL7b with
>>>ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
>>>
>>>sssd_domain.nl.log, loglevel 9
>>>RHEL7b: http://pastebin.centos.org/8301/
>>Constructed uri 'ldap://vm-ipa.domain.nl'
>>
>>Could you also provide krb5_child.log and ldap_child.log from fedora machine?
>>     (debug_level 9)
>>
>>LS
>>
>
>No, I'm using only one ipa server (vm-ipa). I accidentally
>copy-pasted without changing the domain name ;)
>
>> Any chance you could use the migrate-ds script to migrate users? I'm
>> not 100% sure if your own upgrade method does the same thing..
>I don't think so, our old LDAP schema is a mess...
>
>krb5_child.log: http://pastebin.centos.org/8306/

[sss_child_krb5_trace_cb] (0x4000): [24671]
    1394465217.407384: Getting initial credentials for jitse at DOMAIN.NL
[sss_child_krb5_trace_cb] (0x4000): [24671]
    1394465217.407699: Sending request (173 bytes) to DOMAIN.NL
[sss_child_krb5_trace_cb] (0x4000): [24671]
    1394465217.408202: Sending initial UDP request to dgram 10.14.3.15:88
[sss_child_krb5_trace_cb] (0x4000): [24671]
    1394465217.425034: Received answer from dgram 10.14.3.15:88
[sss_child_krb5_trace_cb] (0x4000): [24671]
    1394465217.425171: Response was from master KDC
[sss_child_krb5_trace_cb] (0x4000): [24671]
    1394465217.425241: Received error from KDC: -1765328361/Password has expired
[get_and_save_tgt] (0x0020): 918: [-1765328361][Password has expired]
[tgt_req_child] (0x1000): Password was expired

It looks like password is expired for user jitse.

LS

>ldap_child.log: http://pastebin.centos.org/8311/
>
> - Jitse



From lslebodn at redhat.com  Mon Mar 10 16:03:01 2014
From: lslebodn at redhat.com (Lukas Slebodnik)
Date: Mon, 10 Mar 2014 17:03:01 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <20140310155809.GG21499@mail.corp.redhat.com>
References: <531DB65D.5050301@gmail.com>
	<20140310133547.GD21499@mail.corp.redhat.com>
	<531DC550.1070903@gmail.com> <531DC9F0.4020405@gmail.com>
	<20140310151023.GE21499@mail.corp.redhat.com>
	<531DDBC3.4060700@gmail.com>
	<20140310155809.GG21499@mail.corp.redhat.com>
Message-ID: <20140310160301.GH21499@mail.corp.redhat.com>

On (10/03/14 16:58), Lukas Slebodnik wrote:
>On (10/03/14 16:35), Jitse Klomp wrote:
>>On 10-03-14 16:10, Lukas Slebodnik wrote:
>>>On (10/03/14 15:19), Jitse Klomp wrote:
>>>>On 10-03-14 14:59, Jitse Klomp wrote:
>>>>>On 10-03-14 14:35, Lukas Slebodnik wrote:
>>>>>>On (10/03/14 13:55), Jitse Klomp wrote:
>>>>>>>Hello all,
>>>>>>>
>>>>>>>
>>>>>>>I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
>>>>>>>migrate-ds I used some custom scripts to import all of our users (~250)
>>>>>>>and groups (~85) with IPA commands (ipa user-add etc.). To move
>>>>>>>passwords I configured the ipa-server to run in migration mode and did
>>>>>>>an ldapmodify like this:
>>>>>>>
>>>>>>>    dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>>>>>>    changetype: modify
>>>>>>>    replace: userPassword
>>>>>>>    userPassword: {SHA}hash
>>>>>>>
>>>>>>>Logging in to a machine running CentOS and ipa-client for the first time
>>>>>>>works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
>>>>>>>works. However, logging in to Fedora 20 for the first time throws a
>>>>>>>'permission denied'. Logging in to Fedora works after logging in to
>>>>>>>CentOS or the IPA migration web ui.
>>>>>>>
>>>>>>>
>>>>>>>sssd_domain.nl.log, loglevel 6
>>>>>>>Fedora log: http://pastebin.centos.org/8281/
>>>>>>>CentOS log: http://pastebin.centos.org/8286/
>>>>>>>
>>>>>>>
>>>>>>>Additional details:
>>>>>>>IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>>>>>>>Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>>>>>>>Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
>>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
>>>>>>     (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
>>>>>>     (0x0400): All data has been sent!
>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
>>>>>>     (0x0400): EOF received, client finished
>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>[be_pam_handler_callback]
>>>>>>     (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>>>>>>                                    ^^^
>>>>>>                                   It means  PAM_SYSTEM_ERR /* System
>>>>>>error */
>>>>>>
>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>[be_pam_handler_callback]
>>>>>>     (0x0100): Sending result [4][domain.nl]
>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>[be_pam_handler_callback]
>>>>>>     (0x0100): Sent result [4][domain.nl]
>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
>>>>>>     (0x0100): child [19510] finished successfully.
>>>>>>
>>>>>>>
>>>>>>>Both CentOS and Fedora are fully up-to-date using only the base
>>>>>>>repos. Config of the clients is done with ipa-client-install.
>>>>>>>
>>>>>>
>>>>>>Could you attach log files with debug_level 9?
>>>>>>
>>>>>>LS
>>>>>>
>>>>>
>>>>>Sure. Just sssd_domain or do you need more?
>>>>>
>>>Are you using two different ipa servers?
>>>ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
>>>
>>>>>sssd_domain.nl.log, loglevel 9
>>>>>Fedora: http://pastebin.centos.org/8291/
>>>Constructed uri 'ldap://vm-ipa.domain.nl'
>>>
>>>>>CentOS: http://pastebin.centos.org/8296/
>>>Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
>>>
>>>>>
>>>>>  - Jitse
>>>>>
>>>>
>>>>The problem is also present in RHEL7b with
>>>>ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
>>>>
>>>>sssd_domain.nl.log, loglevel 9
>>>>RHEL7b: http://pastebin.centos.org/8301/
>>>Constructed uri 'ldap://vm-ipa.domain.nl'
>>>
>>>Could you also provide krb5_child.log and ldap_child.log from fedora machine?
>>>     (debug_level 9)
>>>
>>>LS
>>>
>>
>>No, I'm using only one ipa server (vm-ipa). I accidentally
>>copy-pasted without changing the domain name ;)
>>
>>> Any chance you could use the migrate-ds script to migrate users? I'm
>>> not 100% sure if your own upgrade method does the same thing..
>>I don't think so, our old LDAP schema is a mess...
>>
>>krb5_child.log: http://pastebin.centos.org/8306/
>
>[sss_child_krb5_trace_cb] (0x4000): [24671]
>    1394465217.407384: Getting initial credentials for jitse at DOMAIN.NL
>[sss_child_krb5_trace_cb] (0x4000): [24671]
>    1394465217.407699: Sending request (173 bytes) to DOMAIN.NL
>[sss_child_krb5_trace_cb] (0x4000): [24671]
>    1394465217.408202: Sending initial UDP request to dgram 10.14.3.15:88
>[sss_child_krb5_trace_cb] (0x4000): [24671]
>    1394465217.425034: Received answer from dgram 10.14.3.15:88
>[sss_child_krb5_trace_cb] (0x4000): [24671]
>    1394465217.425171: Response was from master KDC
>[sss_child_krb5_trace_cb] (0x4000): [24671]
>    1394465217.425241: Received error from KDC: -1765328361/Password has expired
>[get_and_save_tgt] (0x0020): 918: [-1765328361][Password has expired]
>[tgt_req_child] (0x1000): Password was expired
>
>It looks like password is expired for user jitse.
>
My hands were faster than my mind.

I wanted to wrote:
It looks like password is expired for user jitse.
It is really weird because it works on Centos.
Do you have a synchronized time on all machines with ipa server?

LS



From jitseklomp at gmail.com  Mon Mar 10 16:23:59 2014
From: jitseklomp at gmail.com (Jitse Klomp)
Date: Mon, 10 Mar 2014 17:23:59 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <20140310160301.GH21499@mail.corp.redhat.com>
References: <531DB65D.5050301@gmail.com>
	<20140310133547.GD21499@mail.corp.redhat.com>
	<531DC550.1070903@gmail.com> <531DC9F0.4020405@gmail.com>
	<20140310151023.GE21499@mail.corp.redhat.com>
	<531DDBC3.4060700@gmail.com>
	<20140310155809.GG21499@mail.corp.redhat.com>
	<20140310160301.GH21499@mail.corp.redhat.com>
Message-ID: <531DE71F.5000907@gmail.com>

On 10-03-14 17:03, Lukas Slebodnik wrote:
> On (10/03/14 16:58), Lukas Slebodnik wrote:
>> On (10/03/14 16:35), Jitse Klomp wrote:
>>> On 10-03-14 16:10, Lukas Slebodnik wrote:
>>>> On (10/03/14 15:19), Jitse Klomp wrote:
>>>>> On 10-03-14 14:59, Jitse Klomp wrote:
>>>>>> On 10-03-14 14:35, Lukas Slebodnik wrote:
>>>>>>> On (10/03/14 13:55), Jitse Klomp wrote:
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
>>>>>>>> migrate-ds I used some custom scripts to import all of our users (~250)
>>>>>>>> and groups (~85) with IPA commands (ipa user-add etc.). To move
>>>>>>>> passwords I configured the ipa-server to run in migration mode and did
>>>>>>>> an ldapmodify like this:
>>>>>>>>
>>>>>>>>     dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>>>>>>>     changetype: modify
>>>>>>>>     replace: userPassword
>>>>>>>>     userPassword: {SHA}hash
>>>>>>>>
>>>>>>>> Logging in to a machine running CentOS and ipa-client for the first time
>>>>>>>> works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
>>>>>>>> works. However, logging in to Fedora 20 for the first time throws a
>>>>>>>> 'permission denied'. Logging in to Fedora works after logging in to
>>>>>>>> CentOS or the IPA migration web ui.
>>>>>>>>
>>>>>>>>
>>>>>>>> sssd_domain.nl.log, loglevel 6
>>>>>>>> Fedora log: http://pastebin.centos.org/8281/
>>>>>>>> CentOS log: http://pastebin.centos.org/8286/
>>>>>>>>
>>>>>>>>
>>>>>>>> Additional details:
>>>>>>>> IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>>>>>>>> Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>>>>>>>> Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
>>>>>>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
>>>>>>>      (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
>>>>>>>      (0x0400): All data has been sent!
>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
>>>>>>>      (0x0400): EOF received, client finished
>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>> [be_pam_handler_callback]
>>>>>>>      (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>>>>>>>                                     ^^^
>>>>>>>                                    It means  PAM_SYSTEM_ERR /* System
>>>>>>> error */
>>>>>>>
>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>> [be_pam_handler_callback]
>>>>>>>      (0x0100): Sending result [4][domain.nl]
>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>> [be_pam_handler_callback]
>>>>>>>      (0x0100): Sent result [4][domain.nl]
>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
>>>>>>>      (0x0100): child [19510] finished successfully.
>>>>>>>
>>>>>>>>
>>>>>>>> Both CentOS and Fedora are fully up-to-date using only the base
>>>>>>>> repos. Config of the clients is done with ipa-client-install.
>>>>>>>>
>>>>>>>
>>>>>>> Could you attach log files with debug_level 9?
>>>>>>>
>>>>>>> LS
>>>>>>>
>>>>>>
>>>>>> Sure. Just sssd_domain or do you need more?
>>>>>>
>>>> Are you using two different ipa servers?
>>>> ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
>>>>
>>>>>> sssd_domain.nl.log, loglevel 9
>>>>>> Fedora: http://pastebin.centos.org/8291/
>>>> Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>
>>>>>> CentOS: http://pastebin.centos.org/8296/
>>>> Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
>>>>
>>>>>>
>>>>>>   - Jitse
>>>>>>
>>>>>
>>>>> The problem is also present in RHEL7b with
>>>>> ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
>>>>>
>>>>> sssd_domain.nl.log, loglevel 9
>>>>> RHEL7b: http://pastebin.centos.org/8301/
>>>> Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>
>>>> Could you also provide krb5_child.log and ldap_child.log from fedora machine?
>>>>      (debug_level 9)
>>>>
>>>> LS
>>>>
>>>
>>> No, I'm using only one ipa server (vm-ipa). I accidentally
>>> copy-pasted without changing the domain name ;)
>>>
>>>> Any chance you could use the migrate-ds script to migrate users? I'm
>>>> not 100% sure if your own upgrade method does the same thing..
>>> I don't think so, our old LDAP schema is a mess...
>>>
>>> krb5_child.log: http://pastebin.centos.org/8306/
>>
>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>     1394465217.407384: Getting initial credentials for jitse at DOMAIN.NL
>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>     1394465217.407699: Sending request (173 bytes) to DOMAIN.NL
>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>     1394465217.408202: Sending initial UDP request to dgram 10.14.3.15:88
>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>     1394465217.425034: Received answer from dgram 10.14.3.15:88
>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>     1394465217.425171: Response was from master KDC
>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>     1394465217.425241: Received error from KDC: -1765328361/Password has expired
>> [get_and_save_tgt] (0x0020): 918: [-1765328361][Password has expired]
>> [tgt_req_child] (0x1000): Password was expired
>>
>> It looks like password is expired for user jitse.
>>
> My hands were faster than my mind.
>
> I wanted to wrote:
> It looks like password is expired for user jitse.
> It is really weird because it works on Centos.
> Do you have a synchronized time on all machines with ipa server?
>
> LS

Yes, time is in sync across all machines. I think the most interesting 
lines in the log are these:

(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] 
[sss_child_krb5_trace_cb] (0x4000): [24671] 1394465217.441823: 
Processing preauth types: 136, 19, 2, 133

(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] [map_krb5_error] 
(0x0020): 979: [-1765328234][Program lacks support for encryption type]

(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] 
[pack_response_packet] (0x2000): response packet size: [4]

(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] [k5c_send_data] 
(0x4000): Response sent.

(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] [main] (0x0400): 
krb5_child completed successfully

This is where krb5_child on fedora just stops working while krb5_child 
on CentOS does this: http://pastebin.centos.org/8316/


  - Jitse









From rcritten at redhat.com  Mon Mar 10 17:25:10 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 10 Mar 2014 13:25:10 -0400
Subject: [Freeipa-users] Migration mode
In-Reply-To: <20140310160301.GH21499@mail.corp.redhat.com>
References: <531DB65D.5050301@gmail.com>	<20140310133547.GD21499@mail.corp.redhat.com>	<531DC550.1070903@gmail.com>
	<531DC9F0.4020405@gmail.com>	<20140310151023.GE21499@mail.corp.redhat.com>	<531DDBC3.4060700@gmail.com>	<20140310155809.GG21499@mail.corp.redhat.com>
	<20140310160301.GH21499@mail.corp.redhat.com>
Message-ID: <531DF576.70304@redhat.com>

Lukas Slebodnik wrote:
> On (10/03/14 16:58), Lukas Slebodnik wrote:
>> On (10/03/14 16:35), Jitse Klomp wrote:
>>> On 10-03-14 16:10, Lukas Slebodnik wrote:
>>>> On (10/03/14 15:19), Jitse Klomp wrote:
>>>>> On 10-03-14 14:59, Jitse Klomp wrote:
>>>>>> On 10-03-14 14:35, Lukas Slebodnik wrote:
>>>>>>> On (10/03/14 13:55), Jitse Klomp wrote:
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
>>>>>>>> migrate-ds I used some custom scripts to import all of our users (~250)
>>>>>>>> and groups (~85) with IPA commands (ipa user-add etc.). To move
>>>>>>>> passwords I configured the ipa-server to run in migration mode and did
>>>>>>>> an ldapmodify like this:
>>>>>>>>
>>>>>>>>     dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>>>>>>>     changetype: modify
>>>>>>>>     replace: userPassword
>>>>>>>>     userPassword: {SHA}hash
>>>>>>>>
>>>>>>>> Logging in to a machine running CentOS and ipa-client for the first time
>>>>>>>> works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
>>>>>>>> works. However, logging in to Fedora 20 for the first time throws a
>>>>>>>> 'permission denied'. Logging in to Fedora works after logging in to
>>>>>>>> CentOS or the IPA migration web ui.
>>>>>>>>
>>>>>>>>
>>>>>>>> sssd_domain.nl.log, loglevel 6
>>>>>>>> Fedora log: http://pastebin.centos.org/8281/
>>>>>>>> CentOS log: http://pastebin.centos.org/8286/
>>>>>>>>
>>>>>>>>
>>>>>>>> Additional details:
>>>>>>>> IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>>>>>>>> Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>>>>>>>> Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
>>>>>>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
>>>>>>>      (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
>>>>>>>      (0x0400): All data has been sent!
>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
>>>>>>>      (0x0400): EOF received, client finished
>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>> [be_pam_handler_callback]
>>>>>>>      (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>>>>>>>                                     ^^^
>>>>>>>                                    It means  PAM_SYSTEM_ERR /* System
>>>>>>> error */
>>>>>>>
>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>> [be_pam_handler_callback]
>>>>>>>      (0x0100): Sending result [4][domain.nl]
>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>> [be_pam_handler_callback]
>>>>>>>      (0x0100): Sent result [4][domain.nl]
>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
>>>>>>>      (0x0100): child [19510] finished successfully.
>>>>>>>
>>>>>>>>
>>>>>>>> Both CentOS and Fedora are fully up-to-date using only the base
>>>>>>>> repos. Config of the clients is done with ipa-client-install.
>>>>>>>>
>>>>>>>
>>>>>>> Could you attach log files with debug_level 9?
>>>>>>>
>>>>>>> LS
>>>>>>>
>>>>>>
>>>>>> Sure. Just sssd_domain or do you need more?
>>>>>>
>>>> Are you using two different ipa servers?
>>>> ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
>>>>
>>>>>> sssd_domain.nl.log, loglevel 9
>>>>>> Fedora: http://pastebin.centos.org/8291/
>>>> Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>
>>>>>> CentOS: http://pastebin.centos.org/8296/
>>>> Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
>>>>
>>>>>>
>>>>>>   - Jitse
>>>>>>
>>>>>
>>>>> The problem is also present in RHEL7b with
>>>>> ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
>>>>>
>>>>> sssd_domain.nl.log, loglevel 9
>>>>> RHEL7b: http://pastebin.centos.org/8301/
>>>> Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>
>>>> Could you also provide krb5_child.log and ldap_child.log from fedora machine?
>>>>      (debug_level 9)
>>>>
>>>> LS
>>>>
>>>
>>> No, I'm using only one ipa server (vm-ipa). I accidentally
>>> copy-pasted without changing the domain name ;)
>>>
>>>> Any chance you could use the migrate-ds script to migrate users? I'm
>>>> not 100% sure if your own upgrade method does the same thing..
>>> I don't think so, our old LDAP schema is a mess...
>>>
>>> krb5_child.log: http://pastebin.centos.org/8306/
>>
>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>     1394465217.407384: Getting initial credentials for jitse at DOMAIN.NL
>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>     1394465217.407699: Sending request (173 bytes) to DOMAIN.NL
>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>     1394465217.408202: Sending initial UDP request to dgram 10.14.3.15:88
>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>     1394465217.425034: Received answer from dgram 10.14.3.15:88
>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>     1394465217.425171: Response was from master KDC
>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>     1394465217.425241: Received error from KDC: -1765328361/Password has expired
>> [get_and_save_tgt] (0x0020): 918: [-1765328361][Password has expired]
>> [tgt_req_child] (0x1000): Password was expired
>>
>> It looks like password is expired for user jitse.
>>
> My hands were faster than my mind.
>
> I wanted to wrote:
> It looks like password is expired for user jitse.
> It is really weird because it works on Centos.
> Do you have a synchronized time on all machines with ipa server?

I'd be curious what the krbPasswordExpiration is for this user.

rob



From sbose at redhat.com  Mon Mar 10 17:57:33 2014
From: sbose at redhat.com (Sumit Bose)
Date: Mon, 10 Mar 2014 18:57:33 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <531DE71F.5000907@gmail.com>
References: <531DB65D.5050301@gmail.com>
	<20140310133547.GD21499@mail.corp.redhat.com>
	<531DC550.1070903@gmail.com> <531DC9F0.4020405@gmail.com>
	<20140310151023.GE21499@mail.corp.redhat.com>
	<531DDBC3.4060700@gmail.com>
	<20140310155809.GG21499@mail.corp.redhat.com>
	<20140310160301.GH21499@mail.corp.redhat.com>
	<531DE71F.5000907@gmail.com>
Message-ID: <20140310175733.GN2763@localhost.localdomain>

On Mon, Mar 10, 2014 at 05:23:59PM +0100, Jitse Klomp wrote:
> On 10-03-14 17:03, Lukas Slebodnik wrote:
> >On (10/03/14 16:58), Lukas Slebodnik wrote:
> >>On (10/03/14 16:35), Jitse Klomp wrote:
> >>>On 10-03-14 16:10, Lukas Slebodnik wrote:
> >>>>On (10/03/14 15:19), Jitse Klomp wrote:
> >>>>>On 10-03-14 14:59, Jitse Klomp wrote:
> >>>>>>On 10-03-14 14:35, Lukas Slebodnik wrote:
> >>>>>>>On (10/03/14 13:55), Jitse Klomp wrote:
> >>>>>>>>Hello all,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
> >>>>>>>>migrate-ds I used some custom scripts to import all of our users (~250)
> >>>>>>>>and groups (~85) with IPA commands (ipa user-add etc.). To move
> >>>>>>>>passwords I configured the ipa-server to run in migration mode and did
> >>>>>>>>an ldapmodify like this:
> >>>>>>>>
> >>>>>>>>    dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
> >>>>>>>>    changetype: modify
> >>>>>>>>    replace: userPassword
> >>>>>>>>    userPassword: {SHA}hash
> >>>>>>>>
> >>>>>>>>Logging in to a machine running CentOS and ipa-client for the first time
> >>>>>>>>works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
> >>>>>>>>works. However, logging in to Fedora 20 for the first time throws a
> >>>>>>>>'permission denied'. Logging in to Fedora works after logging in to
> >>>>>>>>CentOS or the IPA migration web ui.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>sssd_domain.nl.log, loglevel 6
> >>>>>>>>Fedora log: http://pastebin.centos.org/8281/
> >>>>>>>>CentOS log: http://pastebin.centos.org/8286/
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>Additional details:
> >>>>>>>>IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
> >>>>>>>>Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
> >>>>>>>>Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
> >>>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
> >>>>>>>     (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
> >>>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
> >>>>>>>     (0x0400): All data has been sent!
> >>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
> >>>>>>>     (0x0400): EOF received, client finished
> >>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
> >>>>>>>[be_pam_handler_callback]
> >>>>>>>     (0x0100): Backend returned: (0, 4, <NULL>) [Success]
> >>>>>>>                                    ^^^
> >>>>>>>                                   It means  PAM_SYSTEM_ERR /* System
> >>>>>>>error */
> >>>>>>>
> >>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
> >>>>>>>[be_pam_handler_callback]
> >>>>>>>     (0x0100): Sending result [4][domain.nl]
> >>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
> >>>>>>>[be_pam_handler_callback]
> >>>>>>>     (0x0100): Sent result [4][domain.nl]
> >>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
> >>>>>>>     (0x0100): child [19510] finished successfully.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>Both CentOS and Fedora are fully up-to-date using only the base
> >>>>>>>>repos. Config of the clients is done with ipa-client-install.
> >>>>>>>>
> >>>>>>>
> >>>>>>>Could you attach log files with debug_level 9?
> >>>>>>>
> >>>>>>>LS
> >>>>>>>
> >>>>>>
> >>>>>>Sure. Just sssd_domain or do you need more?
> >>>>>>
> >>>>Are you using two different ipa servers?
> >>>>ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
> >>>>
> >>>>>>sssd_domain.nl.log, loglevel 9
> >>>>>>Fedora: http://pastebin.centos.org/8291/
> >>>>Constructed uri 'ldap://vm-ipa.domain.nl'
> >>>>
> >>>>>>CentOS: http://pastebin.centos.org/8296/
> >>>>Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
> >>>>
> >>>>>>
> >>>>>>  - Jitse
> >>>>>>
> >>>>>
> >>>>>The problem is also present in RHEL7b with
> >>>>>ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
> >>>>>
> >>>>>sssd_domain.nl.log, loglevel 9
> >>>>>RHEL7b: http://pastebin.centos.org/8301/
> >>>>Constructed uri 'ldap://vm-ipa.domain.nl'
> >>>>
> >>>>Could you also provide krb5_child.log and ldap_child.log from fedora machine?
> >>>>     (debug_level 9)
> >>>>
> >>>>LS
> >>>>
> >>>
> >>>No, I'm using only one ipa server (vm-ipa). I accidentally
> >>>copy-pasted without changing the domain name ;)
> >>>
> >>>>Any chance you could use the migrate-ds script to migrate users? I'm
> >>>>not 100% sure if your own upgrade method does the same thing..
> >>>I don't think so, our old LDAP schema is a mess...
> >>>
> >>>krb5_child.log: http://pastebin.centos.org/8306/
> >>
> >>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>    1394465217.407384: Getting initial credentials for jitse at DOMAIN.NL
> >>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>    1394465217.407699: Sending request (173 bytes) to DOMAIN.NL
> >>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>    1394465217.408202: Sending initial UDP request to dgram 10.14.3.15:88
> >>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>    1394465217.425034: Received answer from dgram 10.14.3.15:88
> >>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>    1394465217.425171: Response was from master KDC
> >>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>    1394465217.425241: Received error from KDC: -1765328361/Password has expired
> >>[get_and_save_tgt] (0x0020): 918: [-1765328361][Password has expired]
> >>[tgt_req_child] (0x1000): Password was expired
> >>
> >>It looks like password is expired for user jitse.
> >>
> >My hands were faster than my mind.
> >
> >I wanted to wrote:
> >It looks like password is expired for user jitse.
> >It is really weird because it works on Centos.
> >Do you have a synchronized time on all machines with ipa server?
> >
> >LS
> 
> Yes, time is in sync across all machines. I think the most
> interesting lines in the log are these:
> 
> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
> [sss_child_krb5_trace_cb] (0x4000): [24671] 1394465217.441823:
> Processing preauth types: 136, 19, 2, 133
> 
> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
> [map_krb5_error] (0x0020): 979: [-1765328234][Program lacks support
> for encryption type]
> 
> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
> [pack_response_packet] (0x2000): response packet size: [4]
> 
> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
> [k5c_send_data] (0x4000): Response sent.
> 
> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] [main]
> (0x0400): krb5_child completed successfully
> 
> This is where krb5_child on fedora just stops working while
> krb5_child on CentOS does this: http://pastebin.centos.org/8316/
> 

Can you send the krb5_child.log file with the success from CentOS as
well? Looks like we might handle some error codes differently after
introducing the sssd_errors code.

bye,
Sumit

> 
>  - Jitse
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users



From dpal at redhat.com  Mon Mar 10 18:50:27 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 10 Mar 2014 14:50:27 -0400
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <1394461922.2147.6.camel@localhost.localdomain>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>
	<53191ED7.1000502@redhat.com>
	<CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>
	<531A4A77.6010201@redhat.com>
	<CAN0oX1ZwbPf6n_KkLOnbURg0Qic6y9QP6H7OJ8LRBH5BXfAAag@mail.gmail.com>
	<531BAD8E.5020502@redhat.com>
	<1394461922.2147.6.camel@localhost.localdomain>
Message-ID: <531E0973.3090208@redhat.com>

On 03/10/2014 10:32 AM, Nathaniel McCallum wrote:
> On Sat, 2014-03-08 at 18:53 -0500, Dmitri Pal wrote:
>> On 03/08/2014 04:36 PM, Trey Dockendorf wrote:
>>> I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no NTP).
>>>
>>> IPA is 3.3.3-5.el7
>>> SSSD is 1.11.2-1.el7
>>> krb5 is 1.11.3-31.el7
>>>
>>> Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted
>>> the CLI commands under "Feature Management", with no luck.
>>>
>>> For example:
>>>
>>> ---
>>> # ipa config-mod --user-auth-type=['password', 'otp', 'radius']
>>> Usage: ipa [global-options] config-mod [options]
>>>
>>> ipa: error: no such option: --user-auth-type
>>> ---
>>>
>>> The ipa subcommands "radiusproxy-*" do not exist either.
>>>
>>> What version of IPA should I use to test this proof of concept?  The
>>> docs mention needing Kerberos no earlier than 1.12, which isn't
>>> available in EL7.
>>>
>>> My understanding of Kerberos is not great, but is FreeIPA simply not
>>> designed for external Kerberos (like the use of an external CA)?  Is
>>> there possibly a way to utilize FreeIPA without Kerberos, and just
>>> manage 389DS while still using the web interface (hard to find good
>>> Identity Management Web UI) and CLI tools?  I'd still like to get this
>>> working in FreeIPA, but am working on upgrading our HPC cluster to EL6
>>> (or EL7) and moving to FreeIPA would be a great improvement over 389DS
>>> in terms of manageability.
>>>
>> Nathaniel, do we have a build of the latest bits for RHEL7 somewhere?
>> Can you help with this POC please?
> None of those commands will be present in EL 7.0 and we don't currently
> have EL 7.0 builds of FreeIPA 4.0 master to my knowledge.

I thought we have something that builds latest bits for RHEL. If not is 
it hard to produce one?

>
> It would be possible to do this via manual manipulation of the LDAP
> entries. You'd need to create an ipatokenRadiusConfiguration object and
> then add the ipatokenRadiusProxyUser class (ipatokenRadiusConfigLink
> attribute) to each user you'd like to proxy.
>
> However, I don't think manual manipulation of LDAP like this is a
> supported operation. I would also imagine that your University may look
> down on an intentional man-in-the-middle password proxy.
>
> Nathaniel
>
Nathaniel. All the security disclaimers have been mentioned earlier in 
the thread.
While I agree with you from security POV proxy is a solution that 
already in place so it is not worse than now.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From simo at redhat.com  Mon Mar 10 18:54:35 2014
From: simo at redhat.com (Simo Sorce)
Date: Mon, 10 Mar 2014 14:54:35 -0400
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6929BF@001FSN2MPN1-045.001f.mgd2.msft.net>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>	<20140307155921.GI19071@hendrix.redhat.com>
	<5319EE1D.1010207@redhat.com>
	<20140307162419.GL19071@hendrix.redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6926F2@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394231525.14651.146.camel@willson.li.ssimo.org>
	<82E7C9A01FD0764CACDD35D10F5DFB6E69284E@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394311954.14651.195.camel@willson.li.ssimo.org>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6929BF@001FSN2MPN1-045.001f.mgd2.msft.net>
Message-ID: <1394477675.32465.25.camel@willson.li.ssimo.org>

On Sun, 2014-03-09 at 01:28 +0000, Nordgren, Bryce L -FS wrote:
> IPA supplements (or hopefully will supplement) AD in my environment. I
> need to worry about colliding with UIDs in a directory I don't
> control. IPA can't solve this problem for me. Neither can my current
> LDAP solution. But machines which could generate their own
> mappings...many headaches would go away.

In the default case IPA, will automatically allocate a non conflicting
range to AD SIDs and pa SIDs to UIDs automatically. however if you want
to use posix Ids stored in AD then yes, you will have to take care
manually to avoid conflicts.

> The renaming thing you brought up (within a non-UID/SID-sharing
> environment) sounds like it could be a good thesis topic. "Going
> forward" probably means starting to use NFSv4, which also warns
> against renaming because it doesn?t use UID/SIDs. It sounds like a
> necessary and present issue to address.

Well, once you make the fully qualified name (user at realm) your unique
identifier, renaming becomes pretty much impossibile, except at great
pains (like having a 'synchronized' service that maps new name to old
name and banning reuse of the old unique name for any future user).

Efficiently transmitting group information also becomes a challenge, but
we may decide not to care about performance :)

> Assembling a functional realm containing only platform-independent
> principals (could include groups, not GIDs), by extending the NFS
> idmapper could be another. (Or at least ensuring that the POSIX
> mappings and NFS mappings are the same...) Try the same thing on
> Windows and see what the showstoppers are. Success may simplify
> integration of Windows into IPA managed domains if you didn't have to
> emulate an AD instance so completely. Home users everywhere may love
> being able to make all their machines have the same password via a KDC
> (or IPA?) running on their wireless router.

Unfortunately that is not really in our hands, Microsoft tied windows
clients to AD, so only Microsoft can provide 'simpler' interfaces and
let the client remain fully functional.

> If you're tired of this topic, how about a thesis which makes Kerberos
> KDCs function more like IP routers, collaboratively and automatically
> maintaining the connectivity topology between Kerberos realms?

Well there are some proposal, but a thesis on this that summarize the
problem and possible solution seem a really interesting topic for a
bright student. 

>  Clearly, its not the same: cross-realm connectivity (I will NOT use
> the word "trust") is inherently unidirectional. Also, the mapping from
> realm->dns and specific fqdns for the KDCs will need to be
> communicated.

Indeed we had to implement MS interfaces in IPA to communicate topology
back and forth. Unfortunately 'trust' is a word you have to use any time
you want to communicate information, either you trust the source or have
a way to verify it is truthful ... by trusting something else :-)

>  The KDC could potentially communicate this topology to interested
> clients, but why on earth would the clients want to know? IP routers
> made UUCP bang paths obsolete, something should do the same for
> Kerberos capaths.

Actually the solution to avoid capaths on clients is already planned,
and it is to stop having clients try to discover topology on their own
at all. Clients should always communicate with their KDC, and the KDC
will issue referrals as appropriate. Once you do this capaths can be
dismantled for the clients, the KDC will care for handling topology
information.
One small problem remains: how do I find the KDC if the realm name of
the realm does not match the DNS domain name ? That is something that
can be, perhaps resolved with some additional PA-DATA on the referrals
if there is no other way.


But let me say I am not at all against having thesis' that explore some
of these theoretical questions, however one need to understand that the
deliverable may end up being something that cannot be implemented or
that it would require a long time to do so. As long as that is clear
everything is game.

Simo.

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



From dpal at redhat.com  Mon Mar 10 18:55:39 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 10 Mar 2014 14:55:39 -0400
Subject: [Freeipa-users] install IPA replica multi-hosts (ipa packages
 version 3.3.3-18)
In-Reply-To: <1394464565.531dd73570eac@imp.free.fr>
References: <1394198167.5319c6977ca6d@imp.free.fr>
	<5319DB9A.2090809@redhat.com>
	<1394206154.5319e5ca7b4be@imp.free.fr>
	<5319EC61.6020105@redhat.com> <531D73AB.3010201@redhat.com>
	<1394464565.531dd73570eac@imp.free.fr>
Message-ID: <531E0AAB.6040800@redhat.com>

On 03/10/2014 11:16 AM, artjazz at free.fr wrote:
> Selon Petr Spacek<pspacek at redhat.com>:
>
>> On 7.3.2014 16:57, Dmitri Pal wrote:
>>> On 03/07/2014 10:29 AM, artjazz at free.fr wrote:
>>>> Selon Petr Spacek<pspacek at redhat.com>:
>>>>
>>>>>>   On 7.3.2014 14:16,artjazz at free.fr  wrote:
>>>>>>>   >   I want to install ipa server with a replica. The replica has 2
>> NICs
>>>>>> : the
>>>>>>   ipa
>>>>>>>   >   server is connected on the first interface and all the clients are
>>>>>>   connected on
>>>>>>>   >   the second interface. The two networks are completely separated, 2
>>>>>> subnets
>>>>>>   and
>>>>>>>   >   not routed.
>>>>>>   I'm curious - what is the reasoning behind this?:-)
>>>> The goal is to separate the administration flux and the userland flux.
>>>>
>>> The problem is that it is not that clean.
>>> One server can connect to another on different ports and using different
>>> protocols for different purposes. And client can actually be a proxy that
>> does
>>> some admin tasks via LDAP or executes remote administrative commands.
>>>
>>> I think may be it is better to explore FW rules.
>>> For example create a FW rule that would allow only Kerberos and LDAP
>>> connections from a set of hosts that would be clients. Hm but that again
>> would
>>> prevent you from enrolling new systems since the ipa-client-install
>> connects
>>> to IPA via admin interface during the enrollment stage.
>>>
>>> May be there is some magic that can be done using DNS zones but I am not
>> sure...
>>
>> Let me summarize this thread to:
>> Sorry, this is not supported.
> Thanks for your answer; It's clear for me now, I understand why my different
> tests didn't work.
>
> Just for my information because it's a little bit confusing when I read in the
> FreeIPA_Guide (Fedora18)  the following sentence:
> 19.5. Setting DNS Entries for Multi-Homed Servers
> Some server machines may support multiple network interface cards (NICs).
> Multi-homed machines typically have multiple IPs, all assigned to the same
> hostname. This works fine in FreeIPA most of the time because it listens on all
> available interfaces, except localhost. For a server to be available through any
> NIC, edit the DNS zone file and add entries for each IP address. For example:
> ipaserver  IN A  192.168.1.100
> ipaserver  IN A  192.168.1.101
> ipaserver  IN A  192.168.1.102
>
> What is the architecture of the Multi-Homed Servers in this case ?

What do you mean "architecture" in this context?
Are you asking "what is the reason to have this host be multihomed"?
The main reason is because this is how for example EC2 (and similar) 
works. One machine will have internal NIC seen by the systems inside EC2 
and another seen by systems outside EC2.
To be able to work with clients inside and outside the cloud both NICs 
needs to be listed.

>
>> It becomes extremely complex very quickly and we don't have manpower to
>> maintain support for this kind of scenarios.
> I understand well.
>
>> Ideas and patches are welcome! :-)
> I can try to think about it.
> Best Regards.
>
>> --
>> Petr^2 Spacek
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/





From jitseklomp at gmail.com  Mon Mar 10 18:56:07 2014
From: jitseklomp at gmail.com (Jitse Klomp)
Date: Mon, 10 Mar 2014 19:56:07 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <20140310175733.GN2763@localhost.localdomain>
References: <531DB65D.5050301@gmail.com>
	<20140310133547.GD21499@mail.corp.redhat.com>
	<531DC550.1070903@gmail.com> <531DC9F0.4020405@gmail.com>
	<20140310151023.GE21499@mail.corp.redhat.com>
	<531DDBC3.4060700@gmail.com>
	<20140310155809.GG21499@mail.corp.redhat.com>
	<20140310160301.GH21499@mail.corp.redhat.com>
	<531DE71F.5000907@gmail.com>
	<20140310175733.GN2763@localhost.localdomain>
Message-ID: <531E0AC7.2090209@gmail.com>

On 10-03-14 18:57, Sumit Bose wrote:
> On Mon, Mar 10, 2014 at 05:23:59PM +0100, Jitse Klomp wrote:
>> On 10-03-14 17:03, Lukas Slebodnik wrote:
>>> On (10/03/14 16:58), Lukas Slebodnik wrote:
>>>> On (10/03/14 16:35), Jitse Klomp wrote:
>>>>> On 10-03-14 16:10, Lukas Slebodnik wrote:
>>>>>> On (10/03/14 15:19), Jitse Klomp wrote:
>>>>>>> On 10-03-14 14:59, Jitse Klomp wrote:
>>>>>>>> On 10-03-14 14:35, Lukas Slebodnik wrote:
>>>>>>>>> On (10/03/14 13:55), Jitse Klomp wrote:
>>>>>>>>>> Hello all,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
>>>>>>>>>> migrate-ds I used some custom scripts to import all of our users (~250)
>>>>>>>>>> and groups (~85) with IPA commands (ipa user-add etc.). To move
>>>>>>>>>> passwords I configured the ipa-server to run in migration mode and did
>>>>>>>>>> an ldapmodify like this:
>>>>>>>>>>
>>>>>>>>>>     dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>>>>>>>>>     changetype: modify
>>>>>>>>>>     replace: userPassword
>>>>>>>>>>     userPassword: {SHA}hash
>>>>>>>>>>
>>>>>>>>>> Logging in to a machine running CentOS and ipa-client for the first time
>>>>>>>>>> works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
>>>>>>>>>> works. However, logging in to Fedora 20 for the first time throws a
>>>>>>>>>> 'permission denied'. Logging in to Fedora works after logging in to
>>>>>>>>>> CentOS or the IPA migration web ui.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> sssd_domain.nl.log, loglevel 6
>>>>>>>>>> Fedora log: http://pastebin.centos.org/8281/
>>>>>>>>>> CentOS log: http://pastebin.centos.org/8286/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Additional details:
>>>>>>>>>> IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>>>>>>>>>> Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>>>>>>>>>> Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
>>>>>>>>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
>>>>>>>>>      (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
>>>>>>>>>      (0x0400): All data has been sent!
>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
>>>>>>>>>      (0x0400): EOF received, client finished
>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>> [be_pam_handler_callback]
>>>>>>>>>      (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>>>>>>>>>                                     ^^^
>>>>>>>>>                                    It means  PAM_SYSTEM_ERR /* System
>>>>>>>>> error */
>>>>>>>>>
>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>> [be_pam_handler_callback]
>>>>>>>>>      (0x0100): Sending result [4][domain.nl]
>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>> [be_pam_handler_callback]
>>>>>>>>>      (0x0100): Sent result [4][domain.nl]
>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
>>>>>>>>>      (0x0100): child [19510] finished successfully.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Both CentOS and Fedora are fully up-to-date using only the base
>>>>>>>>>> repos. Config of the clients is done with ipa-client-install.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Could you attach log files with debug_level 9?
>>>>>>>>>
>>>>>>>>> LS
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sure. Just sssd_domain or do you need more?
>>>>>>>>
>>>>>> Are you using two different ipa servers?
>>>>>> ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
>>>>>>
>>>>>>>> sssd_domain.nl.log, loglevel 9
>>>>>>>> Fedora: http://pastebin.centos.org/8291/
>>>>>> Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>
>>>>>>>> CentOS: http://pastebin.centos.org/8296/
>>>>>> Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
>>>>>>
>>>>>>>>
>>>>>>>>   - Jitse
>>>>>>>>
>>>>>>>
>>>>>>> The problem is also present in RHEL7b with
>>>>>>> ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
>>>>>>>
>>>>>>> sssd_domain.nl.log, loglevel 9
>>>>>>> RHEL7b: http://pastebin.centos.org/8301/
>>>>>> Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>
>>>>>> Could you also provide krb5_child.log and ldap_child.log from fedora machine?
>>>>>>      (debug_level 9)
>>>>>>
>>>>>> LS
>>>>>>
>>>>>
>>>>> No, I'm using only one ipa server (vm-ipa). I accidentally
>>>>> copy-pasted without changing the domain name ;)
>>>>>
>>>>>> Any chance you could use the migrate-ds script to migrate users? I'm
>>>>>> not 100% sure if your own upgrade method does the same thing..
>>>>> I don't think so, our old LDAP schema is a mess...
>>>>>
>>>>> krb5_child.log: http://pastebin.centos.org/8306/
>>>>
>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>     1394465217.407384: Getting initial credentials for jitse at DOMAIN.NL
>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>     1394465217.407699: Sending request (173 bytes) to DOMAIN.NL
>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>     1394465217.408202: Sending initial UDP request to dgram 10.14.3.15:88
>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>     1394465217.425034: Received answer from dgram 10.14.3.15:88
>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>     1394465217.425171: Response was from master KDC
>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>     1394465217.425241: Received error from KDC: -1765328361/Password has expired
>>>> [get_and_save_tgt] (0x0020): 918: [-1765328361][Password has expired]
>>>> [tgt_req_child] (0x1000): Password was expired
>>>>
>>>> It looks like password is expired for user jitse.
>>>>
>>> My hands were faster than my mind.
>>>
>>> I wanted to wrote:
>>> It looks like password is expired for user jitse.
>>> It is really weird because it works on Centos.
>>> Do you have a synchronized time on all machines with ipa server?
>>>
>>> LS
>>
>> Yes, time is in sync across all machines. I think the most
>> interesting lines in the log are these:
>>
>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>> [sss_child_krb5_trace_cb] (0x4000): [24671] 1394465217.441823:
>> Processing preauth types: 136, 19, 2, 133
>>
>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>> [map_krb5_error] (0x0020): 979: [-1765328234][Program lacks support
>> for encryption type]
>>
>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>> [pack_response_packet] (0x2000): response packet size: [4]
>>
>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>> [k5c_send_data] (0x4000): Response sent.
>>
>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] [main]
>> (0x0400): krb5_child completed successfully
>>
>> This is where krb5_child on fedora just stops working while
>> krb5_child on CentOS does this: http://pastebin.centos.org/8316/
>>
>
> Can you send the krb5_child.log file with the success from CentOS as
> well? Looks like we might handle some error codes differently after
> introducing the sssd_errors code.
>
> bye,
> Sumit
>
>>
>>   - Jitse

That last pastebin (http://pastebin.centos.org/8316/) was krb5_child.log 
from a succesful first-time login on centos.

 > I'd be curious what the krbPasswordExpiration is for this user.
See http://pastebin.centos.org/8321/ for a password migration and output 
of ldapsearch.

Output of ldapsearch *after* logging in to CentOS for the first time:
     krbPasswordExpiration: 20140310183603Z
     krbLastPwdChange: 20140310183603Z
     krbExtraData:: AAITBh5Tcm9vdC9hZG1pbkBBLUVTS1dBRFJBQVQuTkwA
     krbLastFailedAuth: 20140310185101Z
     krbLoginFailedCount: 1

  - Jitse



From npmccallum at redhat.com  Mon Mar 10 19:13:06 2014
From: npmccallum at redhat.com (Nathaniel McCallum)
Date: Mon, 10 Mar 2014 15:13:06 -0400
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <531E0973.3090208@redhat.com>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>
	<53191ED7.1000502@redhat.com>
	<CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>
	<531A4A77.6010201@redhat.com>
	<CAN0oX1ZwbPf6n_KkLOnbURg0Qic6y9QP6H7OJ8LRBH5BXfAAag@mail.gmail.com>
	<531BAD8E.5020502@redhat.com>
	<1394461922.2147.6.camel@localhost.localdomain>
	<531E0973.3090208@redhat.com>
Message-ID: <1394478786.2147.14.camel@localhost.localdomain>

On Mon, 2014-03-10 at 14:50 -0400, Dmitri Pal wrote:
> On 03/10/2014 10:32 AM, Nathaniel McCallum wrote:
> > On Sat, 2014-03-08 at 18:53 -0500, Dmitri Pal wrote:
> >> On 03/08/2014 04:36 PM, Trey Dockendorf wrote:
> >>> I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no NTP).
> >>>
> >>> IPA is 3.3.3-5.el7
> >>> SSSD is 1.11.2-1.el7
> >>> krb5 is 1.11.3-31.el7
> >>>
> >>> Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted
> >>> the CLI commands under "Feature Management", with no luck.
> >>>
> >>> For example:
> >>>
> >>> ---
> >>> # ipa config-mod --user-auth-type=['password', 'otp', 'radius']
> >>> Usage: ipa [global-options] config-mod [options]
> >>>
> >>> ipa: error: no such option: --user-auth-type
> >>> ---
> >>>
> >>> The ipa subcommands "radiusproxy-*" do not exist either.
> >>>
> >>> What version of IPA should I use to test this proof of concept?  The
> >>> docs mention needing Kerberos no earlier than 1.12, which isn't
> >>> available in EL7.
> >>>
> >>> My understanding of Kerberos is not great, but is FreeIPA simply not
> >>> designed for external Kerberos (like the use of an external CA)?  Is
> >>> there possibly a way to utilize FreeIPA without Kerberos, and just
> >>> manage 389DS while still using the web interface (hard to find good
> >>> Identity Management Web UI) and CLI tools?  I'd still like to get this
> >>> working in FreeIPA, but am working on upgrading our HPC cluster to EL6
> >>> (or EL7) and moving to FreeIPA would be a great improvement over 389DS
> >>> in terms of manageability.
> >>>
> >> Nathaniel, do we have a build of the latest bits for RHEL7 somewhere?
> >> Can you help with this POC please?
> > None of those commands will be present in EL 7.0 and we don't currently
> > have EL 7.0 builds of FreeIPA 4.0 master to my knowledge.
> 
> I thought we have something that builds latest bits for RHEL. If not is 
> it hard to produce one?

http://koji.fedoraproject.org/koji/packageinfo?packageID=11554

Koji doesn't currently list an EPEL build of IPA, most likely because
such a package would disturb the EL packages. We could create a Copr
build for EL6, but I don't know how many dependencies it would drag in.
If the dependencies are minimal, the job would be fairly easy. I may
take a stab at this later this week.

> > It would be possible to do this via manual manipulation of the LDAP
> > entries. You'd need to create an ipatokenRadiusConfiguration object and
> > then add the ipatokenRadiusProxyUser class (ipatokenRadiusConfigLink
> > attribute) to each user you'd like to proxy.
> >
> > However, I don't think manual manipulation of LDAP like this is a
> > supported operation. I would also imagine that your University may look
> > down on an intentional man-in-the-middle password proxy.
> >
> > Nathaniel
> >
> Nathaniel. All the security disclaimers have been mentioned earlier in 
> the thread.
> While I agree with you from security POV proxy is a solution that 
> already in place so it is not worse than now.

Yup, I just wanted to make sure I covered the disclaimers in full in the
same email detailing how to enable it. :)

Nathaniel



From rcritten at redhat.com  Mon Mar 10 19:14:37 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 10 Mar 2014 15:14:37 -0400
Subject: [Freeipa-users] Migration mode
In-Reply-To: <531E0AC7.2090209@gmail.com>
References: <531DB65D.5050301@gmail.com>	<20140310133547.GD21499@mail.corp.redhat.com>	<531DC550.1070903@gmail.com>
	<531DC9F0.4020405@gmail.com>	<20140310151023.GE21499@mail.corp.redhat.com>	<531DDBC3.4060700@gmail.com>	<20140310155809.GG21499@mail.corp.redhat.com>	<20140310160301.GH21499@mail.corp.redhat.com>	<531DE71F.5000907@gmail.com>	<20140310175733.GN2763@localhost.localdomain>
	<531E0AC7.2090209@gmail.com>
Message-ID: <531E0F1D.6080402@redhat.com>

Jitse Klomp wrote:
> On 10-03-14 18:57, Sumit Bose wrote:
>> On Mon, Mar 10, 2014 at 05:23:59PM +0100, Jitse Klomp wrote:
>>> On 10-03-14 17:03, Lukas Slebodnik wrote:
>>>> On (10/03/14 16:58), Lukas Slebodnik wrote:
>>>>> On (10/03/14 16:35), Jitse Klomp wrote:
>>>>>> On 10-03-14 16:10, Lukas Slebodnik wrote:
>>>>>>> On (10/03/14 15:19), Jitse Klomp wrote:
>>>>>>>> On 10-03-14 14:59, Jitse Klomp wrote:
>>>>>>>>> On 10-03-14 14:35, Lukas Slebodnik wrote:
>>>>>>>>>> On (10/03/14 13:55), Jitse Klomp wrote:
>>>>>>>>>>> Hello all,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm migrating our OpenLDAP-based IdM-system to IPA. Instead
>>>>>>>>>>> of using
>>>>>>>>>>> migrate-ds I used some custom scripts to import all of our
>>>>>>>>>>> users (~250)
>>>>>>>>>>> and groups (~85) with IPA commands (ipa user-add etc.). To move
>>>>>>>>>>> passwords I configured the ipa-server to run in migration
>>>>>>>>>>> mode and did
>>>>>>>>>>> an ldapmodify like this:
>>>>>>>>>>>
>>>>>>>>>>>     dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>>>>>>>>>>     changetype: modify
>>>>>>>>>>>     replace: userPassword
>>>>>>>>>>>     userPassword: {SHA}hash
>>>>>>>>>>>
>>>>>>>>>>> Logging in to a machine running CentOS and ipa-client for the
>>>>>>>>>>> first time
>>>>>>>>>>> works like a charm, a krbPrincipalKey is generated and
>>>>>>>>>>> Kerberos 'just'
>>>>>>>>>>> works. However, logging in to Fedora 20 for the first time
>>>>>>>>>>> throws a
>>>>>>>>>>> 'permission denied'. Logging in to Fedora works after logging
>>>>>>>>>>> in to
>>>>>>>>>>> CentOS or the IPA migration web ui.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> sssd_domain.nl.log, loglevel 6
>>>>>>>>>>> Fedora log: http://pastebin.centos.org/8281/
>>>>>>>>>>> CentOS log: http://pastebin.centos.org/8286/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Additional details:
>>>>>>>>>>> IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>>>>>>>>>>> Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>>>>>>>>>>> Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
>>>>>>>>>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]]
>>>>>>>>>> [ipa_resolve_callback]
>>>>>>>>>>      (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>>>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]]
>>>>>>>>>> [write_pipe_handler]
>>>>>>>>>>      (0x0400): All data has been sent!
>>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>> [read_pipe_handler]
>>>>>>>>>>      (0x0400): EOF received, client finished
>>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>> [be_pam_handler_callback]
>>>>>>>>>>      (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>>>>>>>>>>                                     ^^^
>>>>>>>>>>                                    It means  PAM_SYSTEM_ERR /*
>>>>>>>>>> System
>>>>>>>>>> error */
>>>>>>>>>>
>>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>> [be_pam_handler_callback]
>>>>>>>>>>      (0x0100): Sending result [4][domain.nl]
>>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>> [be_pam_handler_callback]
>>>>>>>>>>      (0x0100): Sent result [4][domain.nl]
>>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>> [child_sig_handler]
>>>>>>>>>>      (0x0100): child [19510] finished successfully.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Both CentOS and Fedora are fully up-to-date using only the base
>>>>>>>>>>> repos. Config of the clients is done with ipa-client-install.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Could you attach log files with debug_level 9?
>>>>>>>>>>
>>>>>>>>>> LS
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sure. Just sssd_domain or do you need more?
>>>>>>>>>
>>>>>>> Are you using two different ipa servers?
>>>>>>> ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
>>>>>>>
>>>>>>>>> sssd_domain.nl.log, loglevel 9
>>>>>>>>> Fedora: http://pastebin.centos.org/8291/
>>>>>>> Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>
>>>>>>>>> CentOS: http://pastebin.centos.org/8296/
>>>>>>> Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
>>>>>>>
>>>>>>>>>
>>>>>>>>>   - Jitse
>>>>>>>>>
>>>>>>>>
>>>>>>>> The problem is also present in RHEL7b with
>>>>>>>> ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
>>>>>>>>
>>>>>>>> sssd_domain.nl.log, loglevel 9
>>>>>>>> RHEL7b: http://pastebin.centos.org/8301/
>>>>>>> Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>
>>>>>>> Could you also provide krb5_child.log and ldap_child.log from
>>>>>>> fedora machine?
>>>>>>>      (debug_level 9)
>>>>>>>
>>>>>>> LS
>>>>>>>
>>>>>>
>>>>>> No, I'm using only one ipa server (vm-ipa). I accidentally
>>>>>> copy-pasted without changing the domain name ;)
>>>>>>
>>>>>>> Any chance you could use the migrate-ds script to migrate users? I'm
>>>>>>> not 100% sure if your own upgrade method does the same thing..
>>>>>> I don't think so, our old LDAP schema is a mess...
>>>>>>
>>>>>> krb5_child.log: http://pastebin.centos.org/8306/
>>>>>
>>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>     1394465217.407384: Getting initial credentials for jitse at DOMAIN.NL
>>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>     1394465217.407699: Sending request (173 bytes) to DOMAIN.NL
>>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>     1394465217.408202: Sending initial UDP request to dgram
>>>>> 10.14.3.15:88
>>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>     1394465217.425034: Received answer from dgram 10.14.3.15:88
>>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>     1394465217.425171: Response was from master KDC
>>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>     1394465217.425241: Received error from KDC:
>>>>> -1765328361/Password has expired
>>>>> [get_and_save_tgt] (0x0020): 918: [-1765328361][Password has expired]
>>>>> [tgt_req_child] (0x1000): Password was expired
>>>>>
>>>>> It looks like password is expired for user jitse.
>>>>>
>>>> My hands were faster than my mind.
>>>>
>>>> I wanted to wrote:
>>>> It looks like password is expired for user jitse.
>>>> It is really weird because it works on Centos.
>>>> Do you have a synchronized time on all machines with ipa server?
>>>>
>>>> LS
>>>
>>> Yes, time is in sync across all machines. I think the most
>>> interesting lines in the log are these:
>>>
>>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>> [sss_child_krb5_trace_cb] (0x4000): [24671] 1394465217.441823:
>>> Processing preauth types: 136, 19, 2, 133
>>>
>>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>> [map_krb5_error] (0x0020): 979: [-1765328234][Program lacks support
>>> for encryption type]
>>>
>>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>> [pack_response_packet] (0x2000): response packet size: [4]
>>>
>>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>> [k5c_send_data] (0x4000): Response sent.
>>>
>>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] [main]
>>> (0x0400): krb5_child completed successfully
>>>
>>> This is where krb5_child on fedora just stops working while
>>> krb5_child on CentOS does this: http://pastebin.centos.org/8316/
>>>
>>
>> Can you send the krb5_child.log file with the success from CentOS as
>> well? Looks like we might handle some error codes differently after
>> introducing the sssd_errors code.
>>
>> bye,
>> Sumit
>>
>>>
>>>   - Jitse
>
> That last pastebin (http://pastebin.centos.org/8316/) was krb5_child.log
> from a succesful first-time login on centos.
>
>  > I'd be curious what the krbPasswordExpiration is for this user.
> See http://pastebin.centos.org/8321/ for a password migration and output
> of ldapsearch.
>
> Output of ldapsearch *after* logging in to CentOS for the first time:
>      krbPasswordExpiration: 20140310183603Z
>      krbLastPwdChange: 20140310183603Z
>      krbExtraData:: AAITBh5Tcm9vdC9hZG1pbkBBLUVTS1dBRFJBQVQuTkwA
>      krbLastFailedAuth: 20140310185101Z
>      krbLoginFailedCount: 1

The password looks expired to me given that the expiration time is prior 
to the last failed login.

rob



From sbose at redhat.com  Mon Mar 10 19:34:16 2014
From: sbose at redhat.com (Sumit Bose)
Date: Mon, 10 Mar 2014 20:34:16 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <531E0AC7.2090209@gmail.com>
References: <20140310133547.GD21499@mail.corp.redhat.com>
	<531DC550.1070903@gmail.com> <531DC9F0.4020405@gmail.com>
	<20140310151023.GE21499@mail.corp.redhat.com>
	<531DDBC3.4060700@gmail.com>
	<20140310155809.GG21499@mail.corp.redhat.com>
	<20140310160301.GH21499@mail.corp.redhat.com>
	<531DE71F.5000907@gmail.com>
	<20140310175733.GN2763@localhost.localdomain>
	<531E0AC7.2090209@gmail.com>
Message-ID: <20140310193416.GO2763@localhost.localdomain>

On Mon, Mar 10, 2014 at 07:56:07PM +0100, Jitse Klomp wrote:
> On 10-03-14 18:57, Sumit Bose wrote:
> >On Mon, Mar 10, 2014 at 05:23:59PM +0100, Jitse Klomp wrote:
> >>On 10-03-14 17:03, Lukas Slebodnik wrote:
> >>>On (10/03/14 16:58), Lukas Slebodnik wrote:
> >>>>On (10/03/14 16:35), Jitse Klomp wrote:
> >>>>>On 10-03-14 16:10, Lukas Slebodnik wrote:
> >>>>>>On (10/03/14 15:19), Jitse Klomp wrote:
> >>>>>>>On 10-03-14 14:59, Jitse Klomp wrote:
> >>>>>>>>On 10-03-14 14:35, Lukas Slebodnik wrote:
> >>>>>>>>>On (10/03/14 13:55), Jitse Klomp wrote:
> >>>>>>>>>>Hello all,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
> >>>>>>>>>>migrate-ds I used some custom scripts to import all of our users (~250)
> >>>>>>>>>>and groups (~85) with IPA commands (ipa user-add etc.). To move
> >>>>>>>>>>passwords I configured the ipa-server to run in migration mode and did
> >>>>>>>>>>an ldapmodify like this:
> >>>>>>>>>>
> >>>>>>>>>>    dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
> >>>>>>>>>>    changetype: modify
> >>>>>>>>>>    replace: userPassword
> >>>>>>>>>>    userPassword: {SHA}hash
> >>>>>>>>>>
> >>>>>>>>>>Logging in to a machine running CentOS and ipa-client for the first time
> >>>>>>>>>>works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
> >>>>>>>>>>works. However, logging in to Fedora 20 for the first time throws a
> >>>>>>>>>>'permission denied'. Logging in to Fedora works after logging in to
> >>>>>>>>>>CentOS or the IPA migration web ui.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>sssd_domain.nl.log, loglevel 6
> >>>>>>>>>>Fedora log: http://pastebin.centos.org/8281/
> >>>>>>>>>>CentOS log: http://pastebin.centos.org/8286/
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>Additional details:
> >>>>>>>>>>IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
> >>>>>>>>>>Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
> >>>>>>>>>>Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
> >>>>>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
> >>>>>>>>>     (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
> >>>>>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
> >>>>>>>>>     (0x0400): All data has been sent!
> >>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
> >>>>>>>>>     (0x0400): EOF received, client finished
> >>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
> >>>>>>>>>[be_pam_handler_callback]
> >>>>>>>>>     (0x0100): Backend returned: (0, 4, <NULL>) [Success]
> >>>>>>>>>                                    ^^^
> >>>>>>>>>                                   It means  PAM_SYSTEM_ERR /* System
> >>>>>>>>>error */
> >>>>>>>>>
> >>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
> >>>>>>>>>[be_pam_handler_callback]
> >>>>>>>>>     (0x0100): Sending result [4][domain.nl]
> >>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
> >>>>>>>>>[be_pam_handler_callback]
> >>>>>>>>>     (0x0100): Sent result [4][domain.nl]
> >>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
> >>>>>>>>>     (0x0100): child [19510] finished successfully.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>Both CentOS and Fedora are fully up-to-date using only the base
> >>>>>>>>>>repos. Config of the clients is done with ipa-client-install.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>Could you attach log files with debug_level 9?
> >>>>>>>>>
> >>>>>>>>>LS
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>Sure. Just sssd_domain or do you need more?
> >>>>>>>>
> >>>>>>Are you using two different ipa servers?
> >>>>>>ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
> >>>>>>
> >>>>>>>>sssd_domain.nl.log, loglevel 9
> >>>>>>>>Fedora: http://pastebin.centos.org/8291/
> >>>>>>Constructed uri 'ldap://vm-ipa.domain.nl'
> >>>>>>
> >>>>>>>>CentOS: http://pastebin.centos.org/8296/
> >>>>>>Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
> >>>>>>
> >>>>>>>>
> >>>>>>>>  - Jitse
> >>>>>>>>
> >>>>>>>
> >>>>>>>The problem is also present in RHEL7b with
> >>>>>>>ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
> >>>>>>>
> >>>>>>>sssd_domain.nl.log, loglevel 9
> >>>>>>>RHEL7b: http://pastebin.centos.org/8301/
> >>>>>>Constructed uri 'ldap://vm-ipa.domain.nl'
> >>>>>>
> >>>>>>Could you also provide krb5_child.log and ldap_child.log from fedora machine?
> >>>>>>     (debug_level 9)
> >>>>>>
> >>>>>>LS
> >>>>>>
> >>>>>
> >>>>>No, I'm using only one ipa server (vm-ipa). I accidentally
> >>>>>copy-pasted without changing the domain name ;)
> >>>>>
> >>>>>>Any chance you could use the migrate-ds script to migrate users? I'm
> >>>>>>not 100% sure if your own upgrade method does the same thing..
> >>>>>I don't think so, our old LDAP schema is a mess...
> >>>>>
> >>>>>krb5_child.log: http://pastebin.centos.org/8306/
> >>>>
> >>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>>>    1394465217.407384: Getting initial credentials for jitse at DOMAIN.NL
> >>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>>>    1394465217.407699: Sending request (173 bytes) to DOMAIN.NL
> >>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>>>    1394465217.408202: Sending initial UDP request to dgram 10.14.3.15:88
> >>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>>>    1394465217.425034: Received answer from dgram 10.14.3.15:88
> >>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>>>    1394465217.425171: Response was from master KDC
> >>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>>>    1394465217.425241: Received error from KDC: -1765328361/Password has expired
> >>>>[get_and_save_tgt] (0x0020): 918: [-1765328361][Password has expired]
> >>>>[tgt_req_child] (0x1000): Password was expired
> >>>>
> >>>>It looks like password is expired for user jitse.
> >>>>
> >>>My hands were faster than my mind.
> >>>
> >>>I wanted to wrote:
> >>>It looks like password is expired for user jitse.
> >>>It is really weird because it works on Centos.
> >>>Do you have a synchronized time on all machines with ipa server?
> >>>
> >>>LS
> >>
> >>Yes, time is in sync across all machines. I think the most
> >>interesting lines in the log are these:
> >>
> >>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
> >>[sss_child_krb5_trace_cb] (0x4000): [24671] 1394465217.441823:
> >>Processing preauth types: 136, 19, 2, 133
> >>
> >>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
> >>[map_krb5_error] (0x0020): 979: [-1765328234][Program lacks support
> >>for encryption type]
> >>
> >>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
> >>[pack_response_packet] (0x2000): response packet size: [4]
> >>
> >>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
> >>[k5c_send_data] (0x4000): Response sent.
> >>
> >>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] [main]
> >>(0x0400): krb5_child completed successfully
> >>
> >>This is where krb5_child on fedora just stops working while
> >>krb5_child on CentOS does this: http://pastebin.centos.org/8316/
> >>
> >
> >Can you send the krb5_child.log file with the success from CentOS as
> >well? Looks like we might handle some error codes differently after
> >introducing the sssd_errors code.
> >
> >bye,
> >Sumit
> >
> >>
> >>  - Jitse
> 
> That last pastebin (http://pastebin.centos.org/8316/) was
> krb5_child.log from a succesful first-time login on centos.

Thanks. Can you try to set 'allow_weak_crypto = true' in the libdefaults
section of krb5.conf on F20 or RHEL7?

bye,
Sumit

> 
> > I'd be curious what the krbPasswordExpiration is for this user.
> See http://pastebin.centos.org/8321/ for a password migration and
> output of ldapsearch.
> 
> Output of ldapsearch *after* logging in to CentOS for the first time:
>     krbPasswordExpiration: 20140310183603Z
>     krbLastPwdChange: 20140310183603Z
>     krbExtraData:: AAITBh5Tcm9vdC9hZG1pbkBBLUVTS1dBRFJBQVQuTkwA
>     krbLastFailedAuth: 20140310185101Z
>     krbLoginFailedCount: 1
> 
>  - Jitse
> 
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users



From rstory at tislabs.com  Mon Mar 10 19:45:18 2014
From: rstory at tislabs.com (Robert Story)
Date: Mon, 10 Mar 2014 15:45:18 -0400
Subject: [Freeipa-users] install with external CA failed
In-Reply-To: <531DCFB1.9040506@redhat.com>
References: <20140305234258.1641247f@ispx.vb.futz.org>
	<531DCFB1.9040506@redhat.com>
Message-ID: <20140310154518.6cfdebdd@ispx.vb.futz.org>

On Mon, 10 Mar 2014 15:44:01 +0100 Jan wrote:
JC> On 6.3.2014 05:42, Robert Story wrote:
JC> > I'm trying to install on CentOS 6.5 (ipa-server-3.0.0-37.el6.x86_64)
JC> > and an external CA. I'm getting this error:
JC> > [snip]
JC> Can you please run certutil -V on the issuer certificate
JC> (CN=Certificate Authority,O=xxx)? That might give us a clue why it is
JC> invalid.

Unfortunately I've already scrapped that install and just went with the
internal self-signed CA. So far, the only annoyance is that the webserver
also presents a self-signed cert for the UI.  Is it safe to replace just
the web cert with a cert signed by my local CA? Or might that break
something?


Robert

--
Senior Software Engineer @ Parsons
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140310/2e406b3d/attachment.sig>

From simo at redhat.com  Mon Mar 10 20:07:54 2014
From: simo at redhat.com (Simo Sorce)
Date: Mon, 10 Mar 2014 16:07:54 -0400
Subject: [Freeipa-users] install with external CA failed
In-Reply-To: <20140310154518.6cfdebdd@ispx.vb.futz.org>
References: <20140305234258.1641247f@ispx.vb.futz.org>
	<531DCFB1.9040506@redhat.com>
	<20140310154518.6cfdebdd@ispx.vb.futz.org>
Message-ID: <1394482074.32465.26.camel@willson.li.ssimo.org>

On Mon, 2014-03-10 at 15:45 -0400, Robert Story wrote:
> On Mon, 10 Mar 2014 15:44:01 +0100 Jan wrote:
> JC> On 6.3.2014 05:42, Robert Story wrote:
> JC> > I'm trying to install on CentOS 6.5 (ipa-server-3.0.0-37.el6.x86_64)
> JC> > and an external CA. I'm getting this error:
> JC> > [snip]
> JC> Can you please run certutil -V on the issuer certificate
> JC> (CN=Certificate Authority,O=xxx)? That might give us a clue why it is
> JC> invalid.
> 
> Unfortunately I've already scrapped that install and just went with the
> internal self-signed CA. So far, the only annoyance is that the webserver
> also presents a self-signed cert for the UI.  Is it safe to replace just
> the web cert with a cert signed by my local CA? Or might that break
> something?

Import the CA cert in your browser.

Simo.

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



From jitseklomp at gmail.com  Mon Mar 10 20:10:01 2014
From: jitseklomp at gmail.com (Jitse Klomp)
Date: Mon, 10 Mar 2014 21:10:01 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <20140310193416.GO2763@localhost.localdomain>
References: <20140310133547.GD21499@mail.corp.redhat.com>	<531DC550.1070903@gmail.com>
	<531DC9F0.4020405@gmail.com>	<20140310151023.GE21499@mail.corp.redhat.com>	<531DDBC3.4060700@gmail.com>	<20140310155809.GG21499@mail.corp.redhat.com>	<20140310160301.GH21499@mail.corp.redhat.com>	<531DE71F.5000907@gmail.com>	<20140310175733.GN2763@localhost.localdomain>	<531E0AC7.2090209@gmail.com>
	<20140310193416.GO2763@localhost.localdomain>
Message-ID: <531E1C19.6020502@gmail.com>

On 10-03-14 20:34, Sumit Bose wrote:
> On Mon, Mar 10, 2014 at 07:56:07PM +0100, Jitse Klomp wrote:
>> On 10-03-14 18:57, Sumit Bose wrote:
>>> On Mon, Mar 10, 2014 at 05:23:59PM +0100, Jitse Klomp wrote:
>>>> On 10-03-14 17:03, Lukas Slebodnik wrote:
>>>>> On (10/03/14 16:58), Lukas Slebodnik wrote:
>>>>>> On (10/03/14 16:35), Jitse Klomp wrote:
>>>>>>> On 10-03-14 16:10, Lukas Slebodnik wrote:
>>>>>>>> On (10/03/14 15:19), Jitse Klomp wrote:
>>>>>>>>> On 10-03-14 14:59, Jitse Klomp wrote:
>>>>>>>>>> On 10-03-14 14:35, Lukas Slebodnik wrote:
>>>>>>>>>>> On (10/03/14 13:55), Jitse Klomp wrote:
>>>>>>>>>>>> Hello all,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
>>>>>>>>>>>> migrate-ds I used some custom scripts to import all of our users (~250)
>>>>>>>>>>>> and groups (~85) with IPA commands (ipa user-add etc.). To move
>>>>>>>>>>>> passwords I configured the ipa-server to run in migration mode and did
>>>>>>>>>>>> an ldapmodify like this:
>>>>>>>>>>>>
>>>>>>>>>>>>     dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>>>>>>>>>>>     changetype: modify
>>>>>>>>>>>>     replace: userPassword
>>>>>>>>>>>>     userPassword: {SHA}hash
>>>>>>>>>>>>
>>>>>>>>>>>> Logging in to a machine running CentOS and ipa-client for the first time
>>>>>>>>>>>> works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
>>>>>>>>>>>> works. However, logging in to Fedora 20 for the first time throws a
>>>>>>>>>>>> 'permission denied'. Logging in to Fedora works after logging in to
>>>>>>>>>>>> CentOS or the IPA migration web ui.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> sssd_domain.nl.log, loglevel 6
>>>>>>>>>>>> Fedora log: http://pastebin.centos.org/8281/
>>>>>>>>>>>> CentOS log: http://pastebin.centos.org/8286/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Additional details:
>>>>>>>>>>>> IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>>>>>>>>>>>> Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>>>>>>>>>>>> Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
>>>>>>>>>>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
>>>>>>>>>>>      (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>>>>> (Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
>>>>>>>>>>>      (0x0400): All data has been sent!
>>>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
>>>>>>>>>>>      (0x0400): EOF received, client finished
>>>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>> [be_pam_handler_callback]
>>>>>>>>>>>      (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>>>>>>>>>>>                                     ^^^
>>>>>>>>>>>                                    It means  PAM_SYSTEM_ERR /* System
>>>>>>>>>>> error */
>>>>>>>>>>>
>>>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>> [be_pam_handler_callback]
>>>>>>>>>>>      (0x0100): Sending result [4][domain.nl]
>>>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>> [be_pam_handler_callback]
>>>>>>>>>>>      (0x0100): Sent result [4][domain.nl]
>>>>>>>>>>> (Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
>>>>>>>>>>>      (0x0100): child [19510] finished successfully.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Both CentOS and Fedora are fully up-to-date using only the base
>>>>>>>>>>>> repos. Config of the clients is done with ipa-client-install.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Could you attach log files with debug_level 9?
>>>>>>>>>>>
>>>>>>>>>>> LS
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sure. Just sssd_domain or do you need more?
>>>>>>>>>>
>>>>>>>> Are you using two different ipa servers?
>>>>>>>> ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
>>>>>>>>
>>>>>>>>>> sssd_domain.nl.log, loglevel 9
>>>>>>>>>> Fedora: http://pastebin.centos.org/8291/
>>>>>>>> Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>>
>>>>>>>>>> CentOS: http://pastebin.centos.org/8296/
>>>>>>>> Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   - Jitse
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The problem is also present in RHEL7b with
>>>>>>>>> ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
>>>>>>>>>
>>>>>>>>> sssd_domain.nl.log, loglevel 9
>>>>>>>>> RHEL7b: http://pastebin.centos.org/8301/
>>>>>>>> Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>>
>>>>>>>> Could you also provide krb5_child.log and ldap_child.log from fedora machine?
>>>>>>>>      (debug_level 9)
>>>>>>>>
>>>>>>>> LS
>>>>>>>>
>>>>>>>
>>>>>>> No, I'm using only one ipa server (vm-ipa). I accidentally
>>>>>>> copy-pasted without changing the domain name ;)
>>>>>>>
>>>>>>>> Any chance you could use the migrate-ds script to migrate users? I'm
>>>>>>>> not 100% sure if your own upgrade method does the same thing..
>>>>>>> I don't think so, our old LDAP schema is a mess...
>>>>>>>
>>>>>>> krb5_child.log: http://pastebin.centos.org/8306/
>>>>>>
>>>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>     1394465217.407384: Getting initial credentials for jitse at DOMAIN.NL
>>>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>     1394465217.407699: Sending request (173 bytes) to DOMAIN.NL
>>>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>     1394465217.408202: Sending initial UDP request to dgram 10.14.3.15:88
>>>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>     1394465217.425034: Received answer from dgram 10.14.3.15:88
>>>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>     1394465217.425171: Response was from master KDC
>>>>>> [sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>     1394465217.425241: Received error from KDC: -1765328361/Password has expired
>>>>>> [get_and_save_tgt] (0x0020): 918: [-1765328361][Password has expired]
>>>>>> [tgt_req_child] (0x1000): Password was expired
>>>>>>
>>>>>> It looks like password is expired for user jitse.
>>>>>>
>>>>> My hands were faster than my mind.
>>>>>
>>>>> I wanted to wrote:
>>>>> It looks like password is expired for user jitse.
>>>>> It is really weird because it works on Centos.
>>>>> Do you have a synchronized time on all machines with ipa server?
>>>>>
>>>>> LS
>>>>
>>>> Yes, time is in sync across all machines. I think the most
>>>> interesting lines in the log are these:
>>>>
>>>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>>> [sss_child_krb5_trace_cb] (0x4000): [24671] 1394465217.441823:
>>>> Processing preauth types: 136, 19, 2, 133
>>>>
>>>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>>> [map_krb5_error] (0x0020): 979: [-1765328234][Program lacks support
>>>> for encryption type]
>>>>
>>>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>>> [pack_response_packet] (0x2000): response packet size: [4]
>>>>
>>>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>>> [k5c_send_data] (0x4000): Response sent.
>>>>
>>>> (Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] [main]
>>>> (0x0400): krb5_child completed successfully
>>>>
>>>> This is where krb5_child on fedora just stops working while
>>>> krb5_child on CentOS does this: http://pastebin.centos.org/8316/
>>>>
>>>
>>> Can you send the krb5_child.log file with the success from CentOS as
>>> well? Looks like we might handle some error codes differently after
>>> introducing the sssd_errors code.
>>>
>>> bye,
>>> Sumit
>>>
>>>>
>>>>   - Jitse
>>
>> That last pastebin (http://pastebin.centos.org/8316/) was
>> krb5_child.log from a succesful first-time login on centos.
>
> Thanks. Can you try to set 'allow_weak_crypto = true' in the libdefaults
> section of krb5.conf on F20 or RHEL7?
>
> bye,
> Sumit
>
>>
>>> I'd be curious what the krbPasswordExpiration is for this user.
>> See http://pastebin.centos.org/8321/ for a password migration and
>> output of ldapsearch.
>>
>> Output of ldapsearch *after* logging in to CentOS for the first time:
>>      krbPasswordExpiration: 20140310183603Z
>>      krbLastPwdChange: 20140310183603Z
>>      krbExtraData:: AAITBh5Tcm9vdC9hZG1pbkBBLUVTS1dBRFJBQVQuTkwA
>>      krbLastFailedAuth: 20140310185101Z
>>      krbLoginFailedCount: 1
>>
>>   - Jitse

Yes, here you go: http://pastebin.centos.org/8331/

It doesn't seem to be a lot different from the old one...

  - Jitse



From lslebodn at redhat.com  Mon Mar 10 20:47:13 2014
From: lslebodn at redhat.com (Lukas Slebodnik)
Date: Mon, 10 Mar 2014 21:47:13 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <531E0F1D.6080402@redhat.com>
References: <531DC550.1070903@gmail.com> <531DC9F0.4020405@gmail.com>
	<20140310151023.GE21499@mail.corp.redhat.com>
	<531DDBC3.4060700@gmail.com>
	<20140310155809.GG21499@mail.corp.redhat.com>
	<20140310160301.GH21499@mail.corp.redhat.com>
	<531DE71F.5000907@gmail.com>
	<20140310175733.GN2763@localhost.localdomain>
	<531E0AC7.2090209@gmail.com> <531E0F1D.6080402@redhat.com>
Message-ID: <20140310204712.GA25777@mail.corp.redhat.com>

On (10/03/14 15:14), Rob Crittenden wrote:
>Jitse Klomp wrote:
>>On 10-03-14 18:57, Sumit Bose wrote:
>>>On Mon, Mar 10, 2014 at 05:23:59PM +0100, Jitse Klomp wrote:
>>>>On 10-03-14 17:03, Lukas Slebodnik wrote:
>>>>>On (10/03/14 16:58), Lukas Slebodnik wrote:
>>>>>>On (10/03/14 16:35), Jitse Klomp wrote:
>>>>>>>On 10-03-14 16:10, Lukas Slebodnik wrote:
>>>>>>>>On (10/03/14 15:19), Jitse Klomp wrote:
>>>>>>>>>On 10-03-14 14:59, Jitse Klomp wrote:
>>>>>>>>>>On 10-03-14 14:35, Lukas Slebodnik wrote:
>>>>>>>>>>>On (10/03/14 13:55), Jitse Klomp wrote:
>>>>>>>>>>>>Hello all,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>I'm migrating our OpenLDAP-based IdM-system to IPA. Instead
>>>>>>>>>>>>of using
>>>>>>>>>>>>migrate-ds I used some custom scripts to import all of our
>>>>>>>>>>>>users (~250)
>>>>>>>>>>>>and groups (~85) with IPA commands (ipa user-add etc.). To move
>>>>>>>>>>>>passwords I configured the ipa-server to run in migration
>>>>>>>>>>>>mode and did
>>>>>>>>>>>>an ldapmodify like this:
>>>>>>>>>>>>
>>>>>>>>>>>>    dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>>>>>>>>>>>    changetype: modify
>>>>>>>>>>>>    replace: userPassword
>>>>>>>>>>>>    userPassword: {SHA}hash
>>>>>>>>>>>>
>>>>>>>>>>>>Logging in to a machine running CentOS and ipa-client for the
>>>>>>>>>>>>first time
>>>>>>>>>>>>works like a charm, a krbPrincipalKey is generated and
>>>>>>>>>>>>Kerberos 'just'
>>>>>>>>>>>>works. However, logging in to Fedora 20 for the first time
>>>>>>>>>>>>throws a
>>>>>>>>>>>>'permission denied'. Logging in to Fedora works after logging
>>>>>>>>>>>>in to
>>>>>>>>>>>>CentOS or the IPA migration web ui.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>sssd_domain.nl.log, loglevel 6
>>>>>>>>>>>>Fedora log: http://pastebin.centos.org/8281/
>>>>>>>>>>>>CentOS log: http://pastebin.centos.org/8286/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Additional details:
>>>>>>>>>>>>IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>>>>>>>>>>>>Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>>>>>>>>>>>>Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
>>>>>>>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>[ipa_resolve_callback]
>>>>>>>>>>>     (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>[write_pipe_handler]
>>>>>>>>>>>     (0x0400): All data has been sent!
>>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>[read_pipe_handler]
>>>>>>>>>>>     (0x0400): EOF received, client finished
>>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>[be_pam_handler_callback]
>>>>>>>>>>>     (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>>>>>>>>>>>                                    ^^^
>>>>>>>>>>>                                   It means  PAM_SYSTEM_ERR /*
>>>>>>>>>>>System
>>>>>>>>>>>error */
>>>>>>>>>>>
>>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>[be_pam_handler_callback]
>>>>>>>>>>>     (0x0100): Sending result [4][domain.nl]
>>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>[be_pam_handler_callback]
>>>>>>>>>>>     (0x0100): Sent result [4][domain.nl]
>>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>[child_sig_handler]
>>>>>>>>>>>     (0x0100): child [19510] finished successfully.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Both CentOS and Fedora are fully up-to-date using only the base
>>>>>>>>>>>>repos. Config of the clients is done with ipa-client-install.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Could you attach log files with debug_level 9?
>>>>>>>>>>>
>>>>>>>>>>>LS
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Sure. Just sssd_domain or do you need more?
>>>>>>>>>>
>>>>>>>>Are you using two different ipa servers?
>>>>>>>>ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
>>>>>>>>
>>>>>>>>>>sssd_domain.nl.log, loglevel 9
>>>>>>>>>>Fedora: http://pastebin.centos.org/8291/
>>>>>>>>Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>>
>>>>>>>>>>CentOS: http://pastebin.centos.org/8296/
>>>>>>>>Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  - Jitse
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>The problem is also present in RHEL7b with
>>>>>>>>>ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
>>>>>>>>>
>>>>>>>>>sssd_domain.nl.log, loglevel 9
>>>>>>>>>RHEL7b: http://pastebin.centos.org/8301/
>>>>>>>>Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>>
>>>>>>>>Could you also provide krb5_child.log and ldap_child.log from
>>>>>>>>fedora machine?
>>>>>>>>     (debug_level 9)
>>>>>>>>
>>>>>>>>LS
>>>>>>>>
>>>>>>>
>>>>>>>No, I'm using only one ipa server (vm-ipa). I accidentally
>>>>>>>copy-pasted without changing the domain name ;)
>>>>>>>
>>>>>>>>Any chance you could use the migrate-ds script to migrate users? I'm
>>>>>>>>not 100% sure if your own upgrade method does the same thing..
>>>>>>>I don't think so, our old LDAP schema is a mess...
>>>>>>>
>>>>>>>krb5_child.log: http://pastebin.centos.org/8306/
>>>>>>
>>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>    1394465217.407384: Getting initial credentials for jitse at DOMAIN.NL
>>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>    1394465217.407699: Sending request (173 bytes) to DOMAIN.NL
>>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>    1394465217.408202: Sending initial UDP request to dgram
>>>>>>10.14.3.15:88
>>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>    1394465217.425034: Received answer from dgram 10.14.3.15:88
>>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>    1394465217.425171: Response was from master KDC
>>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>    1394465217.425241: Received error from KDC:
>>>>>>-1765328361/Password has expired
>>>>>>[get_and_save_tgt] (0x0020): 918: [-1765328361][Password has expired]
>>>>>>[tgt_req_child] (0x1000): Password was expired
>>>>>>
>>>>>>It looks like password is expired for user jitse.
>>>>>>
>>>>>My hands were faster than my mind.
>>>>>
>>>>>I wanted to wrote:
>>>>>It looks like password is expired for user jitse.
>>>>>It is really weird because it works on Centos.
>>>>>Do you have a synchronized time on all machines with ipa server?
>>>>>
>>>>>LS
>>>>
>>>>Yes, time is in sync across all machines. I think the most
>>>>interesting lines in the log are these:
>>>>
>>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>>>[sss_child_krb5_trace_cb] (0x4000): [24671] 1394465217.441823:
>>>>Processing preauth types: 136, 19, 2, 133
>>>>
>>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>>>[map_krb5_error] (0x0020): 979: [-1765328234][Program lacks support
>>>>for encryption type]
>>>>
>>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>>>[pack_response_packet] (0x2000): response packet size: [4]
>>>>
>>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>>>[k5c_send_data] (0x4000): Response sent.
>>>>
>>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] [main]
>>>>(0x0400): krb5_child completed successfully
>>>>
>>>>This is where krb5_child on fedora just stops working while
>>>>krb5_child on CentOS does this: http://pastebin.centos.org/8316/
>>>>
>>>
>>>Can you send the krb5_child.log file with the success from CentOS as
>>>well? Looks like we might handle some error codes differently after
>>>introducing the sssd_errors code.
>>>
>>>bye,
>>>Sumit
>>>
>>>>
>>>>  - Jitse
>>
>>That last pastebin (http://pastebin.centos.org/8316/) was krb5_child.log
>>from a succesful first-time login on centos.
>>
>> > I'd be curious what the krbPasswordExpiration is for this user.
>>See http://pastebin.centos.org/8321/ for a password migration and output
>>of ldapsearch.
>>
>>Output of ldapsearch *after* logging in to CentOS for the first time:
>>     krbPasswordExpiration: 20140310183603Z
>>     krbLastPwdChange:      20140310183603Z
Why is the password exporation the same as the last password change?

LS
>>     krbExtraData:: AAITBh5Tcm9vdC9hZG1pbkBBLUVTS1dBRFJBQVQuTkwA
>>     krbLastFailedAuth: 20140310185101Z
>>     krbLoginFailedCount: 1
>
>The password looks expired to me given that the expiration time is
>prior to the last failed login.
>
>rob



From sbose at redhat.com  Mon Mar 10 21:06:31 2014
From: sbose at redhat.com (Sumit Bose)
Date: Mon, 10 Mar 2014 22:06:31 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <531E1C19.6020502@gmail.com>
References: <531DC9F0.4020405@gmail.com>
	<20140310151023.GE21499@mail.corp.redhat.com>
	<531DDBC3.4060700@gmail.com>
	<20140310155809.GG21499@mail.corp.redhat.com>
	<20140310160301.GH21499@mail.corp.redhat.com>
	<531DE71F.5000907@gmail.com>
	<20140310175733.GN2763@localhost.localdomain>
	<531E0AC7.2090209@gmail.com>
	<20140310193416.GO2763@localhost.localdomain>
	<531E1C19.6020502@gmail.com>
Message-ID: <20140310210631.GP2763@localhost.localdomain>

On Mon, Mar 10, 2014 at 09:10:01PM +0100, Jitse Klomp wrote:
> On 10-03-14 20:34, Sumit Bose wrote:
> >On Mon, Mar 10, 2014 at 07:56:07PM +0100, Jitse Klomp wrote:
> >>On 10-03-14 18:57, Sumit Bose wrote:
> >>>On Mon, Mar 10, 2014 at 05:23:59PM +0100, Jitse Klomp wrote:
> >>>>On 10-03-14 17:03, Lukas Slebodnik wrote:
> >>>>>On (10/03/14 16:58), Lukas Slebodnik wrote:
> >>>>>>On (10/03/14 16:35), Jitse Klomp wrote:
> >>>>>>>On 10-03-14 16:10, Lukas Slebodnik wrote:
> >>>>>>>>On (10/03/14 15:19), Jitse Klomp wrote:
> >>>>>>>>>On 10-03-14 14:59, Jitse Klomp wrote:
> >>>>>>>>>>On 10-03-14 14:35, Lukas Slebodnik wrote:
> >>>>>>>>>>>On (10/03/14 13:55), Jitse Klomp wrote:
> >>>>>>>>>>>>Hello all,
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>I'm migrating our OpenLDAP-based IdM-system to IPA. Instead of using
> >>>>>>>>>>>>migrate-ds I used some custom scripts to import all of our users (~250)
> >>>>>>>>>>>>and groups (~85) with IPA commands (ipa user-add etc.). To move
> >>>>>>>>>>>>passwords I configured the ipa-server to run in migration mode and did
> >>>>>>>>>>>>an ldapmodify like this:
> >>>>>>>>>>>>
> >>>>>>>>>>>>    dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
> >>>>>>>>>>>>    changetype: modify
> >>>>>>>>>>>>    replace: userPassword
> >>>>>>>>>>>>    userPassword: {SHA}hash
> >>>>>>>>>>>>
> >>>>>>>>>>>>Logging in to a machine running CentOS and ipa-client for the first time
> >>>>>>>>>>>>works like a charm, a krbPrincipalKey is generated and Kerberos 'just'
> >>>>>>>>>>>>works. However, logging in to Fedora 20 for the first time throws a
> >>>>>>>>>>>>'permission denied'. Logging in to Fedora works after logging in to
> >>>>>>>>>>>>CentOS or the IPA migration web ui.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>sssd_domain.nl.log, loglevel 6
> >>>>>>>>>>>>Fedora log: http://pastebin.centos.org/8281/
> >>>>>>>>>>>>CentOS log: http://pastebin.centos.org/8286/
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>Additional details:
> >>>>>>>>>>>>IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
> >>>>>>>>>>>>Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
> >>>>>>>>>>>>Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
> >>>>>>>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [ipa_resolve_callback]
> >>>>>>>>>>>     (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
> >>>>>>>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]] [write_pipe_handler]
> >>>>>>>>>>>     (0x0400): All data has been sent!
> >>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [read_pipe_handler]
> >>>>>>>>>>>     (0x0400): EOF received, client finished
> >>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
> >>>>>>>>>>>[be_pam_handler_callback]
> >>>>>>>>>>>     (0x0100): Backend returned: (0, 4, <NULL>) [Success]
> >>>>>>>>>>>                                    ^^^
> >>>>>>>>>>>                                   It means  PAM_SYSTEM_ERR /* System
> >>>>>>>>>>>error */
> >>>>>>>>>>>
> >>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
> >>>>>>>>>>>[be_pam_handler_callback]
> >>>>>>>>>>>     (0x0100): Sending result [4][domain.nl]
> >>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
> >>>>>>>>>>>[be_pam_handler_callback]
> >>>>>>>>>>>     (0x0100): Sent result [4][domain.nl]
> >>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]] [child_sig_handler]
> >>>>>>>>>>>     (0x0100): child [19510] finished successfully.
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>Both CentOS and Fedora are fully up-to-date using only the base
> >>>>>>>>>>>>repos. Config of the clients is done with ipa-client-install.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>Could you attach log files with debug_level 9?
> >>>>>>>>>>>
> >>>>>>>>>>>LS
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>Sure. Just sssd_domain or do you need more?
> >>>>>>>>>>
> >>>>>>>>Are you using two different ipa servers?
> >>>>>>>>ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
> >>>>>>>>
> >>>>>>>>>>sssd_domain.nl.log, loglevel 9
> >>>>>>>>>>Fedora: http://pastebin.centos.org/8291/
> >>>>>>>>Constructed uri 'ldap://vm-ipa.domain.nl'
> >>>>>>>>
> >>>>>>>>>>CentOS: http://pastebin.centos.org/8296/
> >>>>>>>>Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>  - Jitse
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>The problem is also present in RHEL7b with
> >>>>>>>>>ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
> >>>>>>>>>
> >>>>>>>>>sssd_domain.nl.log, loglevel 9
> >>>>>>>>>RHEL7b: http://pastebin.centos.org/8301/
> >>>>>>>>Constructed uri 'ldap://vm-ipa.domain.nl'
> >>>>>>>>
> >>>>>>>>Could you also provide krb5_child.log and ldap_child.log from fedora machine?
> >>>>>>>>     (debug_level 9)
> >>>>>>>>
> >>>>>>>>LS
> >>>>>>>>
> >>>>>>>
> >>>>>>>No, I'm using only one ipa server (vm-ipa). I accidentally
> >>>>>>>copy-pasted without changing the domain name ;)
> >>>>>>>
> >>>>>>>>Any chance you could use the migrate-ds script to migrate users? I'm
> >>>>>>>>not 100% sure if your own upgrade method does the same thing..
> >>>>>>>I don't think so, our old LDAP schema is a mess...
> >>>>>>>
> >>>>>>>krb5_child.log: http://pastebin.centos.org/8306/
> >>>>>>
> >>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>>>>>    1394465217.407384: Getting initial credentials for jitse at DOMAIN.NL
> >>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>>>>>    1394465217.407699: Sending request (173 bytes) to DOMAIN.NL
> >>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>>>>>    1394465217.408202: Sending initial UDP request to dgram 10.14.3.15:88
> >>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>>>>>    1394465217.425034: Received answer from dgram 10.14.3.15:88
> >>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>>>>>    1394465217.425171: Response was from master KDC
> >>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
> >>>>>>    1394465217.425241: Received error from KDC: -1765328361/Password has expired
> >>>>>>[get_and_save_tgt] (0x0020): 918: [-1765328361][Password has expired]
> >>>>>>[tgt_req_child] (0x1000): Password was expired
> >>>>>>
> >>>>>>It looks like password is expired for user jitse.
> >>>>>>
> >>>>>My hands were faster than my mind.
> >>>>>
> >>>>>I wanted to wrote:
> >>>>>It looks like password is expired for user jitse.
> >>>>>It is really weird because it works on Centos.
> >>>>>Do you have a synchronized time on all machines with ipa server?
> >>>>>
> >>>>>LS
> >>>>
> >>>>Yes, time is in sync across all machines. I think the most
> >>>>interesting lines in the log are these:
> >>>>
> >>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
> >>>>[sss_child_krb5_trace_cb] (0x4000): [24671] 1394465217.441823:
> >>>>Processing preauth types: 136, 19, 2, 133
> >>>>
> >>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
> >>>>[map_krb5_error] (0x0020): 979: [-1765328234][Program lacks support
> >>>>for encryption type]
> >>>>
> >>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
> >>>>[pack_response_packet] (0x2000): response packet size: [4]
> >>>>
> >>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
> >>>>[k5c_send_data] (0x4000): Response sent.
> >>>>
> >>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] [main]
> >>>>(0x0400): krb5_child completed successfully
> >>>>
> >>>>This is where krb5_child on fedora just stops working while
> >>>>krb5_child on CentOS does this: http://pastebin.centos.org/8316/
> >>>>
> >>>
> >>>Can you send the krb5_child.log file with the success from CentOS as
> >>>well? Looks like we might handle some error codes differently after
> >>>introducing the sssd_errors code.
> >>>
> >>>bye,
> >>>Sumit
> >>>
> >>>>
> >>>>  - Jitse
> >>
> >>That last pastebin (http://pastebin.centos.org/8316/) was
> >>krb5_child.log from a succesful first-time login on centos.
> >
> >Thanks. Can you try to set 'allow_weak_crypto = true' in the libdefaults
> >section of krb5.conf on F20 or RHEL7?
> >
> >bye,
> >Sumit
> >
> >>
> >>>I'd be curious what the krbPasswordExpiration is for this user.
> >>See http://pastebin.centos.org/8321/ for a password migration and
> >>output of ldapsearch.
> >>
> >>Output of ldapsearch *after* logging in to CentOS for the first time:
> >>     krbPasswordExpiration: 20140310183603Z
> >>     krbLastPwdChange: 20140310183603Z
> >>     krbExtraData:: AAITBh5Tcm9vdC9hZG1pbkBBLUVTS1dBRFJBQVQuTkwA
> >>     krbLastFailedAuth: 20140310185101Z
> >>     krbLoginFailedCount: 1
> >>
> >>  - Jitse
> 
> Yes, here you go: http://pastebin.centos.org/8331/
> 
> It doesn't seem to be a lot different from the old one...

Thank you. Maybe there is a change in return codes between MIT Kerberos
1.10 (Centos 6) and 1.11 (F20, RHEL7). Can you try to run 

KRB5_TRACE=/dev/stdout kinit unmigrated_user at DOMAIN.NL

on the different platforms and paste the results? I would expect to see
[Preauthentication failed] on Centos6 and [Program lacks support for
encryption type] on F10 or RHEL7.

bye,
Sumit

> 
>  - Jitse
> 
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users



From bnordgren at fs.fed.us  Mon Mar 10 21:09:42 2014
From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS)
Date: Mon, 10 Mar 2014 21:09:42 +0000
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <CAN0oX1ZwbPf6n_KkLOnbURg0Qic6y9QP6H7OJ8LRBH5BXfAAag@mail.gmail.com>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>
	<53191ED7.1000502@redhat.com>
	<CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>
	<531A4A77.6010201@redhat.com>
	<CAN0oX1ZwbPf6n_KkLOnbURg0Qic6y9QP6H7OJ8LRBH5BXfAAag@mail.gmail.com>
Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E692E74@001FSN2MPN1-045.001f.mgd2.msft.net>

I'm jumping in kind of late, but I may have a way for you to eliminate your current man in the middle password proxy.

> >>>>>>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
> >>>>>>>>
> >>>>>>>> Is it possible with FreeIPA to use an external KDC or pass some
> >>>>>>>> or all authentication to an external KDC?  The KDC at our
> >>>>>>>> University may give me a one way trust if I describe my
> >>>>>>>> implementation plan for FreeIPA.
> >>>>>>>> Currently I use 389DS with PAM pass through using untrusted
> >>>>>>>> pam_krb5.
> >>>>>>>> I'd like to fully utilize FreeIPA without managing passwords
> >>>>>>>> since all my users already have University accounts.  I just
> >>>>>>>> want to manage authorization for my systems, not
> >>>>>>>> authentication.
> >>>>>>>

First, I understand you to be saying that the University provides Kerberos authentication, but the associated "id_provider" either does not exist, is irrelevant to your situation, or you need to override/replace some values. If this is not correct, the remainder is unlikely to be applicable. Furthermore, some users allowed on your HPC cluster do not exist in the University system, so you need to be able to add users.

> >>>>> Right now the workflow I have with 389ds using PAM Pass Through
> >>>>> Auth is the following:
> >>>>>
> >>>>> For users with the proper attribute defined in 'pamIDAttr'
> >>>>>
> >>>>> client --->   389DS --->   389DS server's pam_krb5 --->   Campus KDC
> >>>>>
> >>>>> For users lacking the attribute for 'pamIDAttr'
> >>>>>
> >>>>> client --->   389DS
> >>>>>
> >>>>> The Kerberos setup currently on the 389DS server is untrusted (no
> >>>>> krb5.keytab).
> >>>>>
> >>>>> The ideal workflow with FreeIPA would be
> >>>>>
> >>>>> client ---->   IPA --->   Campus KDC
> >>>>>

First thing: emphasize in your deployment plan that you intend to eliminate your current password proxy. Gold star for you.

Second thing: you need two IPA instances because you have two realms. The first IPA instance manages the users from the University realm (for your machines only). The second IPA instance manages the extra users you plan on adding. The second instance also contains the machine entries for the nodes in your HPC cluster. For each user you intend to permit to use your cluster, you need to create an account in one of these IPAs.

Third: Configure sssd on your HPC nodes with a "University" realm. Your "University" realm should point "auth_provider" and "chpass_provider" "krb5_server", and "krb5_kpasswd"  to your university's KDC, "id_provider" should be ipa, and should point to your very own "HPC IPA". This will replace any "id_provider" information your university supplies, or create it if it does not exist.

Fourth: Configure sssd with an "HPC" Realm. Everything (auth_provider/id_provider) points to your HPC IPA instance.

Your "University" IPA instance manages a KDC. Ignore it. Never have your clients connect to it. You are interested in creating accounts having the same username as in the University's KDC. Just make it so that those users can't login using the IPA instance you set up. Give them random passwords which never expire. SSSD should take care of authenticating against the University.

You may also have to manually create the one-way Kerberos trust with the university using the MIT tools. This trust goes to the KDC managed by your "HPC" ipa instance.

It's probably not necessary to mess with a trust relationship between the two IPAs. Trust is a Kerberos thing, and only one of your IPAs has an important Kerberos store.

It may be useful to maintain the [capaths] section of krb5.conf on all your login appliances. It may not. Try it and let me know.

Your login node(s) will require network connectivity to the University's KDC. Other nodes will not. Once your users get a forwardable TGT from your HPC IPA (which they should get on login), they can directly authenticate to your cluster. Both of your IPA instances will need to be accessible from all nodes on your cluster.

This is just hypothetical. YMMV. I've been mulling over a similar problem for a long time, and I can't claim to have a perfect solution.

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.




From lslebodn at redhat.com  Mon Mar 10 21:32:42 2014
From: lslebodn at redhat.com (Lukas Slebodnik)
Date: Mon, 10 Mar 2014 22:32:42 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <20140310204712.GA25777@mail.corp.redhat.com>
References: <531DC9F0.4020405@gmail.com>
	<20140310151023.GE21499@mail.corp.redhat.com>
	<531DDBC3.4060700@gmail.com>
	<20140310155809.GG21499@mail.corp.redhat.com>
	<20140310160301.GH21499@mail.corp.redhat.com>
	<531DE71F.5000907@gmail.com>
	<20140310175733.GN2763@localhost.localdomain>
	<531E0AC7.2090209@gmail.com> <531E0F1D.6080402@redhat.com>
	<20140310204712.GA25777@mail.corp.redhat.com>
Message-ID: <20140310213241.GC25777@mail.corp.redhat.com>

On (10/03/14 21:47), Lukas Slebodnik wrote:
>On (10/03/14 15:14), Rob Crittenden wrote:
>>Jitse Klomp wrote:
>>>On 10-03-14 18:57, Sumit Bose wrote:
>>>>On Mon, Mar 10, 2014 at 05:23:59PM +0100, Jitse Klomp wrote:
>>>>>On 10-03-14 17:03, Lukas Slebodnik wrote:
>>>>>>On (10/03/14 16:58), Lukas Slebodnik wrote:
>>>>>>>On (10/03/14 16:35), Jitse Klomp wrote:
>>>>>>>>On 10-03-14 16:10, Lukas Slebodnik wrote:
>>>>>>>>>On (10/03/14 15:19), Jitse Klomp wrote:
>>>>>>>>>>On 10-03-14 14:59, Jitse Klomp wrote:
>>>>>>>>>>>On 10-03-14 14:35, Lukas Slebodnik wrote:
>>>>>>>>>>>>On (10/03/14 13:55), Jitse Klomp wrote:
>>>>>>>>>>>>>Hello all,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>I'm migrating our OpenLDAP-based IdM-system to IPA. Instead
>>>>>>>>>>>>>of using
>>>>>>>>>>>>>migrate-ds I used some custom scripts to import all of our
>>>>>>>>>>>>>users (~250)
>>>>>>>>>>>>>and groups (~85) with IPA commands (ipa user-add etc.). To move
>>>>>>>>>>>>>passwords I configured the ipa-server to run in migration
>>>>>>>>>>>>>mode and did
>>>>>>>>>>>>>an ldapmodify like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    dn: uid=jitse,cn=users,cn=accounts,dc=domain,dc=nl
>>>>>>>>>>>>>    changetype: modify
>>>>>>>>>>>>>    replace: userPassword
>>>>>>>>>>>>>    userPassword: {SHA}hash
>>>>>>>>>>>>>
>>>>>>>>>>>>>Logging in to a machine running CentOS and ipa-client for the
>>>>>>>>>>>>>first time
>>>>>>>>>>>>>works like a charm, a krbPrincipalKey is generated and
>>>>>>>>>>>>>Kerberos 'just'
>>>>>>>>>>>>>works. However, logging in to Fedora 20 for the first time
>>>>>>>>>>>>>throws a
>>>>>>>>>>>>>'permission denied'. Logging in to Fedora works after logging
>>>>>>>>>>>>>in to
>>>>>>>>>>>>>CentOS or the IPA migration web ui.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>sssd_domain.nl.log, loglevel 6
>>>>>>>>>>>>>Fedora log: http://pastebin.centos.org/8281/
>>>>>>>>>>>>>CentOS log: http://pastebin.centos.org/8286/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>Additional details:
>>>>>>>>>>>>>IPA server: CentOS 6.5, ipa-server-3.0.0-37.el6.x86_64
>>>>>>>>>>>>>Client 1: CentOS 6.5, ipa-client-3.0.0-37.el6.x86_64
>>>>>>>>>>>>>Client 2: Fedora 20, freeipa-client-3.3.3-4.fc20.x86_64
>>>>>>>>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>>[ipa_resolve_callback]
>>>>>>>>>>>>     (0x0400): Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>>>>>>(Mon Mar  3 22:15:42 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>>[write_pipe_handler]
>>>>>>>>>>>>     (0x0400): All data has been sent!
>>>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>>[read_pipe_handler]
>>>>>>>>>>>>     (0x0400): EOF received, client finished
>>>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>>[be_pam_handler_callback]
>>>>>>>>>>>>     (0x0100): Backend returned: (0, 4, <NULL>) [Success]
>>>>>>>>>>>>                                    ^^^
>>>>>>>>>>>>                                   It means  PAM_SYSTEM_ERR /*
>>>>>>>>>>>>System
>>>>>>>>>>>>error */
>>>>>>>>>>>>
>>>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>>[be_pam_handler_callback]
>>>>>>>>>>>>     (0x0100): Sending result [4][domain.nl]
>>>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>>[be_pam_handler_callback]
>>>>>>>>>>>>     (0x0100): Sent result [4][domain.nl]
>>>>>>>>>>>>(Mon Mar  3 22:15:43 2014) [sssd[be[domain.nl]]]
>>>>>>>>>>>>[child_sig_handler]
>>>>>>>>>>>>     (0x0100): child [19510] finished successfully.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>Both CentOS and Fedora are fully up-to-date using only the base
>>>>>>>>>>>>>repos. Config of the clients is done with ipa-client-install.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Could you attach log files with debug_level 9?
>>>>>>>>>>>>
>>>>>>>>>>>>LS
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Sure. Just sssd_domain or do you need more?
>>>>>>>>>>>
>>>>>>>>>Are you using two different ipa servers?
>>>>>>>>>ldap://vm-ipa.domain.nl, ldap://vm-ipa.a-eskwadraat.nl
>>>>>>>>>
>>>>>>>>>>>sssd_domain.nl.log, loglevel 9
>>>>>>>>>>>Fedora: http://pastebin.centos.org/8291/
>>>>>>>>>Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>>>
>>>>>>>>>>>CentOS: http://pastebin.centos.org/8296/
>>>>>>>>>Constructed uri 'ldap://vm-ipa.a-eskwadraat.nl'
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  - Jitse
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>The problem is also present in RHEL7b with
>>>>>>>>>>ipa-client-3.3.3-5.el7.x86_64 and sssd-1.11.2-1.el7.x86_64
>>>>>>>>>>
>>>>>>>>>>sssd_domain.nl.log, loglevel 9
>>>>>>>>>>RHEL7b: http://pastebin.centos.org/8301/
>>>>>>>>>Constructed uri 'ldap://vm-ipa.domain.nl'
>>>>>>>>>
>>>>>>>>>Could you also provide krb5_child.log and ldap_child.log from
>>>>>>>>>fedora machine?
>>>>>>>>>     (debug_level 9)
>>>>>>>>>
>>>>>>>>>LS
>>>>>>>>>
>>>>>>>>
>>>>>>>>No, I'm using only one ipa server (vm-ipa). I accidentally
>>>>>>>>copy-pasted without changing the domain name ;)
>>>>>>>>
>>>>>>>>>Any chance you could use the migrate-ds script to migrate users? I'm
>>>>>>>>>not 100% sure if your own upgrade method does the same thing..
>>>>>>>>I don't think so, our old LDAP schema is a mess...
>>>>>>>>
>>>>>>>>krb5_child.log: http://pastebin.centos.org/8306/
>>>>>>>
>>>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>>    1394465217.407384: Getting initial credentials for jitse at DOMAIN.NL
>>>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>>    1394465217.407699: Sending request (173 bytes) to DOMAIN.NL
>>>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>>    1394465217.408202: Sending initial UDP request to dgram
>>>>>>>10.14.3.15:88
>>>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>>    1394465217.425034: Received answer from dgram 10.14.3.15:88
>>>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>>    1394465217.425171: Response was from master KDC
>>>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671]
>>>>>>>    1394465217.425241: Received error from KDC:
>>>>>>>-1765328361/Password has expired
>>>>>>>[get_and_save_tgt] (0x0020): 918: [-1765328361][Password has expired]
>>>>>>>[tgt_req_child] (0x1000): Password was expired
>>>>>>>
>>>>>>>It looks like password is expired for user jitse.
>>>>>>>
>>>>>>My hands were faster than my mind.
>>>>>>
>>>>>>I wanted to wrote:
>>>>>>It looks like password is expired for user jitse.
>>>>>>It is really weird because it works on Centos.
>>>>>>Do you have a synchronized time on all machines with ipa server?
>>>>>>
>>>>>>LS
>>>>>
>>>>>Yes, time is in sync across all machines. I think the most
>>>>>interesting lines in the log are these:
>>>>>
>>>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>>>>[sss_child_krb5_trace_cb] (0x4000): [24671] 1394465217.441823:
>>>>>Processing preauth types: 136, 19, 2, 133
>>>>>
>>>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>>>>[map_krb5_error] (0x0020): 979: [-1765328234][Program lacks support
>>>>>for encryption type]
>>>>>
>>>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>>>>[pack_response_packet] (0x2000): response packet size: [4]
>>>>>
>>>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]]
>>>>>[k5c_send_data] (0x4000): Response sent.
>>>>>
>>>>>(Mon Mar 10 16:26:57 2014) [[sssd[krb5_child[24671]]]] [main]
>>>>>(0x0400): krb5_child completed successfully
>>>>>
>>>>>This is where krb5_child on fedora just stops working while
>>>>>krb5_child on CentOS does this: http://pastebin.centos.org/8316/
>>>>>
>>>>
>>>>Can you send the krb5_child.log file with the success from CentOS as
>>>>well? Looks like we might handle some error codes differently after
>>>>introducing the sssd_errors code.
>>>>
>>>>bye,
>>>>Sumit
>>>>
>>>>>
>>>>>  - Jitse
>>>
>>>That last pastebin (http://pastebin.centos.org/8316/) was krb5_child.log
>>>from a succesful first-time login on centos.
>>>
>>> > I'd be curious what the krbPasswordExpiration is for this user.
>>>See http://pastebin.centos.org/8321/ for a password migration and output
>>>of ldapsearch.
>>>
>>>Output of ldapsearch *after* logging in to CentOS for the first time:
>>>     krbPasswordExpiration: 20140310183603Z
>>>     krbLastPwdChange:      20140310183603Z
>Why is the password exporation the same as the last password change?
>
I will answer myself: because of migration mode.

LS



From simo at redhat.com  Mon Mar 10 21:51:11 2014
From: simo at redhat.com (Simo Sorce)
Date: Mon, 10 Mar 2014 17:51:11 -0400
Subject: [Freeipa-users] Migration mode
In-Reply-To: <20140310204712.GA25777@mail.corp.redhat.com>
References: <531DC550.1070903@gmail.com> <531DC9F0.4020405@gmail.com>
	<20140310151023.GE21499@mail.corp.redhat.com>
	<531DDBC3.4060700@gmail.com>
	<20140310155809.GG21499@mail.corp.redhat.com>
	<20140310160301.GH21499@mail.corp.redhat.com>
	<531DE71F.5000907@gmail.com>
	<20140310175733.GN2763@localhost.localdomain>
	<531E0AC7.2090209@gmail.com> <531E0F1D.6080402@redhat.com>
	<20140310204712.GA25777@mail.corp.redhat.com>
Message-ID: <1394488271.32465.31.camel@willson.li.ssimo.org>

On Mon, 2014-03-10 at 21:47 +0100, Lukas Slebodnik wrote:
> >>Output of ldapsearch *after* logging in to CentOS for the first
> time:
> >>     krbPasswordExpiration: 20140310183603Z
> >>     krbLastPwdChange:      20140310183603Z
> Why is the password exporation the same as the last password change?
> 
This is normal when an admin performs a password reset, it is used to
force the user to change the password on first login.
Not sure this is the case, as migration code is involved, so I am not
sure why it is happening in this case.

Simo.

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



From bnordgren at fs.fed.us  Mon Mar 10 21:51:52 2014
From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS)
Date: Mon, 10 Mar 2014 21:51:52 +0000
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <1394477675.32465.25.camel@willson.li.ssimo.org>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>	<20140307155921.GI19071@hendrix.redhat.com>
	<5319EE1D.1010207@redhat.com>
	<20140307162419.GL19071@hendrix.redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6926F2@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394231525.14651.146.camel@willson.li.ssimo.org>
	<82E7C9A01FD0764CACDD35D10F5DFB6E69284E@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394311954.14651.195.camel@willson.li.ssimo.org>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6929BF@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394477675.32465.25.camel@willson.li.ssimo.org>
Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E692F00@001FSN2MPN1-045.001f.mgd2.msft.net>

> But let me say I am not at all against having thesis' that explore some of these
> theoretical questions, however one need to understand that the deliverable
> may end up being something that cannot be implemented or that it would
> require a long time to do so. As long as that is clear everything is game.

If it was a "lock", it wouldn't make a good research topic. ;)

Deliverable could be an I-D which could eventually turn into an RFC at worst. At best, the student could adapt topology discovery algorithms from IP routers, adding in "directionality" and bindings between realm and dns names.

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.



From jitseklomp at gmail.com  Mon Mar 10 22:09:48 2014
From: jitseklomp at gmail.com (Jitse Klomp)
Date: Mon, 10 Mar 2014 23:09:48 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <20140310210631.GP2763@localhost.localdomain>
References: <531DC9F0.4020405@gmail.com>	<20140310151023.GE21499@mail.corp.redhat.com>	<531DDBC3.4060700@gmail.com>	<20140310155809.GG21499@mail.corp.redhat.com>	<20140310160301.GH21499@mail.corp.redhat.com>	<531DE71F.5000907@gmail.com>	<20140310175733.GN2763@localhost.localdomain>	<531E0AC7.2090209@gmail.com>	<20140310193416.GO2763@localhost.localdomain>	<531E1C19.6020502@gmail.com>
	<20140310210631.GP2763@localhost.localdomain>
Message-ID: <531E382C.6000801@gmail.com>

On 10-03-14 22:06, Sumit Bose wrote:
> Thank you. Maybe there is a change in return codes between MIT Kerberos
> 1.10 (Centos 6) and 1.11 (F20, RHEL7). Can you try to run
>
> KRB5_TRACE=/dev/stdout kinit unmigrated_user at DOMAIN.NL
>
> on the different platforms and paste the results? I would expect to see
> [Preauthentication failed] on Centos6 and [Program lacks support for
> encryption type] on F10 or RHEL7.
>
> bye,
> Sumit

http://pastebin.centos.org/8336/
Top one is CentOS, bottom one Fedora. Output on RHEL7 is the same as on 
Fedora.

  - Jitse



From dpal at redhat.com  Mon Mar 10 22:49:27 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 10 Mar 2014 18:49:27 -0400
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <1394478786.2147.14.camel@localhost.localdomain>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>
	<53191ED7.1000502@redhat.com>
	<CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>
	<531A4A77.6010201@redhat.com>
	<CAN0oX1ZwbPf6n_KkLOnbURg0Qic6y9QP6H7OJ8LRBH5BXfAAag@mail.gmail.com>
	<531BAD8E.5020502@redhat.com>
	<1394461922.2147.6.camel@localhost.localdomain>
	<531E0973.3090208@redhat.com>
	<1394478786.2147.14.camel@localhost.localdomain>
Message-ID: <531E4177.2040709@redhat.com>

On 03/10/2014 03:13 PM, Nathaniel McCallum wrote:
> On Mon, 2014-03-10 at 14:50 -0400, Dmitri Pal wrote:
>> On 03/10/2014 10:32 AM, Nathaniel McCallum wrote:
>>> On Sat, 2014-03-08 at 18:53 -0500, Dmitri Pal wrote:
>>>> On 03/08/2014 04:36 PM, Trey Dockendorf wrote:
>>>>> I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no NTP).
>>>>>
>>>>> IPA is 3.3.3-5.el7
>>>>> SSSD is 1.11.2-1.el7
>>>>> krb5 is 1.11.3-31.el7
>>>>>
>>>>> Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted
>>>>> the CLI commands under "Feature Management", with no luck.
>>>>>
>>>>> For example:
>>>>>
>>>>> ---
>>>>> # ipa config-mod --user-auth-type=['password', 'otp', 'radius']
>>>>> Usage: ipa [global-options] config-mod [options]
>>>>>
>>>>> ipa: error: no such option: --user-auth-type
>>>>> ---
>>>>>
>>>>> The ipa subcommands "radiusproxy-*" do not exist either.
>>>>>
>>>>> What version of IPA should I use to test this proof of concept?  The
>>>>> docs mention needing Kerberos no earlier than 1.12, which isn't
>>>>> available in EL7.
>>>>>
>>>>> My understanding of Kerberos is not great, but is FreeIPA simply not
>>>>> designed for external Kerberos (like the use of an external CA)?  Is
>>>>> there possibly a way to utilize FreeIPA without Kerberos, and just
>>>>> manage 389DS while still using the web interface (hard to find good
>>>>> Identity Management Web UI) and CLI tools?  I'd still like to get this
>>>>> working in FreeIPA, but am working on upgrading our HPC cluster to EL6
>>>>> (or EL7) and moving to FreeIPA would be a great improvement over 389DS
>>>>> in terms of manageability.
>>>>>
>>>> Nathaniel, do we have a build of the latest bits for RHEL7 somewhere?
>>>> Can you help with this POC please?
>>> None of those commands will be present in EL 7.0 and we don't currently
>>> have EL 7.0 builds of FreeIPA 4.0 master to my knowledge.
>> I thought we have something that builds latest bits for RHEL. If not is
>> it hard to produce one?
> http://koji.fedoraproject.org/koji/packageinfo?packageID=11554
>
> Koji doesn't currently list an EPEL build of IPA, most likely because
> such a package would disturb the EL packages. We could create a Copr
> build for EL6, but I don't know how many dependencies it would drag in.
> If the dependencies are minimal, the job would be fairly easy. I may
> take a stab at this later this week.

No build on top of RHEL7b build would be good enough.

>
>>> It would be possible to do this via manual manipulation of the LDAP
>>> entries. You'd need to create an ipatokenRadiusConfiguration object and
>>> then add the ipatokenRadiusProxyUser class (ipatokenRadiusConfigLink
>>> attribute) to each user you'd like to proxy.
>>>
>>> However, I don't think manual manipulation of LDAP like this is a
>>> supported operation. I would also imagine that your University may look
>>> down on an intentional man-in-the-middle password proxy.
>>>
>>> Nathaniel
>>>
>> Nathaniel. All the security disclaimers have been mentioned earlier in
>> the thread.
>> While I agree with you from security POV proxy is a solution that
>> already in place so it is not worse than now.
> Yup, I just wanted to make sure I covered the disclaimers in full in the
> same email detailing how to enable it. :)
>
> Nathaniel
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From dpal at redhat.com  Mon Mar 10 22:58:08 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 10 Mar 2014 18:58:08 -0400
Subject: [Freeipa-users] Using external KDC
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E692E74@001FSN2MPN1-045.001f.mgd2.msft.net>
References: <CAN0oX1aDM-+nQgM=gHi3N3Jf7Ghte-FKW1FQTdJ=pgV6hzYWKw@mail.gmail.com>
	<1393894054.22047.59.camel@willson.li.ssimo.org>
	<53152C7C.9070304@redhat.com>
	<CAN0oX1Yy8Cv3cgqMveaVo-VsfSv-p6PEDGrcpKwOPMBQPOBkXQ@mail.gmail.com>
	<CAN0oX1bPM_pf3LPZgVQt-JNKdUgmcu0tMxAbHgQ0Yu2xaXjFeQ@mail.gmail.com>
	<53191ED7.1000502@redhat.com>
	<CAN0oX1baYvait+NgjMoVf8SZURO6A0AUP_L1_LdiNg2gJnrANA@mail.gmail.com>
	<531A4A77.6010201@redhat.com>
	<CAN0oX1ZwbPf6n_KkLOnbURg0Qic6y9QP6H7OJ8LRBH5BXfAAag@mail.gmail.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E692E74@001FSN2MPN1-045.001f.mgd2.msft.net>
Message-ID: <531E4380.6030103@redhat.com>

On 03/10/2014 05:09 PM, Nordgren, Bryce L -FS wrote:
> I'm jumping in kind of late, but I may have a way for you to eliminate your current man in the middle password proxy.
>
>>>>>>>>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
>>>>>>>>>> Is it possible with FreeIPA to use an external KDC or pass some
>>>>>>>>>> or all authentication to an external KDC?  The KDC at our
>>>>>>>>>> University may give me a one way trust if I describe my
>>>>>>>>>> implementation plan for FreeIPA.
>>>>>>>>>> Currently I use 389DS with PAM pass through using untrusted
>>>>>>>>>> pam_krb5.
>>>>>>>>>> I'd like to fully utilize FreeIPA without managing passwords
>>>>>>>>>> since all my users already have University accounts.  I just
>>>>>>>>>> want to manage authorization for my systems, not
>>>>>>>>>> authentication.
> First, I understand you to be saying that the University provides Kerberos authentication, but the associated "id_provider" either does not exist, is irrelevant to your situation, or you need to override/replace some values. If this is not correct, the remainder is unlikely to be applicable. Furthermore, some users allowed on your HPC cluster do not exist in the University system, so you need to be able to add users.
>
>>>>>>> Right now the workflow I have with 389ds using PAM Pass Through
>>>>>>> Auth is the following:
>>>>>>>
>>>>>>> For users with the proper attribute defined in 'pamIDAttr'
>>>>>>>
>>>>>>> client --->    389DS --->    389DS server's pam_krb5 --->    Campus KDC
>>>>>>>
>>>>>>> For users lacking the attribute for 'pamIDAttr'
>>>>>>>
>>>>>>> client --->    389DS
>>>>>>>
>>>>>>> The Kerberos setup currently on the 389DS server is untrusted (no
>>>>>>> krb5.keytab).
>>>>>>>
>>>>>>> The ideal workflow with FreeIPA would be
>>>>>>>
>>>>>>> client ---->    IPA --->    Campus KDC
>>>>>>>
> First thing: emphasize in your deployment plan that you intend to eliminate your current password proxy. Gold star for you.
>
> Second thing: you need two IPA instances because you have two realms. The first IPA instance manages the users from the University realm (for your machines only). The second IPA instance manages the extra users you plan on adding. The second instance also contains the machine entries for the nodes in your HPC cluster. For each user you intend to permit to use your cluster, you need to create an account in one of these IPAs.
>
> Third: Configure sssd on your HPC nodes with a "University" realm. Your "University" realm should point "auth_provider" and "chpass_provider" "krb5_server", and "krb5_kpasswd"  to your university's KDC, "id_provider" should be ipa, and should point to your very own "HPC IPA". This will replace any "id_provider" information your university supplies, or create it if it does not exist.
>
> Fourth: Configure sssd with an "HPC" Realm. Everything (auth_provider/id_provider) points to your HPC IPA instance.
>
> Your "University" IPA instance manages a KDC. Ignore it. Never have your clients connect to it. You are interested in creating accounts having the same username as in the University's KDC. Just make it so that those users can't login using the IPA instance you set up. Give them random passwords which never expire. SSSD should take care of authenticating against the University.
>
> You may also have to manually create the one-way Kerberos trust with the university using the MIT tools. This trust goes to the KDC managed by your "HPC" ipa instance.
>
> It's probably not necessary to mess with a trust relationship between the two IPAs. Trust is a Kerberos thing, and only one of your IPAs has an important Kerberos store.
>
> It may be useful to maintain the [capaths] section of krb5.conf on all your login appliances. It may not. Try it and let me know.
>
> Your login node(s) will require network connectivity to the University's KDC. Other nodes will not. Once your users get a forwardable TGT from your HPC IPA (which they should get on login), they can directly authenticate to your cluster. Both of your IPA instances will need to be accessible from all nodes on your cluster.
>
> This is just hypothetical. YMMV. I've been mulling over a similar problem for a long time, and I can't claim to have a perfect solution.
>
> 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.
>
This is very similar to sort of split brain approach that we do not 
recommend because it is hard to maintain. See the following presentation
https://www.youtube.com/watch?v=cS6EJ1L7fRI minute 32:00
See the diagram but instead of AD assume it is your University KDC.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From bnordgren at fs.fed.us  Mon Mar 10 23:06:21 2014
From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS)
Date: Mon, 10 Mar 2014 23:06:21 +0000
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <1394477675.32465.25.camel@willson.li.ssimo.org>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>	<20140307155921.GI19071@hendrix.redhat.com>
	<5319EE1D.1010207@redhat.com>
	<20140307162419.GL19071@hendrix.redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6926F2@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394231525.14651.146.camel@willson.li.ssimo.org>
	<82E7C9A01FD0764CACDD35D10F5DFB6E69284E@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394311954.14651.195.camel@willson.li.ssimo.org>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6929BF@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394477675.32465.25.camel@willson.li.ssimo.org>
Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E692F6E@001FSN2MPN1-045.001f.mgd2.msft.net>



> In the default case IPA, will automatically allocate a non conflicting range to
> AD SIDs and pa SIDs to UIDs automatically. however if you want to use posix
> Ids stored in AD then yes, you will have to take care manually to avoid
> conflicts.

A perhaps doable, more applied thesis still requiring a substantial bit of work:

Posit a successful collaboration ecosystem that organizations are free to join or leave at will. Each realm must be free to use UID/GID of their choice without coordinating with all potential collaborators. The combination of UIDs/GIDs presented to individual machines still must not collide.

I think this could happen in IPA, assuming that all local machines and services authenticate with Kerberos. IPA would have to allocate a "foreign principal" record whenever the KDC was presented with a cross-realm TGT for a local service from a "new" foreign client (that may be tricky). IPA could manage the UID space for its own realm. Sssd would no longer need multiple realm entries and all relevant "id_provider" info could be synthesized at the realm level by IPA.

Effectively, the unique identifier for all external principles is username at REALM, with all the previously mentioned renaming problems. Local principals have their numeric id. But admins still shouldn't rename principals because they will cause problems for their collaborators.

Or, each machine could do it. It's a matter of deciding what the integration point is for cross-realm operation. That's pretty well defined for Kerberos (the KDC), and for the id provider (sssd). Trouble is, they're different integration points.


> Actually the solution to avoid capaths on clients is already planned, and it is to
> stop having clients try to discover topology on their own at all. Clients should
> always communicate with their KDC, and the KDC will issue referrals as
> appropriate. Once you do this capaths can be dismantled for the clients, the
> KDC will care for handling topology information.

I take it this is a reading assignment for RFC6806. :) I shall dive in.

> One small problem remains: how do I find the KDC if the realm name of the
> realm does not match the DNS domain name ? That is something that can be,
> perhaps resolved with some additional PA-DATA on the referrals if there is
> no other way.

Yeah. Also, the DNS domain name of a service may not match the DNS domain name of it's home KDC...

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.



From dtaylor at pactelint.com  Mon Mar 10 23:34:11 2014
From: dtaylor at pactelint.com (David Taylor)
Date: Tue, 11 Mar 2014 10:34:11 +1100
Subject: [Freeipa-users] SSS for sudoers confusion
Message-ID: <ecb313ccbc842f86b6c9c57f39bcb108@mail.gmail.com>

Hi all,
           I'm in the process of testing IPA server for centralised
authentication of our linux hosts. We run CentOS 6.5 and it's all new so
we have no legacy issues.

In the lab I've set up an IPA server with the yum install and used a local
bind instance which all seems to be working correctly. Where the issues
begin is with the sudoers functionality. After reading the manual and
consulting Google sensei I found a number of resources that talk about
setting up ldap either natively in the nsswitch.conf file or via sssd,
I've tried a number of slightly different configurations on the client
side with little effect. So the question is "what is the process for
configuring an IPA system to handle sudo functionality".

Any help is greatly appreciated.

----------------------nssswitch.conf--------------------------------------
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
#       nisplus                 Use NIS+ (NIS version 3)
#       nis                     Use NIS (NIS version 2), also called YP
#       dns                     Use DNS (Domain Name Service)
#       files                   Use the local files
#       db                      Use the local database (.db) files
#       compat                  Use NIS on compat mode
#       hesiod                  Use Hesiod for user lookups
#       [NOTFOUND=return]       Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:     files sss
shadow:     files sss
group:      files sss

#hosts:     db files nisplus nis dns
hosts:      files dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss
sudoers:    files sss
netgroup:   files sss

publickey:  nisplus

automount:  files sss
aliases:    files nisplus

--------------------------------------------------------------------------
-----------------------------
---------------
sssd.conf-----------------------------------------------------------------
-----------
[domain/test.example.net]

cache_credentials = True
krb5_store_password_if_offline = True
krb5_realm = TEST.EXAMPLE.NET
krb5_server = ipa-server-1.test.example.net
ipa_domain = test.example.net
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ipa-server-1.test.example.net
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = _srv_, ipa-server-1.test.example.net
ldap_tls_cacert = /etc/ipa/ca.crt
ldap_uri = ldap://ipa-server-1.test.example.net

[sssd]
services = nss, pam, ssh, sudo
config_file_version = 2
sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,dc=test,dc=example,dc=net
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/ipa-client.test.example.net
ldap_sasl_realm = TEST.EXAMPLE.NET

domains = test.example.net
[nss]

[pam]

[sudo]

[autofs]

[ssh]

[pac]
--------------------------------------------------------------------------
-------------------------------

Best regards
David Taylor

David Taylor
Head of Engineering - SpeedCast Pacific



Level 1, Unit 4F
12 Lord St, Botany
NSW, Australia, 2019
Office                      +61 2 9531 7555
Direct:               +61 2 9086 2787
Mobile:              +61 4 3131 1146
24x7 Helpdesk   +61 2 9016 3222
Web:                http://www.example.com / www.speedcast.com

To strengthen our corporate identity in target markets worldwide,
effective 18th January, we have commenced operating under the SpeedCast
name. Read More



From dpal at redhat.com  Mon Mar 10 23:48:31 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 10 Mar 2014 19:48:31 -0400
Subject: [Freeipa-users] SSS for sudoers confusion
In-Reply-To: <ecb313ccbc842f86b6c9c57f39bcb108@mail.gmail.com>
References: <ecb313ccbc842f86b6c9c57f39bcb108@mail.gmail.com>
Message-ID: <531E4F4F.6080101@redhat.com>

On 03/10/2014 07:34 PM, David Taylor wrote:
> Hi all,
>             I'm in the process of testing IPA server for centralised
> authentication of our linux hosts. We run CentOS 6.5 and it's all new so
> we have no legacy issues.
>
> In the lab I've set up an IPA server with the yum install and used a local
> bind instance which all seems to be working correctly. Where the issues
> begin is with the sudoers functionality. After reading the manual and
> consulting Google sensei I found a number of resources that talk about
> setting up ldap either natively in the nsswitch.conf file or via sssd,
> I've tried a number of slightly different configurations on the client
> side with little effect. So the question is "what is the process for
> configuring an IPA system to handle sudo functionality".
>
> Any help is greatly appreciated.

http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf

>
> ----------------------nssswitch.conf--------------------------------------
> #
> # /etc/nsswitch.conf
> #
> # An example Name Service Switch config file. This file should be
> # sorted with the most-used services at the beginning.
> #
> # The entry '[NOTFOUND=return]' means that the search for an
> # entry should stop if the search in the previous entry turned
> # up nothing. Note that if the search failed due to some other reason
> # (like no NIS server responding) then the search continues with the
> # next entry.
> #
> # Valid entries include:
> #
> #       nisplus                 Use NIS+ (NIS version 3)
> #       nis                     Use NIS (NIS version 2), also called YP
> #       dns                     Use DNS (Domain Name Service)
> #       files                   Use the local files
> #       db                      Use the local database (.db) files
> #       compat                  Use NIS on compat mode
> #       hesiod                  Use Hesiod for user lookups
> #       [NOTFOUND=return]       Stop searching if not found so far
> #
>
> # To use db, put the "db" in front of "files" for entries you want to be
> # looked up first in the databases
> #
> # Example:
> #passwd:    db files nisplus nis
> #shadow:    db files nisplus nis
> #group:     db files nisplus nis
>
> passwd:     files sss
> shadow:     files sss
> group:      files sss
>
> #hosts:     db files nisplus nis dns
> hosts:      files dns
>
> # Example - obey only what nisplus tells us...
> #services:   nisplus [NOTFOUND=return] files
> #networks:   nisplus [NOTFOUND=return] files
> #protocols:  nisplus [NOTFOUND=return] files
> #rpc:        nisplus [NOTFOUND=return] files
> #ethers:     nisplus [NOTFOUND=return] files
> #netmasks:   nisplus [NOTFOUND=return] files
>
> bootparams: nisplus [NOTFOUND=return] files
>
> ethers:     files
> netmasks:   files
> networks:   files
> protocols:  files
> rpc:        files
> services:   files sss
> sudoers:    files sss
> netgroup:   files sss
>
> publickey:  nisplus
>
> automount:  files sss
> aliases:    files nisplus
>
> --------------------------------------------------------------------------
> -----------------------------
> ---------------
> sssd.conf-----------------------------------------------------------------
> -----------
> [domain/test.example.net]
>
> cache_credentials = True
> krb5_store_password_if_offline = True
> krb5_realm = TEST.EXAMPLE.NET
> krb5_server = ipa-server-1.test.example.net
> ipa_domain = test.example.net
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = ipa-server-1.test.example.net
> chpass_provider = ipa
> ipa_dyndns_update = True
> ipa_server = _srv_, ipa-server-1.test.example.net
> ldap_tls_cacert = /etc/ipa/ca.crt
> ldap_uri = ldap://ipa-server-1.test.example.net
>
> [sssd]
> services = nss, pam, ssh, sudo
> config_file_version = 2
> sudo_provider = ldap
> ldap_sudo_search_base = ou=sudoers,dc=test,dc=example,dc=net
> ldap_sasl_mech = GSSAPI
> ldap_sasl_authid = host/ipa-client.test.example.net
> ldap_sasl_realm = TEST.EXAMPLE.NET
>
> domains = test.example.net
> [nss]
>
> [pam]
>
> [sudo]
>
> [autofs]
>
> [ssh]
>
> [pac]
> --------------------------------------------------------------------------
> -------------------------------
>
> Best regards
> David Taylor
>
> David Taylor
> Head of Engineering - SpeedCast Pacific
>
>
>
> Level 1, Unit 4F
> 12 Lord St, Botany
> NSW, Australia, 2019
> Office                      +61 2 9531 7555
> Direct:               +61 2 9086 2787
> Mobile:              +61 4 3131 1146
> 24x7 Helpdesk   +61 2 9016 3222
> Web:                http://www.example.com / www.speedcast.com
>
> To strengthen our corporate identity in target markets worldwide,
> effective 18th January, we have commenced operating under the SpeedCast
> name. Read More
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/





From simo at redhat.com  Mon Mar 10 23:50:31 2014
From: simo at redhat.com (Simo Sorce)
Date: Mon, 10 Mar 2014 19:50:31 -0400
Subject: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E692F6E@001FSN2MPN1-045.001f.mgd2.msft.net>
References: <531878F9.80400@redhat.com> <53189A86.7000707@redhat.com>
	<5319E1EB.1060304@redhat.com>	<20140307155921.GI19071@hendrix.redhat.com>
	<5319EE1D.1010207@redhat.com>
	<20140307162419.GL19071@hendrix.redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6926F2@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394231525.14651.146.camel@willson.li.ssimo.org>
	<82E7C9A01FD0764CACDD35D10F5DFB6E69284E@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394311954.14651.195.camel@willson.li.ssimo.org>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6929BF@001FSN2MPN1-045.001f.mgd2.msft.net>
	<1394477675.32465.25.camel@willson.li.ssimo.org>
	<82E7C9A01FD0764CACDD35D10F5DFB6E692F6E@001FSN2MPN1-045.001f.mgd2.msft.net>
Message-ID: <1394495431.32465.50.camel@willson.li.ssimo.org>

On Mon, 2014-03-10 at 23:06 +0000, Nordgren, Bryce L -FS wrote:
> 
> > In the default case IPA, will automatically allocate a non conflicting range to
> > AD SIDs and pa SIDs to UIDs automatically. however if you want to use posix
> > Ids stored in AD then yes, you will have to take care manually to avoid
> > conflicts.
> 
> A perhaps doable, more applied thesis still requiring a substantial
> bit of work:
> 
> Posit a successful collaboration ecosystem that organizations are free
> to join or leave at will. Each realm must be free to use UID/GID of
> their choice without coordinating with all potential collaborators.
> The combination of UIDs/GIDs presented to individual machines still
> must not collide.
> 
> I think this could happen in IPA, assuming that all local machines and
> services authenticate with Kerberos. IPA would have to allocate a
> "foreign principal" record whenever the KDC was presented with a
> cross-realm TGT for a local service from a "new" foreign client (that
> may be tricky). IPA could manage the UID space for its own realm. Sssd
> would no longer need multiple realm entries and all relevant
> "id_provider" info could be synthesized at the realm level by IPA.

This is what we basically do with AD trusts if you do not configure the
trust to go and fetch Posix Ids from AD and is the default case :-)

I see no problem doing the same with another IPA trusts once we have
such a thing.

> Effectively, the unique identifier for all external principles is
> username at REALM, with all the previously mentioned renaming problems.

Not necessarily we can do algorithmic mapping (like we do for SID->UID
with AD trusts) and maintain the foreign ID as the actual identifier.

>  Local principals have their numeric id. But admins still shouldn't
> rename principals because they will cause problems for their
> collaborators.
> 
> Or, each machine could do it. It's a matter of deciding what the
> integration point is for cross-realm operation. That's pretty well
> defined for Kerberos (the KDC), and for the id provider (sssd).
> Trouble is, they're different integration points.
> 
Well for IPA it will not be a big deal, once we offocially support
trusts these trusts will be sssd subdomains and the configuration is
fetched from IPA.

> > Actually the solution to avoid capaths on clients is already planned, and it is to
> > stop having clients try to discover topology on their own at all. Clients should
> > always communicate with their KDC, and the KDC will issue referrals as
> > appropriate. Once you do this capaths can be dismantled for the clients, the
> > KDC will care for handling topology information.
> 
> I take it this is a reading assignment for RFC6806. :) I shall dive in.

Indeed.

> > One small problem remains: how do I find the KDC if the realm name of the
> > realm does not match the DNS domain name ? That is something that can be,
> > perhaps resolved with some additional PA-DATA on the referrals if there is
> > no other way.
> 
> Yeah. Also, the DNS domain name of a service may not match the DNS domain name of it's home KDC...

That's not a problem, just a capath routing.

Simo.

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



From dtaylor at pactelint.com  Tue Mar 11 01:00:25 2014
From: dtaylor at pactelint.com (David Taylor)
Date: Tue, 11 Mar 2014 12:00:25 +1100
Subject: [Freeipa-users] SSS for sudoers confusion
In-Reply-To: <531E4F4F.6080101@redhat.com>
References: <ecb313ccbc842f86b6c9c57f39bcb108@mail.gmail.com>
	<531E4F4F.6080101@redhat.com>
Message-ID: <2627e6f4f9584458353d1d405289ae21@mail.gmail.com>

@Dmitri - Thank you for your reply, that is actually one of the documents
I read, however there seem to be some steps missing as with the
configuration elements in place sudo doesn't work

dtaylor is not allowed to run sudo on ipa-client.  This incident will be
reported.

There is some note about configuring a password on the ldap user however
following the suggestions I found didn't actually work.


Best regards
David Taylor


-----Original Message-----
From: freeipa-users-bounces at redhat.com
[mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal
Sent: Tuesday, 11 March 2014 10:49 AM
To: freeipa-users at redhat.com
Subject: Re: [Freeipa-users] SSS for sudoers confusion

On 03/10/2014 07:34 PM, David Taylor wrote:
> Hi all,
>             I'm in the process of testing IPA server for centralised
> authentication of our linux hosts. We run CentOS 6.5 and it's all new
> so we have no legacy issues.
>
> In the lab I've set up an IPA server with the yum install and used a
> local bind instance which all seems to be working correctly. Where the
> issues begin is with the sudoers functionality. After reading the
> manual and consulting Google sensei I found a number of resources that
> talk about setting up ldap either natively in the nsswitch.conf file
> or via sssd, I've tried a number of slightly different configurations
> on the client side with little effect. So the question is "what is the
> process for configuring an IPA system to handle sudo functionality".
>
> Any help is greatly appreciated.

http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf

>
> ----------------------nssswitch.conf----------------------------------
> ----
> #
> # /etc/nsswitch.conf
> #
> # An example Name Service Switch config file. This file should be #
> sorted with the most-used services at the beginning.
> #
> # The entry '[NOTFOUND=return]' means that the search for an # entry
> should stop if the search in the previous entry turned # up nothing.
> Note that if the search failed due to some other reason # (like no NIS
> server responding) then the search continues with the # next entry.
> #
> # Valid entries include:
> #
> #       nisplus                 Use NIS+ (NIS version 3)
> #       nis                     Use NIS (NIS version 2), also called YP
> #       dns                     Use DNS (Domain Name Service)
> #       files                   Use the local files
> #       db                      Use the local database (.db) files
> #       compat                  Use NIS on compat mode
> #       hesiod                  Use Hesiod for user lookups
> #       [NOTFOUND=return]       Stop searching if not found so far
> #
>
> # To use db, put the "db" in front of "files" for entries you want to
> be # looked up first in the databases # # Example:
> #passwd:    db files nisplus nis
> #shadow:    db files nisplus nis
> #group:     db files nisplus nis
>
> passwd:     files sss
> shadow:     files sss
> group:      files sss
>
> #hosts:     db files nisplus nis dns
> hosts:      files dns
>
> # Example - obey only what nisplus tells us...
> #services:   nisplus [NOTFOUND=return] files
> #networks:   nisplus [NOTFOUND=return] files
> #protocols:  nisplus [NOTFOUND=return] files
> #rpc:        nisplus [NOTFOUND=return] files
> #ethers:     nisplus [NOTFOUND=return] files
> #netmasks:   nisplus [NOTFOUND=return] files
>
> bootparams: nisplus [NOTFOUND=return] files
>
> ethers:     files
> netmasks:   files
> networks:   files
> protocols:  files
> rpc:        files
> services:   files sss
> sudoers:    files sss
> netgroup:   files sss
>
> publickey:  nisplus
>
> automount:  files sss
> aliases:    files nisplus
>
> ----------------------------------------------------------------------
> ----
> -----------------------------
> ---------------
> sssd.conf-------------------------------------------------------------
> ----
> -----------
> [domain/test.example.net]
>
> cache_credentials = True
> krb5_store_password_if_offline = True
> krb5_realm = TEST.EXAMPLE.NET
> krb5_server = ipa-server-1.test.example.net ipa_domain =
> test.example.net id_provider = ipa auth_provider = ipa access_provider
> = ipa ipa_hostname = ipa-server-1.test.example.net chpass_provider =
> ipa ipa_dyndns_update = True ipa_server = _srv_,
> ipa-server-1.test.example.net ldap_tls_cacert = /etc/ipa/ca.crt
> ldap_uri = ldap://ipa-server-1.test.example.net
>
> [sssd]
> services = nss, pam, ssh, sudo
> config_file_version = 2
> sudo_provider = ldap
> ldap_sudo_search_base = ou=sudoers,dc=test,dc=example,dc=net
> ldap_sasl_mech = GSSAPI
> ldap_sasl_authid = host/ipa-client.test.example.net ldap_sasl_realm =
> TEST.EXAMPLE.NET
>
> domains = test.example.net
> [nss]
>
> [pam]
>
> [sudo]
>
> [autofs]
>
> [ssh]
>
> [pac]
> ----------------------------------------------------------------------
> ----
> -------------------------------
>
> Best regards
> David Taylor
>
> David Taylor
> Head of Engineering - SpeedCast Pacific
>
>
>
> Level 1, Unit 4F
> 12 Lord St, Botany
> NSW, Australia, 2019
> Office                      +61 2 9531 7555
> Direct:               +61 2 9086 2787
> Mobile:              +61 4 3131 1146
> 24x7 Helpdesk   +61 2 9016 3222
> Web:                http://www.example.com / www.speedcast.com
>
> To strengthen our corporate identity in target markets worldwide,
> effective 18th January, we have commenced operating under the
> SpeedCast name. Read More
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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 at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



From dtaylor at pactelint.com  Tue Mar 11 02:57:16 2014
From: dtaylor at pactelint.com (David Taylor)
Date: Tue, 11 Mar 2014 13:57:16 +1100
Subject: [Freeipa-users] FW:  SSS for sudoers confusion (Solved)
Message-ID: <2e584ad4037ad1b54f98396eb9cad7cc@mail.gmail.com>

Ok here is the info that finally made it all work

https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html

I seem to have had all the elements in there already so I suspect it was a
statement order issue

Best regards
David Taylor

-----Original Message-----
From: freeipa-users-bounces at redhat.com
[mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal
Sent: Tuesday, 11 March 2014 10:49 AM
To: freeipa-users at redhat.com
Subject: Re: [Freeipa-users] SSS for sudoers confusion

On 03/10/2014 07:34 PM, David Taylor wrote:
> Hi all,
>             I'm in the process of testing IPA server for centralised
> authentication of our linux hosts. We run CentOS 6.5 and it's all new
> so we have no legacy issues.
>
> In the lab I've set up an IPA server with the yum install and used a
> local bind instance which all seems to be working correctly. Where the
> issues begin is with the sudoers functionality. After reading the
> manual and consulting Google sensei I found a number of resources that
> talk about setting up ldap either natively in the nsswitch.conf file
> or via sssd, I've tried a number of slightly different configurations
> on the client side with little effect. So the question is "what is the
> process for configuring an IPA system to handle sudo functionality".
>
> Any help is greatly appreciated.

http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf

>
> ----------------------nssswitch.conf----------------------------------
> ----
> #
> # /etc/nsswitch.conf
> #
> # An example Name Service Switch config file. This file should be #
> sorted with the most-used services at the beginning.
> #
> # The entry '[NOTFOUND=return]' means that the search for an # entry
> should stop if the search in the previous entry turned # up nothing.
> Note that if the search failed due to some other reason # (like no NIS
> server responding) then the search continues with the # next entry.
> #
> # Valid entries include:
> #
> #       nisplus                 Use NIS+ (NIS version 3)
> #       nis                     Use NIS (NIS version 2), also called YP
> #       dns                     Use DNS (Domain Name Service)
> #       files                   Use the local files
> #       db                      Use the local database (.db) files
> #       compat                  Use NIS on compat mode
> #       hesiod                  Use Hesiod for user lookups
> #       [NOTFOUND=return]       Stop searching if not found so far
> #
>
> # To use db, put the "db" in front of "files" for entries you want to
> be # looked up first in the databases # # Example:
> #passwd:    db files nisplus nis
> #shadow:    db files nisplus nis
> #group:     db files nisplus nis
>
> passwd:     files sss
> shadow:     files sss
> group:      files sss
>
> #hosts:     db files nisplus nis dns
> hosts:      files dns
>
> # Example - obey only what nisplus tells us...
> #services:   nisplus [NOTFOUND=return] files
> #networks:   nisplus [NOTFOUND=return] files
> #protocols:  nisplus [NOTFOUND=return] files
> #rpc:        nisplus [NOTFOUND=return] files
> #ethers:     nisplus [NOTFOUND=return] files
> #netmasks:   nisplus [NOTFOUND=return] files
>
> bootparams: nisplus [NOTFOUND=return] files
>
> ethers:     files
> netmasks:   files
> networks:   files
> protocols:  files
> rpc:        files
> services:   files sss
> sudoers:    files sss
> netgroup:   files sss
>
> publickey:  nisplus
>
> automount:  files sss
> aliases:    files nisplus
>
> ----------------------------------------------------------------------
> ----
> -----------------------------
> ---------------
> sssd.conf-------------------------------------------------------------
> ----
> -----------
> [domain/test.example.net]
>
> cache_credentials = True
> krb5_store_password_if_offline = True
> krb5_realm = TEST.EXAMPLE.NET
> krb5_server = ipa-server-1.test.example.net ipa_domain =
> test.example.net id_provider = ipa auth_provider = ipa access_provider
> = ipa ipa_hostname = ipa-server-1.test.example.net chpass_provider =
> ipa ipa_dyndns_update = True ipa_server = _srv_,
> ipa-server-1.test.example.net ldap_tls_cacert = /etc/ipa/ca.crt
> ldap_uri = ldap://ipa-server-1.test.example.net
>
> [sssd]
> services = nss, pam, ssh, sudo
> config_file_version = 2
> sudo_provider = ldap
> ldap_sudo_search_base = ou=sudoers,dc=test,dc=example,dc=net
> ldap_sasl_mech = GSSAPI
> ldap_sasl_authid = host/ipa-client.test.example.net ldap_sasl_realm =
> TEST.EXAMPLE.NET
>
> domains = test.example.net
> [nss]
>
> [pam]
>
> [sudo]
>
> [autofs]
>
> [ssh]
>
> [pac]
> ----------------------------------------------------------------------
> ----
> -------------------------------
>
> Best regards
> David Taylor
>
> David Taylor
> Head of Engineering - SpeedCast Pacific
>
>
>
> Level 1, Unit 4F
> 12 Lord St, Botany
> NSW, Australia, 2019
> Office                      +61 2 9531 7555
> Direct:               +61 2 9086 2787
> Mobile:              +61 4 3131 1146
> 24x7 Helpdesk   +61 2 9016 3222
> Web:                http://www.example.com / www.speedcast.com
>
> To strengthen our corporate identity in target markets worldwide,
> effective 18th January, we have commenced operating under the
> SpeedCast name. Read More
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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 at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



From abokovoy at redhat.com  Tue Mar 11 06:54:04 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Tue, 11 Mar 2014 08:54:04 +0200
Subject: [Freeipa-users] SSS for sudoers confusion
In-Reply-To: <2627e6f4f9584458353d1d405289ae21@mail.gmail.com>
References: <ecb313ccbc842f86b6c9c57f39bcb108@mail.gmail.com>
	<531E4F4F.6080101@redhat.com>
	<2627e6f4f9584458353d1d405289ae21@mail.gmail.com>
Message-ID: <20140311065404.GB16644@redhat.com>

On Tue, 11 Mar 2014, David Taylor wrote:
>@Dmitri - Thank you for your reply, that is actually one of the documents
>I read, however there seem to be some steps missing as with the
>configuration elements in place sudo doesn't work
>
>dtaylor is not allowed to run sudo on ipa-client.  This incident will be
>reported.
>
>There is some note about configuring a password on the ldap user however
>following the suggestions I found didn't actually work.
 From your original email I can see that you put sudo provider
configuration into wrong section in sssd.conf. No wonder it does not
work. Any provider configuration must be in the domain section.

In RHEL 6.5 and before you can do like I describe here:
https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html

In Fedora 20 you don't need to add anything for IPA case because sssd
will set everything up by default for IPA provider.

Did you actually read man page sssd-sudo(5)? It has exact configuration
changes you need to do.

>
>
>Best regards
>David Taylor
>
>
>-----Original Message-----
>From: freeipa-users-bounces at redhat.com
>[mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal
>Sent: Tuesday, 11 March 2014 10:49 AM
>To: freeipa-users at redhat.com
>Subject: Re: [Freeipa-users] SSS for sudoers confusion
>
>On 03/10/2014 07:34 PM, David Taylor wrote:
>> Hi all,
>>             I'm in the process of testing IPA server for centralised
>> authentication of our linux hosts. We run CentOS 6.5 and it's all new
>> so we have no legacy issues.
>>
>> In the lab I've set up an IPA server with the yum install and used a
>> local bind instance which all seems to be working correctly. Where the
>> issues begin is with the sudoers functionality. After reading the
>> manual and consulting Google sensei I found a number of resources that
>> talk about setting up ldap either natively in the nsswitch.conf file
>> or via sssd, I've tried a number of slightly different configurations
>> on the client side with little effect. So the question is "what is the
>> process for configuring an IPA system to handle sudo functionality".
>>
>> Any help is greatly appreciated.
>
>http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
>
>>
>> ----------------------nssswitch.conf----------------------------------
>> ----
>> #
>> # /etc/nsswitch.conf
>> #
>> # An example Name Service Switch config file. This file should be #
>> sorted with the most-used services at the beginning.
>> #
>> # The entry '[NOTFOUND=return]' means that the search for an # entry
>> should stop if the search in the previous entry turned # up nothing.
>> Note that if the search failed due to some other reason # (like no NIS
>> server responding) then the search continues with the # next entry.
>> #
>> # Valid entries include:
>> #
>> #       nisplus                 Use NIS+ (NIS version 3)
>> #       nis                     Use NIS (NIS version 2), also called YP
>> #       dns                     Use DNS (Domain Name Service)
>> #       files                   Use the local files
>> #       db                      Use the local database (.db) files
>> #       compat                  Use NIS on compat mode
>> #       hesiod                  Use Hesiod for user lookups
>> #       [NOTFOUND=return]       Stop searching if not found so far
>> #
>>
>> # To use db, put the "db" in front of "files" for entries you want to
>> be # looked up first in the databases # # Example:
>> #passwd:    db files nisplus nis
>> #shadow:    db files nisplus nis
>> #group:     db files nisplus nis
>>
>> passwd:     files sss
>> shadow:     files sss
>> group:      files sss
>>
>> #hosts:     db files nisplus nis dns
>> hosts:      files dns
>>
>> # Example - obey only what nisplus tells us...
>> #services:   nisplus [NOTFOUND=return] files
>> #networks:   nisplus [NOTFOUND=return] files
>> #protocols:  nisplus [NOTFOUND=return] files
>> #rpc:        nisplus [NOTFOUND=return] files
>> #ethers:     nisplus [NOTFOUND=return] files
>> #netmasks:   nisplus [NOTFOUND=return] files
>>
>> bootparams: nisplus [NOTFOUND=return] files
>>
>> ethers:     files
>> netmasks:   files
>> networks:   files
>> protocols:  files
>> rpc:        files
>> services:   files sss
>> sudoers:    files sss
>> netgroup:   files sss
>>
>> publickey:  nisplus
>>
>> automount:  files sss
>> aliases:    files nisplus
>>
>> ----------------------------------------------------------------------
>> ----
>> -----------------------------
>> ---------------
>> sssd.conf-------------------------------------------------------------
>> ----
>> -----------
>> [domain/test.example.net]
>>
>> cache_credentials = True
>> krb5_store_password_if_offline = True
>> krb5_realm = TEST.EXAMPLE.NET
>> krb5_server = ipa-server-1.test.example.net ipa_domain =
>> test.example.net id_provider = ipa auth_provider = ipa access_provider
>> = ipa ipa_hostname = ipa-server-1.test.example.net chpass_provider =
>> ipa ipa_dyndns_update = True ipa_server = _srv_,
>> ipa-server-1.test.example.net ldap_tls_cacert = /etc/ipa/ca.crt
>> ldap_uri = ldap://ipa-server-1.test.example.net
>>
>> [sssd]
>> services = nss, pam, ssh, sudo
>> config_file_version = 2
>> sudo_provider = ldap
>> ldap_sudo_search_base = ou=sudoers,dc=test,dc=example,dc=net
>> ldap_sasl_mech = GSSAPI
>> ldap_sasl_authid = host/ipa-client.test.example.net ldap_sasl_realm =
>> TEST.EXAMPLE.NET
>>
>> domains = test.example.net
>> [nss]
>>
>> [pam]
>>
>> [sudo]
>>
>> [autofs]
>>
>> [ssh]
>>
>> [pac]
>> ----------------------------------------------------------------------
>> ----
>> -------------------------------
>>
>> Best regards
>> David Taylor
>>
>> David Taylor
>> Head of Engineering - SpeedCast Pacific
>>
>>
>>
>> Level 1, Unit 4F
>> 12 Lord St, Botany
>> NSW, Australia, 2019
>> Office                      +61 2 9531 7555
>> Direct:               +61 2 9086 2787
>> Mobile:              +61 4 3131 1146
>> 24x7 Helpdesk   +61 2 9016 3222
>> Web:                http://www.example.com / www.speedcast.com
>>
>> To strengthen our corporate identity in target markets worldwide,
>> effective 18th January, we have commenced operating under the
>> SpeedCast name. Read More
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at 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 at redhat.com
>https://www.redhat.com/mailman/listinfo/freeipa-users
>
>_______________________________________________
>Freeipa-users mailing list
>Freeipa-users at redhat.com
>https://www.redhat.com/mailman/listinfo/freeipa-users

-- 
/ Alexander Bokovoy



From pspacek at redhat.com  Tue Mar 11 08:48:43 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Tue, 11 Mar 2014 09:48:43 +0100
Subject: [Freeipa-users] install IPA replica multi-hosts (ipa packages
 version 3.3.3-18)
In-Reply-To: <531E0AAB.6040800@redhat.com>
References: <1394198167.5319c6977ca6d@imp.free.fr>	<5319DB9A.2090809@redhat.com>	<1394206154.5319e5ca7b4be@imp.free.fr>	<5319EC61.6020105@redhat.com>
	<531D73AB.3010201@redhat.com>	<1394464565.531dd73570eac@imp.free.fr>
	<531E0AAB.6040800@redhat.com>
Message-ID: <531ECDEB.3040504@redhat.com>

On 10.3.2014 19:55, Dmitri Pal wrote:
> On 03/10/2014 11:16 AM, artjazz at free.fr wrote:
>> Selon Petr Spacek<pspacek at redhat.com>:
>>
>>> On 7.3.2014 16:57, Dmitri Pal wrote:
>>>> On 03/07/2014 10:29 AM, artjazz at free.fr wrote:
>>>>> Selon Petr Spacek<pspacek at redhat.com>:
>>>>>
>>>>>>>   On 7.3.2014 14:16,artjazz at free.fr  wrote:
>>>>>>>>   >   I want to install ipa server with a replica. The replica has 2
>>> NICs
>>>>>>> : the
>>>>>>>   ipa
>>>>>>>>   >   server is connected on the first interface and all the clients are
>>>>>>>   connected on
>>>>>>>>   >   the second interface. The two networks are completely separated, 2
>>>>>>> subnets
>>>>>>>   and
>>>>>>>>   >   not routed.
>>>>>>>   I'm curious - what is the reasoning behind this?:-)
>>>>> The goal is to separate the administration flux and the userland flux.
>>>>>
>>>> The problem is that it is not that clean.
>>>> One server can connect to another on different ports and using different
>>>> protocols for different purposes. And client can actually be a proxy that
>>> does
>>>> some admin tasks via LDAP or executes remote administrative commands.
>>>>
>>>> I think may be it is better to explore FW rules.
>>>> For example create a FW rule that would allow only Kerberos and LDAP
>>>> connections from a set of hosts that would be clients. Hm but that again
>>> would
>>>> prevent you from enrolling new systems since the ipa-client-install
>>> connects
>>>> to IPA via admin interface during the enrollment stage.
>>>>
>>>> May be there is some magic that can be done using DNS zones but I am not
>>> sure...
>>>
>>> Let me summarize this thread to:
>>> Sorry, this is not supported.
>> Thanks for your answer; It's clear for me now, I understand why my different
>> tests didn't work.
>>
>> Just for my information because it's a little bit confusing when I read in the
>> FreeIPA_Guide (Fedora18)  the following sentence:
>> 19.5. Setting DNS Entries for Multi-Homed Servers
>> Some server machines may support multiple network interface cards (NICs).
>> Multi-homed machines typically have multiple IPs, all assigned to the same
>> hostname. This works fine in FreeIPA most of the time because it listens on all
>> available interfaces, except localhost. For a server to be available through
>> any
>> NIC, edit the DNS zone file and add entries for each IP address. For example:
>> ipaserver  IN A  192.168.1.100
>> ipaserver  IN A  192.168.1.101
>> ipaserver  IN A  192.168.1.102
>>
>> What is the architecture of the Multi-Homed Servers in this case ?
>
> What do you mean "architecture" in this context?

The main difference between your setup and the example in docs is that you 
tried to use two different names for one server but the documentation shows an 
example where one name is associated with multiple IP addresses.

Multiple IP addresses for one name are supported as it is very basic 
requirement for IPv4 & IPv6 dual-stack configuration support.

Problems arise when you have multiple names for the same server.

Petr^2 Spacek



From mkosek at redhat.com  Tue Mar 11 09:09:32 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Tue, 11 Mar 2014 10:09:32 +0100
Subject: [Freeipa-users] install with external CA failed
In-Reply-To: <1394482074.32465.26.camel@willson.li.ssimo.org>
References: <20140305234258.1641247f@ispx.vb.futz.org>	<531DCFB1.9040506@redhat.com>	<20140310154518.6cfdebdd@ispx.vb.futz.org>
	<1394482074.32465.26.camel@willson.li.ssimo.org>
Message-ID: <531ED2CC.6000809@redhat.com>

On 03/10/2014 09:07 PM, Simo Sorce wrote:
> On Mon, 2014-03-10 at 15:45 -0400, Robert Story wrote:
>> On Mon, 10 Mar 2014 15:44:01 +0100 Jan wrote:
>> JC> On 6.3.2014 05:42, Robert Story wrote:
>> JC> > I'm trying to install on CentOS 6.5 (ipa-server-3.0.0-37.el6.x86_64)
>> JC> > and an external CA. I'm getting this error:
>> JC> > [snip]
>> JC> Can you please run certutil -V on the issuer certificate
>> JC> (CN=Certificate Authority,O=xxx)? That might give us a clue why it is
>> JC> invalid.
>>
>> Unfortunately I've already scrapped that install and just went with the
>> internal self-signed CA. So far, the only annoyance is that the webserver
>> also presents a self-signed cert for the UI.  Is it safe to replace just
>> the web cert with a cert signed by my local CA? Or might that break
>> something?
> 
> Import the CA cert in your browser.
> 
> Simo.
> 

Yup, in FreeIPA 4.0 even that step should not be needed given the system shared
CA trust storage:
https://fedorahosted.org/freeipa/ticket/3504

As for now, you can add the CA certificate also via convenience wizards in IPA
UI too:

http://vm-236.idm.lab.eng.brq.redhat.com/ipa/config/unauthorized.html

Martin



From p.a.p.de.ruiter at gmail.com  Tue Mar 11 09:32:45 2014
From: p.a.p.de.ruiter at gmail.com (Patrick de Ruiter)
Date: Tue, 11 Mar 2014 10:32:45 +0100
Subject: [Freeipa-users] Red Hat 5 client enrolment fails to Red Hat 6 Server
Message-ID: <CAJnO9qvRJDNcO846_GCmbbm9PzK1PwBGap+kas3krNKb=HLXkQ@mail.gmail.com>

When I want to enroll en new machine the ipa-client-install process bails
out with the error "Failed to retrieve encryption type DES cbc mode with
CRC-32 (#1)" .
The output below is the debug output:

[root at apa01-tst ~]# ipa-client-install -d --domain=example.com --mkhomedir
-w otpass --realm=EXAMPLE.COM  --ntp-server=ns01.example.com   --unattended

root        : DEBUG    /usr/sbin/ipa-client-install was invoked with
options: {'conf_ntp': True, 'domain': 'example.com', 'uninstall': False,
'force': False, 'sssd': True, 'krb5_offline_passwords': True, 'hostname':
None, 'permit': False, 'server': None, 'prompt_password': False,
'mkhomedir': True, 'dns_updates': False, 'preserve_sssd': False, 'debug':
True, 'on_master': False, 'ca_cert_file': None, 'realm_name': 'EXAMPLE.COM',
'unattended': True, 'ntp_server': 'ns01.example.com', 'principal': None}
root        : DEBUG    missing options might be asked for interactively
later

root        : DEBUG    Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
root        : DEBUG    Loading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
root        : DEBUG    [IPA Discovery]
root        : DEBUG    Starting IPA discovery with domain=example.com,
servers=None, hostname=apa01-tst.chn1.oob.example.com
root        : DEBUG    Search for LDAP SRV record in example.com
root        : DEBUG    [ipadnssearchldap]
root        : DEBUG    [ipadnssearchkrb]
root        : DEBUG    [ipacheckldap]
root        : DEBUG    Verifying that auth01.example.com (realm EXAMPLE.COM)
is an IPA server
root        : DEBUG    Init ldap with: ldap://auth01.example.com:389
root        : DEBUG    Search LDAP server for IPA base DN
root        : DEBUG    Check if naming context 'dc=pp,dc=ams' is for IPA
root        : DEBUG    Naming context 'dc=pp,dc=ams' is a valid IPA context
root        : DEBUG    Search for (objectClass=krbRealmContainer) in
dc=pp,dc=ams(sub)
root        : DEBUG    Found: [('cn=EXAMPLE.COM,cn=kerberos,dc=pp,dc=ams',
{'krbSubTrees': ['dc=pp,dc=ams'], 'cn': ['EXAMPLE.COM'],
'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special',
'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top',
'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'],
'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special',
'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal',
'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special'],
'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})]
root        : DEBUG    Discovery result: Success; server=auth01.example.com,
domain=example.com, kdc=auth01.example.com, basedn=dc=pp,dc=ams
root        : DEBUG    Validated servers: auth01.example.com
root        : DEBUG    will use domain: example.com

root        : DEBUG    [ipadnssearchldap(example.com)]
root        : DEBUG    DNS validated, enabling discovery
root        : DEBUG    will use discovered server: auth01.example.com
Discovery was successful!
root        : DEBUG    will use cli_realm: EXAMPLE.COM

root        : DEBUG    will use cli_basedn: dc=pp,dc=ams

Hostname: apa01-tst.chn1.oob.example.com
Realm: EXAMPLE.COM
DNS Domain: example.com
IPA Server: auth01.example.com
BaseDN: dc=pp,dc=ams


Synchronizing time with KDC...
root        : DEBUG    args=/usr/sbin/ntpdate -U ntp -s -b
auth01.example.com
root        : DEBUG    stdout=
root        : DEBUG    stderr=
root        : DEBUG    Writing Kerberos configuration to /tmp/tmpM19nuR:
#File modified by ipa-client-install

[libdefaults]
  default_realm = EXAMPLE.COM
  dns_lookup_realm = false
  dns_lookup_kdc = false
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes

[realms]
  EXAMPLE.COM = {
    kdc = auth01.example.com:88
    master_kdc = auth01.example.com:88
    admin_server = auth01.example.com:749
    default_domain = example.com
    pkinit_anchors = FILE:/etc/ipa/ca.crt
  }

[domain_realm]
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM


root        : INFO     OTP case, CA cert preexisted, use it
root        : DEBUG    args=/usr/sbin/ipa-join -s auth01.example.com -b
dc=pp,dc=ams -d -w XXXXXXXX
root        : DEBUG    stdout=
root        : DEBUG    stderr=request done: ld 0x172d1d10 msgid 1
request done: ld 0x172d1d10 msgid 2
request done: ld 0x172d1d10 msgid 3
Failed to retrieve encryption type DES cbc mode with CRC-32 (#1)
Keytab successfully retrieved and stored in: /etc/krb5.keytab
Certificate subject base is: O=EXAMPLE.COM

Enrolled in IPA realm EXAMPLE.COM
root        : DEBUG    args=/usr/kerberos/bin/kinit -k -t /etc/krb5.keytab
host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM
root        : DEBUG    stdout=
root        : DEBUG    stderr=kinit(v5): Password incorrect while getting
initial credentials

Failed to obtain host TGT.
Installation failed. Rolling back changes.
IPA client is not configured on this system.

Regards,
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140311/ed616328/attachment.htm>

From rcritten at redhat.com  Tue Mar 11 13:00:55 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Tue, 11 Mar 2014 09:00:55 -0400
Subject: [Freeipa-users] Red Hat 5 client enrolment fails to Red Hat 6
 Server
In-Reply-To: <CAJnO9qvRJDNcO846_GCmbbm9PzK1PwBGap+kas3krNKb=HLXkQ@mail.gmail.com>
References: <CAJnO9qvRJDNcO846_GCmbbm9PzK1PwBGap+kas3krNKb=HLXkQ@mail.gmail.com>
Message-ID: <531F0907.5030401@redhat.com>

Patrick de Ruiter wrote:
> When I want to enroll en new machine the ipa-client-install process
> bails out with the error "Failed to retrieve encryption type DES cbc
> mode with CRC-32 (#1)" .
> The output below is the debug output:
>
> [root at apa01-tst ~]# ipa-client-install -d --domain=example.com
> <http://example.com> --mkhomedir -w otpass --realm=EXAMPLE.COM
> <http://EXAMPLE.COM>  --ntp-server=ns01.example.com
> <http://ns01.example.com>   --unattended
> root        : DEBUG    /usr/sbin/ipa-client-install was invoked with
> options: {'conf_ntp': True, 'domain': 'example.com
> <http://example.com>', 'uninstall': False, 'force': False, 'sssd': True,
> 'krb5_offline_passwords': True, 'hostname': None, 'permit': False,
> 'server': None, 'prompt_password': False, 'mkhomedir': True,
> 'dns_updates': False, 'preserve_sssd': False, 'debug': True,
> 'on_master': False, 'ca_cert_file': None, 'realm_name': 'EXAMPLE.COM
> <http://EXAMPLE.COM>', 'unattended': True, 'ntp_server':
> 'ns01.example.com <http://ns01.example.com>', 'principal': None}
> root        : DEBUG    missing options might be asked for interactively
> later
>
> root        : DEBUG    Loading Index file from
> '/var/lib/ipa-client/sysrestore/sysrestore.index'
> root        : DEBUG    Loading StateFile from
> '/var/lib/ipa-client/sysrestore/sysrestore.state'
> root        : DEBUG    [IPA Discovery]
> root        : DEBUG    Starting IPA discovery with domain=example.com
> <http://example.com>, servers=None,
> hostname=apa01-tst.chn1.oob.example.com
> <http://apa01-tst.chn1.oob.example.com>
> root        : DEBUG    Search for LDAP SRV record in example.com
> <http://example.com>
> root        : DEBUG    [ipadnssearchldap]
> root        : DEBUG    [ipadnssearchkrb]
> root        : DEBUG    [ipacheckldap]
> root        : DEBUG    Verifying that auth01.example.com
> <http://auth01.example.com> (realm EXAMPLE.COM <http://EXAMPLE.COM>) is
> an IPA server
> root        : DEBUG    Init ldap with: ldap://auth01.example.com:389
> <http://auth01.example.com:389>
> root        : DEBUG    Search LDAP server for IPA base DN
> root        : DEBUG    Check if naming context 'dc=pp,dc=ams' is for IPA
> root        : DEBUG    Naming context 'dc=pp,dc=ams' is a valid IPA context
> root        : DEBUG    Search for (objectClass=krbRealmContainer) in
> dc=pp,dc=ams(sub)
> root        : DEBUG    Found: [('cn=EXAMPLE.COM
> <http://EXAMPLE.COM>,cn=kerberos,dc=pp,dc=ams', {'krbSubTrees':
> ['dc=pp,dc=ams'], 'cn': ['EXAMPLE.COM <http://EXAMPLE.COM>'],
> 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special',
> 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass':
> ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope':
> ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal',
> 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special',
> 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special',
> 'arcfour-hmac:normal', 'arcfour-hmac:special'], 'krbMaxTicketLife':
> ['86400'], 'krbMaxRenewableAge': ['604800']})]
> root        : DEBUG    Discovery result: Success;
> server=auth01.example.com <http://auth01.example.com>,
> domain=example.com <http://example.com>, kdc=auth01.example.com
> <http://auth01.example.com>, basedn=dc=pp,dc=ams
> root        : DEBUG    Validated servers: auth01.example.com
> <http://auth01.example.com>
> root        : DEBUG    will use domain: example.com <http://example.com>
>
> root        : DEBUG    [ipadnssearchldap(example.com <http://example.com>)]
> root        : DEBUG    DNS validated, enabling discovery
> root        : DEBUG    will use discovered server: auth01.example.com
> <http://auth01.example.com>
> Discovery was successful!
> root        : DEBUG    will use cli_realm: EXAMPLE.COM <http://EXAMPLE.COM>
>
> root        : DEBUG    will use cli_basedn: dc=pp,dc=ams
>
> Hostname: apa01-tst.chn1.oob.example.com
> <http://apa01-tst.chn1.oob.example.com>
> Realm: EXAMPLE.COM <http://EXAMPLE.COM>
> DNS Domain: example.com <http://example.com>
> IPA Server: auth01.example.com <http://auth01.example.com>
> BaseDN: dc=pp,dc=ams
>
>
> Synchronizing time with KDC...
> root        : DEBUG    args=/usr/sbin/ntpdate -U ntp -s -b
> auth01.example.com <http://auth01.example.com>
> root        : DEBUG    stdout=
> root        : DEBUG    stderr=
> root        : DEBUG    Writing Kerberos configuration to /tmp/tmpM19nuR:
> #File modified by ipa-client-install
>
> [libdefaults]
>    default_realm = EXAMPLE.COM <http://EXAMPLE.COM>
>    dns_lookup_realm = false
>    dns_lookup_kdc = false
>    rdns = false
>    ticket_lifetime = 24h
>    forwardable = yes
>
> [realms]
> EXAMPLE.COM <http://EXAMPLE.COM> = {
>      kdc = auth01.example.com:88 <http://auth01.example.com:88>
>      master_kdc = auth01.example.com:88 <http://auth01.example.com:88>
>      admin_server = auth01.example.com:749 <http://auth01.example.com:749>
>      default_domain = example.com <http://example.com>
>      pkinit_anchors = FILE:/etc/ipa/ca.crt
>    }
>
> [domain_realm]
>    .example.com <http://example.com> = EXAMPLE.COM <http://EXAMPLE.COM>
> example.com <http://example.com> = EXAMPLE.COM <http://EXAMPLE.COM>
>
>
> root        : INFO     OTP case, CA cert preexisted, use it
> root        : DEBUG    args=/usr/sbin/ipa-join -s auth01.example.com
> <http://auth01.example.com> -b dc=pp,dc=ams -d -w XXXXXXXX
> root        : DEBUG    stdout=
> root        : DEBUG    stderr=request done: ld 0x172d1d10 msgid 1
> request done: ld 0x172d1d10 msgid 2
> request done: ld 0x172d1d10 msgid 3
> Failed to retrieve encryption type DES cbc mode with CRC-32 (#1)
> Keytab successfully retrieved and stored in: /etc/krb5.keytab
> Certificate subject base is: O=EXAMPLE.COM <http://EXAMPLE.COM>
>
> Enrolled in IPA realm EXAMPLE.COM <http://EXAMPLE.COM>
> root        : DEBUG    args=/usr/kerberos/bin/kinit -k -t
> /etc/krb5.keytab host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM
> <mailto:apa01-tst.chn1.oob.example.com at EXAMPLE.COM>
> root        : DEBUG    stdout=
> root        : DEBUG    stderr=kinit(v5): Password incorrect while
> getting initial credentials
>
> Failed to obtain host TGT.
> Installation failed. Rolling back changes.
> IPA client is not configured on this system.

I don't think this is related to the DES failure, it just means that the 
KDC doesn't issue DES keys (a good thing).

What keys are in the keytab and why errors are logged in the KDC when 
this kinit fails?

What is the rpm version of ipa-client?

rob



From Rashard.Kelly at sita.aero  Tue Mar 11 13:50:23 2014
From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero)
Date: Tue, 11 Mar 2014 09:50:23 -0400
Subject: [Freeipa-users] Joining realm failed: SASL Bind failed Local
	error (-2) (SOLVED)
In-Reply-To: <531DC968.1090303@redhat.com>
References: <OF4B05E951.91821A39-ON85257C95.002482B3-85257C95.00249AF0@sita.aero>
	<531D6CDB.5020009@redhat.com>
	<OF36B7E745.9A0781BB-ON85257C97.004A1E25-85257C97.004DEE57@sita.aero>
	<531DC968.1090303@redhat.com>
Message-ID: <OF3146C78C.CAED9452-ON85257C98.004BEA9A-85257C98.004C0628@sita.aero>

Thanks, after a little digging I found that the reverse DNS records were 
not configured for the masters.

Thank You,
Rashard Kelly




From:   Martin Kosek <mkosek at redhat.com>
To:     Rashard.Kelly at sita.aero
Cc:     freeipa-users at redhat.com
Date:   03/10/2014 10:17 AM
Subject:        Re: [Freeipa-users] Joining realm failed: SASL Bind failed 
Local error (-2)



This service should be needed at all in default installation, did you 
maybe try
to run ipa-client-install with --no-sssd option and do not have 
nss-pam-ldapd
package installed?

Martin

On 03/10/2014 03:11 PM, Rashard.Kelly at sita.aero wrote:
> Thanks for the response Martin. The DNS info is configured the same as 
it 
> is on other clients. I did run the install in debug mode and failed 
at...
> 
> Starting nscd:                                             [  OK  ]
> 
> root        : DEBUG    stderr=
> root        : DEBUG    args=/sbin/chkconfig nscd on
> root        : DEBUG    stdout=
> root        : DEBUG    stderr=
> root        : DEBUG    args=/sbin/service nslcd status
> root        : DEBUG    stdout=
> root        : DEBUG    stderr=nslcd: unrecognized service
> 
> root        : INFO     nslcd daemon is not installed, skip configuration
> 
> what could this mean? Ldap is instslled
> 
> 
> Thank You,
> Rashard Kelly
> 
> 
> This document is strictly confidential and intended only for use by the
> addressee unless otherwise stated.  If you are not the intended 
recipient,
> please notify the sender immediately and delete it from your system.
> 
> 



This document is strictly confidential and intended only for use by the
addressee unless otherwise stated.  If you are not the intended recipient,
please notify the sender immediately and delete it from your system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140311/023c337a/attachment.htm>

From sbose at redhat.com  Tue Mar 11 14:06:34 2014
From: sbose at redhat.com (Sumit Bose)
Date: Tue, 11 Mar 2014 15:06:34 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <531E382C.6000801@gmail.com>
References: <531DDBC3.4060700@gmail.com>
	<20140310155809.GG21499@mail.corp.redhat.com>
	<20140310160301.GH21499@mail.corp.redhat.com>
	<531DE71F.5000907@gmail.com>
	<20140310175733.GN2763@localhost.localdomain>
	<531E0AC7.2090209@gmail.com>
	<20140310193416.GO2763@localhost.localdomain>
	<531E1C19.6020502@gmail.com>
	<20140310210631.GP2763@localhost.localdomain>
	<531E382C.6000801@gmail.com>
Message-ID: <20140311140634.GR2763@localhost.localdomain>

On Mon, Mar 10, 2014 at 11:09:48PM +0100, Jitse Klomp wrote:
> On 10-03-14 22:06, Sumit Bose wrote:
> >Thank you. Maybe there is a change in return codes between MIT Kerberos
> >1.10 (Centos 6) and 1.11 (F20, RHEL7). Can you try to run
> >
> >KRB5_TRACE=/dev/stdout kinit unmigrated_user at DOMAIN.NL
> >
> >on the different platforms and paste the results? I would expect to see
> >[Preauthentication failed] on Centos6 and [Program lacks support for
> >encryption type] on F10 or RHEL7.
> >
> >bye,
> >Sumit
> 
> http://pastebin.centos.org/8336/
> Top one is CentOS, bottom one Fedora. Output on RHEL7 is the same as
> on Fedora.

Thank you for your patience. I was able to reproduce and fix the issue.
Do you want a scratch build for F20 or can you wait for the official
packages?

bye,
Sumit

> 
>  - Jitse
> 
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users



From p.a.p.de.ruiter at gmail.com  Tue Mar 11 15:01:14 2014
From: p.a.p.de.ruiter at gmail.com (Patrick de Ruiter)
Date: Tue, 11 Mar 2014 16:01:14 +0100
Subject: [Freeipa-users] Red Hat 5 client enrolment fails to Red Hat 6
	Server
In-Reply-To: <531F0907.5030401@redhat.com>
References: <CAJnO9qvRJDNcO846_GCmbbm9PzK1PwBGap+kas3krNKb=HLXkQ@mail.gmail.com>
	<531F0907.5030401@redhat.com>
Message-ID: <CAJnO9qtxVGNK+AmWht2S5hwx+peLHtHmhKsQQEOy2cAFS3c0CA@mail.gmail.com>

Hi Rob

Ipa client version is :ipa-client-2.1.3-7.el5

[root at apa01-tst ~]# klist -kte /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- -----------------
--------------------------------------------------------
   2 03/11/14 15:55:02 host/apa01-tst.chn1.oob.pp.ams at PP.AMS (AES-256 CTS
mode with 96-bit SHA-1 HMAC)
   2 03/11/14 15:55:02 host/apa01-tst.chn1.oob.pp.ams at PP.AMS (AES-128 CTS
mode with 96-bit SHA-1 HMAC)
   2 03/11/14 15:55:02 host/apa01-tst.chn1.oob.pp.ams at PP.AMS (Triple DES
cbc mode with HMAC/sha1)
   2 03/11/14 15:55:02 host/apa01-tst.chn1.oob.pp.ams at PP.AMS (ArcFour with
HMAC/md5)


this is what shows up in the logfile krb5kdc.log on the KDC


Mar 11 15:55:02 auth01.example.com krb5kdc[16846](info): AS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: NEEDED_PREAUTH: host/
apa01-tst.chn1.oob.example.com at EXAMPLE.COM for krbtgt/
EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required
Mar 11 15:55:02 auth01.example.com krb5kdc[16847](info): AS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: ISSUE: authtime 1394549702, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM for
krbtgt/EXAMPLE.COM at EXAMPLE.COM
Mar 11 15:55:02 auth01.example.com krb5kdc[16847](info): TGS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: ISSUE: authtime 1394549702, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM for
HTTP/auth01.example.com at EXAMPLE.COM
Mar 11 15:55:02 auth01.example.com krb5kdc[16847](info): TGS_REQ (1 etypes
{18}) 10.63.130.33: ISSUE: authtime 1394549702, etypes {rep=18 tkt=18
ses=18}, host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM for krbtgt/
EXAMPLE.COM at EXAMPLE.COM
Mar 11 15:55:02 auth01.example.com krb5kdc[16847](info): TGS_REQ (1 etypes
{18}) 10.63.130.33: ISSUE: authtime 1394549702, etypes {rep=18 tkt=18
ses=18}, host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM for krbtgt/
EXAMPLE.COM at EXAMPLE.COM
Mar 11 15:55:02 auth01.example.com krb5kdc[16847](info): TGS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.132.21: ISSUE: authtime 1394549702, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM for
ldap/auth01.example.com at EXAMPLE.COM
Mar 11 15:55:03 auth01.example.com krb5kdc[16847](info): AS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: NEEDED_PREAUTH: host/
apa01-tst.chn1.oob.example.com at EXAMPLE.COM for krbtgt/
EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required
Mar 11 15:55:03 auth01.example.com krb5kdc[16846](info): AS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: ISSUE: authtime 1394549703, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM for
krbtgt/EXAMPLE.COM at EXAMPLE.COM
Mar 11 15:55:03 auth01.example.com krb5kdc[16846](info): TGS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: ISSUE: authtime 1394549703, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM for
HTTP/auth01.example.com at EXAMPLE.COM
Mar 11 15:55:03 auth01.example.com krb5kdc[16847](info): TGS_REQ (1 etypes
{18}) 10.63.130.33: ISSUE: authtime 1394549703, etypes {rep=18 tkt=18
ses=18}, host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM for krbtgt/
EXAMPLE.COM at EXAMPLE.COM
Mar 11 15:55:03 auth01.example.com krb5kdc[16846](info): TGS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.132.21: ISSUE: authtime 1394549703, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM for
ldap/auth01.example.com at EXAMPLE.COM
Mar 11 15:55:04 auth01.example.com krb5kdc[16846](info): AS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: NEEDED_PREAUTH: host/
apa01-tst.chn1.oob.example.com at EXAMPLE.COM for krbtgt/
EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required
Mar 11 15:55:04 auth01.example.com krb5kdc[16846](info): AS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: ISSUE: authtime 1394549704, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM for
krbtgt/EXAMPLE.COM at EXAMPLE.COM
Mar 11 15:55:04 auth01.example.com krb5kdc[16846](info): TGS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: ISSUE: authtime 1394549704, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM for
ldap/auth01.example.com at EXAMPLE.COM


Cheers,
Patrick


On Tue, Mar 11, 2014 at 2:00 PM, Rob Crittenden <rcritten at redhat.com> wrote:

> Patrick de Ruiter wrote:
>
>> When I want to enroll en new machine the ipa-client-install process
>> bails out with the error "Failed to retrieve encryption type DES cbc
>> mode with CRC-32 (#1)" .
>> The output below is the debug output:
>>
>> [root at apa01-tst ~]# ipa-client-install -d --domain=example.com
>> <http://example.com> --mkhomedir -w otpass --realm=EXAMPLE.COM
>> <http://EXAMPLE.COM>  --ntp-server=ns01.example.com
>> <http://ns01.example.com>   --unattended
>>
>> root        : DEBUG    /usr/sbin/ipa-client-install was invoked with
>> options: {'conf_ntp': True, 'domain': 'example.com
>> <http://example.com>', 'uninstall': False, 'force': False, 'sssd': True,
>>
>> 'krb5_offline_passwords': True, 'hostname': None, 'permit': False,
>> 'server': None, 'prompt_password': False, 'mkhomedir': True,
>> 'dns_updates': False, 'preserve_sssd': False, 'debug': True,
>> 'on_master': False, 'ca_cert_file': None, 'realm_name': 'EXAMPLE.COM
>> <http://EXAMPLE.COM>', 'unattended': True, 'ntp_server':
>> 'ns01.example.com <http://ns01.example.com>', 'principal': None}
>>
>> root        : DEBUG    missing options might be asked for interactively
>> later
>>
>> root        : DEBUG    Loading Index file from
>> '/var/lib/ipa-client/sysrestore/sysrestore.index'
>> root        : DEBUG    Loading StateFile from
>> '/var/lib/ipa-client/sysrestore/sysrestore.state'
>> root        : DEBUG    [IPA Discovery]
>> root        : DEBUG    Starting IPA discovery with domain=example.com
>> <http://example.com>, servers=None,
>> hostname=apa01-tst.chn1.oob.example.com
>> <http://apa01-tst.chn1.oob.example.com>
>>
>> root        : DEBUG    Search for LDAP SRV record in example.com
>> <http://example.com>
>>
>> root        : DEBUG    [ipadnssearchldap]
>> root        : DEBUG    [ipadnssearchkrb]
>> root        : DEBUG    [ipacheckldap]
>> root        : DEBUG    Verifying that auth01.example.com
>> <http://auth01.example.com> (realm EXAMPLE.COM <http://EXAMPLE.COM>) is
>>
>> an IPA server
>> root        : DEBUG    Init ldap with: ldap://auth01.example.com:389
>> <http://auth01.example.com:389>
>>
>> root        : DEBUG    Search LDAP server for IPA base DN
>> root        : DEBUG    Check if naming context 'dc=pp,dc=ams' is for IPA
>> root        : DEBUG    Naming context 'dc=pp,dc=ams' is a valid IPA
>> context
>> root        : DEBUG    Search for (objectClass=krbRealmContainer) in
>> dc=pp,dc=ams(sub)
>> root        : DEBUG    Found: [('cn=EXAMPLE.COM
>> <http://EXAMPLE.COM>,cn=kerberos,dc=pp,dc=ams', {'krbSubTrees':
>> ['dc=pp,dc=ams'], 'cn': ['EXAMPLE.COM <http://EXAMPLE.COM>'],
>>
>> 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special',
>> 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass':
>> ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope':
>> ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal',
>> 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special',
>> 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special',
>> 'arcfour-hmac:normal', 'arcfour-hmac:special'], 'krbMaxTicketLife':
>> ['86400'], 'krbMaxRenewableAge': ['604800']})]
>> root        : DEBUG    Discovery result: Success;
>> server=auth01.example.com <http://auth01.example.com>,
>> domain=example.com <http://example.com>, kdc=auth01.example.com
>> <http://auth01.example.com>, basedn=dc=pp,dc=ams
>>
>> root        : DEBUG    Validated servers: auth01.example.com
>> <http://auth01.example.com>
>> root        : DEBUG    will use domain: example.com <http://example.com>
>>
>> root        : DEBUG    [ipadnssearchldap(example.com <http://example.com
>> >)]
>>
>> root        : DEBUG    DNS validated, enabling discovery
>> root        : DEBUG    will use discovered server: auth01.example.com
>> <http://auth01.example.com>
>> Discovery was successful!
>> root        : DEBUG    will use cli_realm: EXAMPLE.COM <
>> http://EXAMPLE.COM>
>>
>>
>> root        : DEBUG    will use cli_basedn: dc=pp,dc=ams
>>
>> Hostname: apa01-tst.chn1.oob.example.com
>> <http://apa01-tst.chn1.oob.example.com>
>> Realm: EXAMPLE.COM <http://EXAMPLE.COM>
>> DNS Domain: example.com <http://example.com>
>> IPA Server: auth01.example.com <http://auth01.example.com>
>>
>> BaseDN: dc=pp,dc=ams
>>
>>
>> Synchronizing time with KDC...
>> root        : DEBUG    args=/usr/sbin/ntpdate -U ntp -s -b
>> auth01.example.com <http://auth01.example.com>
>>
>> root        : DEBUG    stdout=
>> root        : DEBUG    stderr=
>> root        : DEBUG    Writing Kerberos configuration to /tmp/tmpM19nuR:
>> #File modified by ipa-client-install
>>
>> [libdefaults]
>>    default_realm = EXAMPLE.COM <http://EXAMPLE.COM>
>>
>>    dns_lookup_realm = false
>>    dns_lookup_kdc = false
>>    rdns = false
>>    ticket_lifetime = 24h
>>    forwardable = yes
>>
>> [realms]
>> EXAMPLE.COM <http://EXAMPLE.COM> = {
>>      kdc = auth01.example.com:88 <http://auth01.example.com:88>
>>      master_kdc = auth01.example.com:88 <http://auth01.example.com:88>
>>      admin_server = auth01.example.com:749 <http://auth01.example.com:749
>> >
>>      default_domain = example.com <http://example.com>
>>
>>      pkinit_anchors = FILE:/etc/ipa/ca.crt
>>    }
>>
>> [domain_realm]
>>    .example.com <http://example.com> = EXAMPLE.COM <http://EXAMPLE.COM>
>> example.com <http://example.com> = EXAMPLE.COM <http://EXAMPLE.COM>
>>
>>
>>
>> root        : INFO     OTP case, CA cert preexisted, use it
>> root        : DEBUG    args=/usr/sbin/ipa-join -s auth01.example.com
>> <http://auth01.example.com> -b dc=pp,dc=ams -d -w XXXXXXXX
>>
>> root        : DEBUG    stdout=
>> root        : DEBUG    stderr=request done: ld 0x172d1d10 msgid 1
>> request done: ld 0x172d1d10 msgid 2
>> request done: ld 0x172d1d10 msgid 3
>> Failed to retrieve encryption type DES cbc mode with CRC-32 (#1)
>> Keytab successfully retrieved and stored in: /etc/krb5.keytab
>> Certificate subject base is: O=EXAMPLE.COM <http://EXAMPLE.COM>
>>
>> Enrolled in IPA realm EXAMPLE.COM <http://EXAMPLE.COM>
>>
>> root        : DEBUG    args=/usr/kerberos/bin/kinit -k -t
>> /etc/krb5.keytab host/apa01-tst.chn1.oob.example.com at EXAMPLE.COM
>> <mailto:apa01-tst.chn1.oob.example.com at EXAMPLE.COM>
>>
>> root        : DEBUG    stdout=
>> root        : DEBUG    stderr=kinit(v5): Password incorrect while
>> getting initial credentials
>>
>> Failed to obtain host TGT.
>> Installation failed. Rolling back changes.
>> IPA client is not configured on this system.
>>
>
> I don't think this is related to the DES failure, it just means that the
> KDC doesn't issue DES keys (a good thing).
>
> What keys are in the keytab and why errors are logged in the KDC when this
> kinit fails?
>
> What is the rpm version of ipa-client?
>
> rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140311/68fe1f06/attachment.htm>

From jitseklomp at gmail.com  Tue Mar 11 15:15:57 2014
From: jitseklomp at gmail.com (Jitse Klomp)
Date: Tue, 11 Mar 2014 16:15:57 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <20140311140634.GR2763@localhost.localdomain>
References: <531DDBC3.4060700@gmail.com>	<20140310155809.GG21499@mail.corp.redhat.com>	<20140310160301.GH21499@mail.corp.redhat.com>	<531DE71F.5000907@gmail.com>	<20140310175733.GN2763@localhost.localdomain>	<531E0AC7.2090209@gmail.com>	<20140310193416.GO2763@localhost.localdomain>	<531E1C19.6020502@gmail.com>	<20140310210631.GP2763@localhost.localdomain>	<531E382C.6000801@gmail.com>
	<20140311140634.GR2763@localhost.localdomain>
Message-ID: <531F28AD.60005@gmail.com>

On 03/11/2014 03:06 PM, Sumit Bose wrote:
> On Mon, Mar 10, 2014 at 11:09:48PM +0100, Jitse Klomp wrote:
>> On 10-03-14 22:06, Sumit Bose wrote:
>>> Thank you. Maybe there is a change in return codes between MIT Kerberos
>>> 1.10 (Centos 6) and 1.11 (F20, RHEL7). Can you try to run
>>>
>>> KRB5_TRACE=/dev/stdout kinit unmigrated_user at DOMAIN.NL
>>>
>>> on the different platforms and paste the results? I would expect to see
>>> [Preauthentication failed] on Centos6 and [Program lacks support for
>>> encryption type] on F10 or RHEL7.
>>>
>>> bye,
>>> Sumit
>>
>> http://pastebin.centos.org/8336/
>> Top one is CentOS, bottom one Fedora. Output on RHEL7 is the same as
>> on Fedora.
>
> Thank you for your patience. I was able to reproduce and fix the issue.
> Do you want a scratch build for F20 or can you wait for the official
> packages?
>
> bye,
> Sumit

Great! Thanks! Do you know how long it will take for the fix to land in 
the official packages?

  - Jitse



From rstory at tislabs.com  Tue Mar 11 16:44:24 2014
From: rstory at tislabs.com (Robert Story)
Date: Tue, 11 Mar 2014 12:44:24 -0400
Subject: [Freeipa-users] install with external CA failed
In-Reply-To: <1394482074.32465.26.camel@willson.li.ssimo.org>
References: <20140305234258.1641247f@ispx.vb.futz.org>
	<531DCFB1.9040506@redhat.com>
	<20140310154518.6cfdebdd@ispx.vb.futz.org>
	<1394482074.32465.26.camel@willson.li.ssimo.org>
Message-ID: <20140311124424.371a82f5@ispx.vb.futz.org>

On Mon, 10 Mar 2014 16:07:54 -0400 Simo wrote:
SS> > Unfortunately I've already scrapped that install and just went with
SS> > the internal self-signed CA. So far, the only annoyance is that the
SS> > webserver also presents a self-signed cert for the UI.  Is it safe to
SS> > replace just the web cert with a cert signed by my local CA? Or might
SS> > that break something?
SS> 
SS> Import the CA cert in your browser.

This is exactly what I'm trying to avoid. Users already have to install our
corporate CA cert, and I'd like to avoid having to install two. I'm hoping
that the cert for the UI could be swapped for one signed by our existing CA.


Robert

--
Senior Software Engineer @ Parsons
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140311/30bb4003/attachment.sig>

From dpal at redhat.com  Tue Mar 11 20:38:08 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Tue, 11 Mar 2014 16:38:08 -0400
Subject: [Freeipa-users] install with external CA failed
In-Reply-To: <20140311124424.371a82f5@ispx.vb.futz.org>
References: <20140305234258.1641247f@ispx.vb.futz.org>
	<531DCFB1.9040506@redhat.com>
	<20140310154518.6cfdebdd@ispx.vb.futz.org>
	<1394482074.32465.26.camel@willson.li.ssimo.org>
	<20140311124424.371a82f5@ispx.vb.futz.org>
Message-ID: <531F7430.90404@redhat.com>

On 03/11/2014 12:44 PM, Robert Story wrote:
> On Mon, 10 Mar 2014 16:07:54 -0400 Simo wrote:
> SS>  >  Unfortunately I've already scrapped that install and just went with
> SS>  >  the internal self-signed CA. So far, the only annoyance is that the
> SS>  >  webserver also presents a self-signed cert for the UI.  Is it safe to
> SS>  >  replace just the web cert with a cert signed by my local CA? Or might
> SS>  >  that break something?
> SS>
> SS>  Import the CA cert in your browser.
>
> This is exactly what I'm trying to avoid. Users already have to install our
> corporate CA cert, and I'd like to avoid having to install two. I'm hoping
> that the cert for the UI could be swapped for one signed by our existing CA.
>
>
> Robert
>
> --
> Senior Software Engineer @ Parsons
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


There are several options:

a) Resolve the issue with CA chaining. It might be due to some data 
missing in the cert issued by your corporate CA when you tried to chain 
things. We can drill down into that.
b) You can use the feature available in IPA 3.3 to use CA-less install. 
It will be in CentOS 7. In this case you can install IPA without any CA 
and just use you corporate CA. The down side is that all cert related 
operations of IPA will be disabled.
c) Import the cert into the browser or the common certs store. I vaguely 
remember that this change might have been ported to 6.5 but I am not 
sure from top of my head.

Thanks
Dmitri

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140311/7ae4bbb8/attachment.htm>

From Rashard.Kelly at sita.aero  Wed Mar 12 15:47:40 2014
From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero)
Date: Wed, 12 Mar 2014 11:47:40 -0400
Subject: [Freeipa-users] Sudo Rule Command Line Option Arguments
Message-ID: <OF79190430.8B641110-ON85257C99.0056262F-85257C99.0056C2ED@sita.aero>

What is the correct way to add a flag inside a sudo command that will be 
added to a command group? When adding commands with no flags I have no 
issue such as "/usr/bin/yum info example*" but when I try to add options 
to the command like this "/usr/bin/yum --disableexcludes=all localinstall 
example*", It does not work even when escaping items like --. How does IPA 
handle a request like that?
 
ipa-client-3.0.0-37.el6.x86_64

[rkelly at hostname /]$ ipa sudocmdgroup-add-member --sudocmds "/usr/bin/yum 
--disableexcludes=all localinstall example*" yumsita
  Sudo Command Group: yumexample
  Description: Yum install Priviledges for example.com specific packages
  Member Sudo commands: /usr/bin/yum info example*, /usr/bin/yum update 
example*,
                        /usr/bin/yum remove example*, /usr/bin/yum install
                        example*, /usr/bin/yum localinstall example*, 
/usr/bin/yum
                        localupdate example*
  Failed members:
    member sudo command: /usr/bin/yum --disableexcludes=all localinstall 
example*: no such entry
-------------------------
Number of members added 0
-------------------------


Thank You,
Rashard Kelly

This document is strictly confidential and intended only for use by the
addressee unless otherwise stated.  If you are not the intended recipient,
please notify the sender immediately and delete it from your system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140312/baf4f9e3/attachment.htm>

From tmaugh at boingo.com  Wed Mar 12 21:10:27 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Wed, 12 Mar 2014 21:10:27 +0000
Subject: [Freeipa-users] How to remove the CA cert from an IDM replica
Message-ID: <6FB698E172A95F49BE009B36D56F53E22962A0@EXCHMB1-ELS.BWINC.local>

I need to remove the CA certs on a box from a previous IDM install

what is the command to do this

error im getting is

A CA is already configured on this system.


Thanks

-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140312/fbea07fc/attachment.htm>

From dpal at redhat.com  Wed Mar 12 21:16:55 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Wed, 12 Mar 2014 17:16:55 -0400
Subject: [Freeipa-users] How to remove the CA cert from an IDM replica
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E22962A0@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E22962A0@EXCHMB1-ELS.BWINC.local>
Message-ID: <5320CEC7.70101@redhat.com>

On 03/12/2014 05:10 PM, Todd Maugh wrote:
> I need to remove the CA certs on a box from a previous IDM install
>
> what is the command to do this
>
> error im getting is
>
> A CA is already configured on this system.
>
>

Which OS and which version?

> Thanks
>
> -Todd
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140312/4e4fa70c/attachment.htm>

From tmaugh at boingo.com  Wed Mar 12 21:18:37 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Wed, 12 Mar 2014 21:18:37 +0000
Subject: [Freeipa-users] How to remove the CA cert from an IDM replica
In-Reply-To: <5320CEC7.70101@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E22962A0@EXCHMB1-ELS.BWINC.local>,
	<5320CEC7.70101@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E22962D2@EXCHMB1-ELS.BWINC.local>

Red Hat 6.5

latest Ipa from yum



________________________________
From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com]
Sent: Wednesday, March 12, 2014 2:16 PM
To: freeipa-users at redhat.com
Subject: Re: [Freeipa-users] How to remove the CA cert from an IDM replica

On 03/12/2014 05:10 PM, Todd Maugh wrote:
I need to remove the CA certs on a box from a previous IDM install

what is the command to do this

error im getting is

A CA is already configured on this system.



Which OS and which version?

Thanks

-Todd



_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at 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/<http://www.redhat.com/carveoutcosts/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140312/3d1f506f/attachment.htm>

From simo at redhat.com  Wed Mar 12 21:23:39 2014
From: simo at redhat.com (Simo Sorce)
Date: Wed, 12 Mar 2014 17:23:39 -0400
Subject: [Freeipa-users] How to remove the CA cert from an IDM replica
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E22962A0@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E22962A0@EXCHMB1-ELS.BWINC.local>
Message-ID: <1394659419.32465.204.camel@willson.li.ssimo.org>

On Wed, 2014-03-12 at 21:10 +0000, Todd Maugh wrote:
> I need to remove the CA certs on a box from a previous IDM install
> 
> what is the command to do this
> 
> error im getting is
> 
> A CA is already configured on this system.

rm /etc/ipa/ca.crt

Simo.

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



From tmaugh at boingo.com  Wed Mar 12 21:28:39 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Wed, 12 Mar 2014 21:28:39 +0000
Subject: [Freeipa-users] How to remove the CA cert from an IDM replica
In-Reply-To: <1394659419.32465.204.camel@willson.li.ssimo.org>
References: <6FB698E172A95F49BE009B36D56F53E22962A0@EXCHMB1-ELS.BWINC.local>,
	<1394659419.32465.204.camel@willson.li.ssimo.org>
Message-ID: <6FB698E172A95F49BE009B36D56F53E229638B@EXCHMB1-ELS.BWINC.local>

but dont I have to remove it from the cert DB?
________________________________________
From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Simo Sorce [simo at redhat.com]
Sent: Wednesday, March 12, 2014 2:23 PM
To: freeipa-users at redhat.com
Subject: Re: [Freeipa-users] How to remove the CA cert from an IDM replica

On Wed, 2014-03-12 at 21:10 +0000, Todd Maugh wrote:
> I need to remove the CA certs on a box from a previous IDM install
>
> what is the command to do this
>
> error im getting is
>
> A CA is already configured on this system.

rm /etc/ipa/ca.crt

Simo.

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

_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



From tmaugh at boingo.com  Wed Mar 12 21:29:38 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Wed, 12 Mar 2014 21:29:38 +0000
Subject: [Freeipa-users] How to remove the CA cert from an IDM replica
In-Reply-To: <1394659419.32465.204.camel@willson.li.ssimo.org>
References: <6FB698E172A95F49BE009B36D56F53E22962A0@EXCHMB1-ELS.BWINC.local>,
	<1394659419.32465.204.camel@willson.li.ssimo.org>
Message-ID: <6FB698E172A95F49BE009B36D56F53E229639F@EXCHMB1-ELS.BWINC.local>

Im seeing this error:

where is the install log located

[root at idm-rep02-w1c-aws ipa]# ipa-replica-install --setup-ca /var/lib/ipa/replica-info-idm-rep02-w1c-aws.ops.boingo.com.gpg --skip-conncheck
Directory Manager (existing master) password: 

Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
A CA is already configured on this system.
[root at idm-rep02-w1c-aws ipa]# ipa-replica-install  /var/lib/ipa/replica-info-idm-rep02-w1c-aws.ops.boingo.com.gpg --skip-conncheck
Directory Manager (existing master) password: 

Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
  [1/31]: creating directory server user
  [2/31]: creating directory server instance
  [3/31]: adding default schema
  [4/31]: enabling memberof plugin
  [5/31]: enabling winsync plugin
  [6/31]: configuring replication version plugin
  [7/31]: enabling IPA enrollment plugin
  [8/31]: enabling ldapi
  [9/31]: disabling betxn plugins
  [10/31]: configuring uniqueness plugin
  [11/31]: configuring uuid plugin
  [12/31]: configuring modrdn plugin
  [13/31]: enabling entryUSN plugin
  [14/31]: configuring lockout plugin
  [15/31]: creating indices
  [16/31]: enabling referential integrity plugin
  [17/31]: configuring ssl for ds instance
  [18/31]: configuring certmap.conf
  [19/31]: configure autobind for root
  [20/31]: configure new location for managed entries
  [21/31]: restarting directory server
  [22/31]: setting up initial replication
Starting replication, please wait until this has completed.
[idm-master-els.ops.boingo.com] reports: Update failed! Status: [-1  - LDAP error: Can't contact LDAP server]

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.


________________________________________
From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Simo Sorce [simo at redhat.com]
Sent: Wednesday, March 12, 2014 2:23 PM
To: freeipa-users at redhat.com
Subject: Re: [Freeipa-users] How to remove the CA cert from an IDM replica

On Wed, 2014-03-12 at 21:10 +0000, Todd Maugh wrote:
> I need to remove the CA certs on a box from a previous IDM install
>
> what is the command to do this
>
> error im getting is
>
> A CA is already configured on this system.

rm /etc/ipa/ca.crt

Simo.

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

_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



From rcritten at redhat.com  Wed Mar 12 21:39:19 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Wed, 12 Mar 2014 17:39:19 -0400
Subject: [Freeipa-users] How to remove the CA cert from an IDM replica
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229639F@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E22962A0@EXCHMB1-ELS.BWINC.local>,
	<1394659419.32465.204.camel@willson.li.ssimo.org>
	<6FB698E172A95F49BE009B36D56F53E229639F@EXCHMB1-ELS.BWINC.local>
Message-ID: <5320D407.7010206@redhat.com>

Todd Maugh wrote:
> Im seeing this error:
>
> where is the install log located
>
> [root at idm-rep02-w1c-aws ipa]# ipa-replica-install --setup-ca /var/lib/ipa/replica-info-idm-rep02-w1c-aws.ops.boingo.com.gpg --skip-conncheck
> Directory Manager (existing master) password:
>
> Configuring NTP daemon (ntpd)
>    [1/4]: stopping ntpd
>    [2/4]: writing configuration
>    [3/4]: configuring ntpd to start on boot
>    [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> A CA is already configured on this system.

# /usr/bin/pkiremove -pki_instance_root=/var/lib 
-pki_instance_name=pki-ca --force

> [root at idm-rep02-w1c-aws ipa]# ipa-replica-install  /var/lib/ipa/replica-info-idm-rep02-w1c-aws.ops.boingo.com.gpg --skip-conncheck
> Directory Manager (existing master) password:
>
> Configuring NTP daemon (ntpd)
>    [1/4]: stopping ntpd
>    [2/4]: writing configuration
>    [3/4]: configuring ntpd to start on boot
>    [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> Configuring directory server (dirsrv): Estimated time 1 minute
>    [1/31]: creating directory server user
>    [2/31]: creating directory server instance
>    [3/31]: adding default schema
>    [4/31]: enabling memberof plugin
>    [5/31]: enabling winsync plugin
>    [6/31]: configuring replication version plugin
>    [7/31]: enabling IPA enrollment plugin
>    [8/31]: enabling ldapi
>    [9/31]: disabling betxn plugins
>    [10/31]: configuring uniqueness plugin
>    [11/31]: configuring uuid plugin
>    [12/31]: configuring modrdn plugin
>    [13/31]: enabling entryUSN plugin
>    [14/31]: configuring lockout plugin
>    [15/31]: creating indices
>    [16/31]: enabling referential integrity plugin
>    [17/31]: configuring ssl for ds instance
>    [18/31]: configuring certmap.conf
>    [19/31]: configure autobind for root
>    [20/31]: configure new location for managed entries
>    [21/31]: restarting directory server
>    [22/31]: setting up initial replication
> Starting replication, please wait until this has completed.
> [idm-master-els.ops.boingo.com] reports: Update failed! Status: [-1  - LDAP error: Can't contact LDAP server]

Why are you skipping the conncheck? It looks like there is a firewall issue.

rob



From robert.roche at xerox.com  Wed Mar 12 21:52:57 2014
From: robert.roche at xerox.com (Rob)
Date: Wed, 12 Mar 2014 21:52:57 +0000 (UTC)
Subject: [Freeipa-users] AIX kerberos client to IPA
Message-ID: <loom.20140312T224425-846@post.gmane.org>


Hi,

I have configured an AIX 6.1 server to connect to a RHEL 6.5 IPA server. The 
AIX server is configured to use netgroups and all that works for existing the 
users.

The problem is when a users password expires or when a new user is created. 
They cannot change their password

WARNING: Your password has expired.
You must change your password now and login again!
Changing password for "testuser"
testuser's Old password:
testuser's New password:
Connection to localhost closed.

The problem seems to be related to not getting a kerberos ticket as kinit can 
be used to change the password.

Logging is enabled but no logs ever get updated

[logging]
        kdc = FILE:/var/krb5/log/krb5kdc.log
        admin_server = FILE:/var/krb5/log/kadmin.log
        kadmin_local = FILE:/var/krb5/log/kadmin_local.log
        default = FILE:/var/krb5/log/krb5lib.log

Anybody ever come across this? Or know how to get logging working?



From tmaugh at boingo.com  Wed Mar 12 22:03:52 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Wed, 12 Mar 2014 22:03:52 +0000
Subject: [Freeipa-users] How to remove the CA cert from an IDM replica
In-Reply-To: <5320D407.7010206@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E22962A0@EXCHMB1-ELS.BWINC.local>, 
	<1394659419.32465.204.camel@willson.li.ssimo.org>
	<6FB698E172A95F49BE009B36D56F53E229639F@EXCHMB1-ELS.BWINC.local>,
	<5320D407.7010206@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E229644B@EXCHMB1-ELS.BWINC.local>

skipping the con check due to a clock skew error
________________________________________
From: Rob Crittenden [rcritten at redhat.com]
Sent: Wednesday, March 12, 2014 2:39 PM
To: Todd Maugh; Simo Sorce; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] How to remove the CA cert from an IDM replica

Todd Maugh wrote:
> Im seeing this error:
>
> where is the install log located
>
> [root at idm-rep02-w1c-aws ipa]# ipa-replica-install --setup-ca /var/lib/ipa/replica-info-idm-rep02-w1c-aws.ops.boingo.com.gpg --skip-conncheck
> Directory Manager (existing master) password:
>
> Configuring NTP daemon (ntpd)
>    [1/4]: stopping ntpd
>    [2/4]: writing configuration
>    [3/4]: configuring ntpd to start on boot
>    [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> A CA is already configured on this system.

# /usr/bin/pkiremove -pki_instance_root=/var/lib
-pki_instance_name=pki-ca --force

> [root at idm-rep02-w1c-aws ipa]# ipa-replica-install  /var/lib/ipa/replica-info-idm-rep02-w1c-aws.ops.boingo.com.gpg --skip-conncheck
> Directory Manager (existing master) password:
>
> Configuring NTP daemon (ntpd)
>    [1/4]: stopping ntpd
>    [2/4]: writing configuration
>    [3/4]: configuring ntpd to start on boot
>    [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> Configuring directory server (dirsrv): Estimated time 1 minute
>    [1/31]: creating directory server user
>    [2/31]: creating directory server instance
>    [3/31]: adding default schema
>    [4/31]: enabling memberof plugin
>    [5/31]: enabling winsync plugin
>    [6/31]: configuring replication version plugin
>    [7/31]: enabling IPA enrollment plugin
>    [8/31]: enabling ldapi
>    [9/31]: disabling betxn plugins
>    [10/31]: configuring uniqueness plugin
>    [11/31]: configuring uuid plugin
>    [12/31]: configuring modrdn plugin
>    [13/31]: enabling entryUSN plugin
>    [14/31]: configuring lockout plugin
>    [15/31]: creating indices
>    [16/31]: enabling referential integrity plugin
>    [17/31]: configuring ssl for ds instance
>    [18/31]: configuring certmap.conf
>    [19/31]: configure autobind for root
>    [20/31]: configure new location for managed entries
>    [21/31]: restarting directory server
>    [22/31]: setting up initial replication
> Starting replication, please wait until this has completed.
> [idm-master-els.ops.boingo.com] reports: Update failed! Status: [-1  - LDAP error: Can't contact LDAP server]

Why are you skipping the conncheck? It looks like there is a firewall issue.

rob




From tmaugh at boingo.com  Wed Mar 12 22:18:46 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Wed, 12 Mar 2014 22:18:46 +0000
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
Message-ID: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>

Hello.

I'm using latest IPA build on red hat 6.5

I retrieved my CA cert from the AD Domain controller

I try to set up my winsyncagreement and I am getting this



[root at idm-master-els.ops.boingo.com ipa]$ ipa-replica-manage connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to certificate database for idm-master-els.ops.boingo.com
ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 'Invalid credentials'}
Failed to setup winsync replication


not sure where to look for the logs for this to see what the invalivd credentials are or wether this might still be a cert issue or a log in issue or what not?


Thanks in advance for the help

-Todd


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140312/232169c0/attachment.htm>

From rmeggins at redhat.com  Wed Mar 12 22:30:28 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Wed, 12 Mar 2014 16:30:28 -0600
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>
Message-ID: <5320E004.4030903@redhat.com>

On 03/12/2014 04:18 PM, Todd Maugh wrote:
> Hello.
>
> I'm using latest IPA build on red hat 6.5
>
> I retrieved my CA cert from the AD Domain controller
>
> I try to set up my winsyncagreement and I am getting this
>
>
>
> [root at idm-master-els.ops.boingo.com ipa]$ ipa-replica-manage connect 
> --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" 
> --bindpw "XXXXXX" --passsync "XXXXXX" 
> --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
> Directory Manager password:
>
> Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to 
> certificate database for idm-master-els.ops.boingo.com
> ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
> ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, 
> comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 
> 'Invalid credentials'}
> Failed to setup winsync replication
>
>
> not sure where to look for the logs for this to see what the invalivd 
> credentials are or wether this might still be a cert issue or a log in 
> issue or what not?

You can test with ldapsearch like this:

$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h 
adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w 
"XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"

>
>
> Thanks in advance for the help
>
> -Todd
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140312/05dfcbb8/attachment.htm>

From tmaugh at boingo.com  Wed Mar 12 22:39:19 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Wed, 12 Mar 2014 22:39:19 +0000
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <5320E004.4030903@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>

thanks Rich,

when I run that  I get the following:


[root at idm-master-els.ops.boingo.com ipa]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
ldap_bind: Invalid credentials (49)
    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580



________________________________
From: Rich Megginson [rmeggins at redhat.com]
Sent: Wednesday, March 12, 2014 3:30 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:18 PM, Todd Maugh wrote:
Hello.

I'm using latest IPA build on red hat 6.5

I retrieved my CA cert from the AD Domain controller

I try to set up my winsyncagreement and I am getting this



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ ipa-replica-manage connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to certificate database for idm-master-els.ops.boingo.com
ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 'Invalid credentials'}
Failed to setup winsync replication


not sure where to look for the logs for this to see what the invalivd credentials are or wether this might still be a cert issue or a log in issue or what not?

You can test with ldapsearch like this:

$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"



Thanks in advance for the help

-Todd





_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140312/29e5bb04/attachment.htm>

From sakodak at gmail.com  Wed Mar 12 22:43:46 2014
From: sakodak at gmail.com (KodaK)
Date: Wed, 12 Mar 2014 17:43:46 -0500
Subject: [Freeipa-users] AIX kerberos client to IPA
In-Reply-To: <loom.20140312T224425-846@post.gmane.org>
References: <loom.20140312T224425-846@post.gmane.org>
Message-ID: <CAA9J0ZF8EUEAB1ncL7F506xrLfBwLCXk3o5PZwrg4B92iwNXgQ@mail.gmail.com>

I had this issue, but I gave up.  I have my users either log into a Linux
box to change passwords or use a web based password reset I set up for them.

When your users log in successfully do they have tickets?  That's my
situation: they can get tickets once they're logged in, but can't change
when prompted at login, nor can they change interactively using passwd.

If you ever figure anything out let me know, but I spent quite a bit of
time on it (once I had the workaround I stopped, though.  You may be more
persistent.)

Good luck,

--Jason


On Wed, Mar 12, 2014 at 4:52 PM, Rob <robert.roche at xerox.com> wrote:

>
> Hi,
>
> I have configured an AIX 6.1 server to connect to a RHEL 6.5 IPA server.
> The
> AIX server is configured to use netgroups and all that works for existing
> the
> users.
>
> The problem is when a users password expires or when a new user is created.
> They cannot change their password
>
> WARNING: Your password has expired.
> You must change your password now and login again!
> Changing password for "testuser"
> testuser's Old password:
> testuser's New password:
> Connection to localhost closed.
>
> The problem seems to be related to not getting a kerberos ticket as kinit
> can
> be used to change the password.
>
> Logging is enabled but no logs ever get updated
>
> [logging]
>         kdc = FILE:/var/krb5/log/krb5kdc.log
>         admin_server = FILE:/var/krb5/log/kadmin.log
>         kadmin_local = FILE:/var/krb5/log/kadmin_local.log
>         default = FILE:/var/krb5/log/krb5lib.log
>
> Anybody ever come across this? Or know how to get logging working?
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>



-- 
The government is going to read our mail anyway, might as well make it
tough for them.  GPG Public key ID:  B6A1A7C6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140312/43d80ef7/attachment.htm>

From rmeggins at redhat.com  Wed Mar 12 22:47:42 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Wed, 12 Mar 2014 16:47:42 -0600
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>
Message-ID: <5320E40E.4030604@redhat.com>

On 03/12/2014 04:39 PM, Todd Maugh wrote:
> thanks Rich,
>
> when I run that  I get the following:
>
>
> *[root at idm-master-els.ops.boingo.com ipa]$ 
> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ 
> -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" 
> -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
> ldap_bind: Invalid credentials (49)
> *

*Invalid credentials almost always means your password "XXXXXX" is not 
correct for user "**cn=idmadmin,cn=Users,dc=bwinc,dc=local"

*
> *    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: 
> AcceptSecurityContext error, data 52e, v2580
> *
>
>
> ------------------------------------------------------------------------
> *From:* Rich Megginson [rmeggins at redhat.com]
> *Sent:* Wednesday, March 12, 2014 3:30 PM
> *To:* Todd Maugh; freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>
> On 03/12/2014 04:18 PM, Todd Maugh wrote:
>> Hello.
>>
>> I'm using latest IPA build on red hat 6.5
>>
>> I retrieved my CA cert from the AD Domain controller
>>
>> I try to set up my winsyncagreement and I am getting this
>>
>>
>>
>> [root at idm-master-els.ops.boingo.com ipa]$ ipa-replica-manage connect 
>> --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" 
>> --bindpw "XXXXXX" --passsync "XXXXXX" 
>> --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
>> Directory Manager password:
>>
>> Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to 
>> certificate database for idm-master-els.ops.boingo.com
>> ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
>> ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, 
>> comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 
>> 'Invalid credentials'}
>> Failed to setup winsync replication
>>
>>
>> not sure where to look for the logs for this to see what the invalivd 
>> credentials are or wether this might still be a cert issue or a log 
>> in issue or what not?
>
> You can test with ldapsearch like this:
>
> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h 
> adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w 
> "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"
>
>>
>>
>> Thanks in advance for the help
>>
>> -Todd
>>
>>
>>
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140312/551cb3be/attachment.htm>

From tmaugh at boingo.com  Wed Mar 12 23:07:11 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Wed, 12 Mar 2014 23:07:11 +0000
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <5320E40E.4030604@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E22965ED@EXCHMB1-ELS.BWINC.local>

so to verify this

I am able to log in to the AD server as idmadmin with the password I'm using in the winsync agreement.

is there a log I can  look at to see what it is getting tripped up on.

I double checked all the security groups  for the AD user and they all look good


________________________________
From: Rich Megginson [rmeggins at redhat.com]
Sent: Wednesday, March 12, 2014 3:47 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:39 PM, Todd Maugh wrote:
thanks Rich,

when I run that  I get the following:


[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
ldap_bind: Invalid credentials (49)

Invalid credentials almost always means your password "XXXXXX" is not correct for user "cn=idmadmin,cn=Users,dc=bwinc,dc=local"

    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580



________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:30 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:18 PM, Todd Maugh wrote:
Hello.

I'm using latest IPA build on red hat 6.5

I retrieved my CA cert from the AD Domain controller

I try to set up my winsyncagreement and I am getting this



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ ipa-replica-manage connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to certificate database for idm-master-els.ops.boingo.com
ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 'Invalid credentials'}
Failed to setup winsync replication


not sure where to look for the logs for this to see what the invalivd credentials are or wether this might still be a cert issue or a log in issue or what not?

You can test with ldapsearch like this:

$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"



Thanks in advance for the help

-Todd





_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140312/1c358ad7/attachment.htm>

From rmeggins at redhat.com  Wed Mar 12 23:23:14 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Wed, 12 Mar 2014 17:23:14 -0600
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E22965ED@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E22965ED@EXCHMB1-ELS.BWINC.local>
Message-ID: <5320EC62.5040802@redhat.com>

On 03/12/2014 05:07 PM, Todd Maugh wrote:
> so to verify this
>
> I am able to log in to the AD server as idmadmin with the password I'm 
> using in the winsync agreement.

I guess you mean that login to Windows using the standard Windows login 
dialog is working correctly?  And that this is still not working correctly:

[root at idm-master-els.ops.boingo.com ipa]$ 
LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h 
adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w 
"XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"

Do you have the Windows administrator password?  If so, can you try 
something like this:

[root at idm-master-els.ops.boingo.com ipa]$ 
LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h 
adc13-els.bwinc.local -D "cn=administrator,cn=Users,dc=bwinc,dc=local" 
-w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"

Is AD configured to allow external LDAP binds?

> is there a log I can  look at to see what it is getting tripped up on.

I suppose you could try somewhere in the Windows Event Viewer . . .

>
> I double checked all the security groups  for the AD user and they all 
> look good
>
>
> ------------------------------------------------------------------------
> *From:* Rich Megginson [rmeggins at redhat.com]
> *Sent:* Wednesday, March 12, 2014 3:47 PM
> *To:* Todd Maugh; freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>
> On 03/12/2014 04:39 PM, Todd Maugh wrote:
>> thanks Rich,
>>
>> when I run that  I get the following:
>>
>>
>> *[root at idm-master-els.ops.boingo.com ipa]$ 
>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ 
>> -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" 
>> -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
>> ldap_bind: Invalid credentials (49)
>> *
>
> *Invalid credentials almost always means your password "XXXXXX" is not 
> correct for user "**cn=idmadmin,cn=Users,dc=bwinc,dc=local"
>
> *
>> *additional info: 80090308: LdapErr: DSID-0C0903C5, comment: 
>> AcceptSecurityContext error, data 52e, v2580
>> *
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Rich Megginson [rmeggins at redhat.com]
>> *Sent:* Wednesday, March 12, 2014 3:30 PM
>> *To:* Todd Maugh; freeipa-users at redhat.com
>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>
>> On 03/12/2014 04:18 PM, Todd Maugh wrote:
>>> Hello.
>>>
>>> I'm using latest IPA build on red hat 6.5
>>>
>>> I retrieved my CA cert from the AD Domain controller
>>>
>>> I try to set up my winsyncagreement and I am getting this
>>>
>>>
>>>
>>> [root at idm-master-els.ops.boingo.com ipa]$ ipa-replica-manage connect 
>>> --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" 
>>> --bindpw "XXXXXX" --passsync "XXXXXX" 
>>> --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
>>> Directory Manager password:
>>>
>>> Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to 
>>> certificate database for idm-master-els.ops.boingo.com
>>> ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
>>> ipa: INFO: The error was: {'info': '80090308: LdapErr: 
>>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, 
>>> v2580', 'desc': 'Invalid credentials'}
>>> Failed to setup winsync replication
>>>
>>>
>>> not sure where to look for the logs for this to see what the 
>>> invalivd credentials are or wether this might still be a cert issue 
>>> or a log in issue or what not?
>>
>> You can test with ldapsearch like this:
>>
>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ 
>> -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" 
>> -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"
>>
>>>
>>>
>>> Thanks in advance for the help
>>>
>>> -Todd
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140312/ef04ace0/attachment.htm>

From simo at redhat.com  Thu Mar 13 01:04:28 2014
From: simo at redhat.com (Simo Sorce)
Date: Wed, 12 Mar 2014 21:04:28 -0400
Subject: [Freeipa-users] How to remove the CA cert from an IDM replica
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229644B@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E22962A0@EXCHMB1-ELS.BWINC.local>
	, <1394659419.32465.204.camel@willson.li.ssimo.org>
	<6FB698E172A95F49BE009B36D56F53E229639F@EXCHMB1-ELS.BWINC.local>
	,<5320D407.7010206@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229644B@EXCHMB1-ELS.BWINC.local>
Message-ID: <1394672668.32465.205.camel@willson.li.ssimo.org>

On Wed, 2014-03-12 at 22:03 +0000, Todd Maugh wrote:
> skipping the con check due to a clock skew error

If your clock is wrong you won't have a functional replica anyway.
Fix the clock.

Simo.

> ________________________________________
> From: Rob Crittenden [rcritten at redhat.com]
> Sent: Wednesday, March 12, 2014 2:39 PM
> To: Todd Maugh; Simo Sorce; freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] How to remove the CA cert from an IDM replica
> 
> Todd Maugh wrote:
> > Im seeing this error:
> >
> > where is the install log located
> >
> > [root at idm-rep02-w1c-aws ipa]# ipa-replica-install --setup-ca /var/lib/ipa/replica-info-idm-rep02-w1c-aws.ops.boingo.com.gpg --skip-conncheck
> > Directory Manager (existing master) password:
> >
> > Configuring NTP daemon (ntpd)
> >    [1/4]: stopping ntpd
> >    [2/4]: writing configuration
> >    [3/4]: configuring ntpd to start on boot
> >    [4/4]: starting ntpd
> > Done configuring NTP daemon (ntpd).
> > A CA is already configured on this system.
> 
> # /usr/bin/pkiremove -pki_instance_root=/var/lib
> -pki_instance_name=pki-ca --force
> 
> > [root at idm-rep02-w1c-aws ipa]# ipa-replica-install  /var/lib/ipa/replica-info-idm-rep02-w1c-aws.ops.boingo.com.gpg --skip-conncheck
> > Directory Manager (existing master) password:
> >
> > Configuring NTP daemon (ntpd)
> >    [1/4]: stopping ntpd
> >    [2/4]: writing configuration
> >    [3/4]: configuring ntpd to start on boot
> >    [4/4]: starting ntpd
> > Done configuring NTP daemon (ntpd).
> > Configuring directory server (dirsrv): Estimated time 1 minute
> >    [1/31]: creating directory server user
> >    [2/31]: creating directory server instance
> >    [3/31]: adding default schema
> >    [4/31]: enabling memberof plugin
> >    [5/31]: enabling winsync plugin
> >    [6/31]: configuring replication version plugin
> >    [7/31]: enabling IPA enrollment plugin
> >    [8/31]: enabling ldapi
> >    [9/31]: disabling betxn plugins
> >    [10/31]: configuring uniqueness plugin
> >    [11/31]: configuring uuid plugin
> >    [12/31]: configuring modrdn plugin
> >    [13/31]: enabling entryUSN plugin
> >    [14/31]: configuring lockout plugin
> >    [15/31]: creating indices
> >    [16/31]: enabling referential integrity plugin
> >    [17/31]: configuring ssl for ds instance
> >    [18/31]: configuring certmap.conf
> >    [19/31]: configure autobind for root
> >    [20/31]: configure new location for managed entries
> >    [21/31]: restarting directory server
> >    [22/31]: setting up initial replication
> > Starting replication, please wait until this has completed.
> > [idm-master-els.ops.boingo.com] reports: Update failed! Status: [-1  - LDAP error: Can't contact LDAP server]
> 
> Why are you skipping the conncheck? It looks like there is a firewall issue.
> 
> rob
> 


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



From Rashard.Kelly at sita.aero  Thu Mar 13 13:37:32 2014
From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero)
Date: Thu, 13 Mar 2014 09:37:32 -0400
Subject: [Freeipa-users] Sudo Rule Command Line Option Arguments (Solved)
In-Reply-To: <OF79190430.8B641110-ON85257C99.0056262F-85257C99.0056C0F2@LocalDomain>
References: <OF79190430.8B641110-ON85257C99.0056262F-85257C99.0056C0F2@LocalDomain>
Message-ID: <OFACEDEC2F.AEAC4F63-ON85257C9A.004A2907-85257C9A.004AD948@sita.aero>

The command had not been added into the sudocmd database. 

   member sudo command: /usr/bin/yum --disableexcludes=all localinstall 
example*: no such entry

I think this error should point to someone checking to make sure the sudo 
command had been created, something along the lines of "no sudocmd entry 
defined yet" vs "no such entry" would improve workflow for people stuck 
using the CMD.


Thank You,
Rashard Kelly




From:   Rashard Kelly/Atlanta/SITA/WW
To:     freeipa-users at redhat.com
Date:   03/12/2014 11:47 AM
Subject:        Sudo Rule Command Line Option Arguments


What is the correct way to add a flag inside a sudo command that will be 
added to a command group? When adding commands with no flags I have no 
issue such as "/usr/bin/yum info example*" but when I try to add options 
to the command like this "/usr/bin/yum --disableexcludes=all localinstall 
example*", It does not work even when escaping items like --. How does IPA 
handle a request like that?
 
ipa-client-3.0.0-37.el6.x86_64

[rkelly at hostname /]$ ipa sudocmdgroup-add-member --sudocmds "/usr/bin/yum 
--disableexcludes=all localinstall example*" yumsita
  Sudo Command Group: yumexample
  Description: Yum install Priviledges for example.com specific packages
  Member Sudo commands: /usr/bin/yum info example*, /usr/bin/yum update 
example*,
                        /usr/bin/yum remove example*, /usr/bin/yum install
                        example*, /usr/bin/yum localinstall example*, 
/usr/bin/yum
                        localupdate example*
  Failed members:
    member sudo command: /usr/bin/yum --disableexcludes=all localinstall 
example*: no such entry
-------------------------
Number of members added 0
-------------------------


Thank You,
Rashard Kelly


This document is strictly confidential and intended only for use by the
addressee unless otherwise stated.  If you are not the intended recipient,
please notify the sender immediately and delete it from your system.
See you at 2014 Air Transport IT Summit, 17-19 June 2014

Click here to register  http://www.sitasummit.aero


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/588cdbf4/attachment.htm>

From jitseklomp at gmail.com  Thu Mar 13 13:51:32 2014
From: jitseklomp at gmail.com (Jitse Klomp)
Date: Thu, 13 Mar 2014 14:51:32 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <531F28AD.60005@gmail.com>
References: <531DDBC3.4060700@gmail.com>
	<20140310155809.GG21499@mail.corp.redhat.com>
	<20140310160301.GH21499@mail.corp.redhat.com>
	<531DE71F.5000907@gmail.com>
	<20140310175733.GN2763@localhost.localdomain>
	<531E0AC7.2090209@gmail.com>
	<20140310193416.GO2763@localhost.localdomain>
	<531E1C19.6020502@gmail.com>
	<20140310210631.GP2763@localhost.localdomain>
	<531E382C.6000801@gmail.com>
	<20140311140634.GR2763@localhost.localdomain>
	<531F28AD.60005@gmail.com>
Message-ID: <CALj8Ak-69Zti3nG6AKaHdiFQYH=nYXk-MQRYW8Hqsis4nV4gdg@mail.gmail.com>

2014-03-11 16:15 GMT+01:00 Jitse Klomp <jitseklomp at gmail.com>:

> On 03/11/2014 03:06 PM, Sumit Bose wrote:
>
>> On Mon, Mar 10, 2014 at 11:09:48PM +0100, Jitse Klomp wrote:
>>
>>> On 10-03-14 22:06, Sumit Bose wrote:
>>>
>>>> Thank you. Maybe there is a change in return codes between MIT Kerberos
>>>> 1.10 (Centos 6) and 1.11 (F20, RHEL7). Can you try to run
>>>>
>>>> KRB5_TRACE=/dev/stdout kinit unmigrated_user at DOMAIN.NL
>>>>
>>>> on the different platforms and paste the results? I would expect to see
>>>> [Preauthentication failed] on Centos6 and [Program lacks support for
>>>> encryption type] on F10 or RHEL7.
>>>>
>>>> bye,
>>>> Sumit
>>>>
>>>
>>> http://pastebin.centos.org/8336/
>>> Top one is CentOS, bottom one Fedora. Output on RHEL7 is the same as
>>> on Fedora.
>>>
>>
>> Thank you for your patience. I was able to reproduce and fix the issue.
>> Do you want a scratch build for F20 or can you wait for the official
>> packages?
>>
>> bye,
>> Sumit
>>
>
> Great! Thanks! Do you know how long it will take for the fix to land in
> the official packages?
>
>  - Jitse
>

A scratch build would be nice too, I need to do some more testing on
Fedora...

 - Jitse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/4a728559/attachment.htm>

From rcritten at redhat.com  Thu Mar 13 13:51:48 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Thu, 13 Mar 2014 09:51:48 -0400
Subject: [Freeipa-users] Sudo Rule Command Line Option Arguments (Solved)
In-Reply-To: <OFACEDEC2F.AEAC4F63-ON85257C9A.004A2907-85257C9A.004AD948@sita.aero>
References: <OF79190430.8B641110-ON85257C99.0056262F-85257C99.0056C0F2@LocalDomain>
	<OFACEDEC2F.AEAC4F63-ON85257C9A.004A2907-85257C9A.004AD948@sita.aero>
Message-ID: <5321B7F4.9080807@redhat.com>

Rashard.Kelly at sita.aero wrote:
> The command had not been added into the sudocmd database.
>
>     member sudo command: /usr/bin/yum --disableexcludes=all localinstall
> example*: no such entry
>
> I think this error should point to someone checking to make sure the
> sudo command had been created, something along the lines of "no sudocmd
> entry defined yet" vs "no such entry" would improve workflow for people
> stuck using the CMD.

Yes, having more specific "not found" errors might be nice. I believe we 
percolate this error up directly from LDAP. Can you open a trac ticket 
on this?

rob

>
>
> Thank You,
> *Rashard Kelly**
> *
>
>
>
> From: Rashard Kelly/Atlanta/SITA/WW
> To: freeipa-users at redhat.com
> Date: 03/12/2014 11:47 AM
> Subject: Sudo Rule Command Line Option Arguments
> ------------------------------------------------------------------------
>
>
> What is the correct way to add a flag inside a sudo command that will be
> added to a command group? When adding commands with no flags I have no
> issue such as "/usr/bin/yum info example*" but when I try to add options
> to the command like this "/usr/bin/yum --disableexcludes=all
> localinstall example*", It does not work even when escaping items like
> --. How does IPA handle a request like that?
>
> ipa-client-3.0.0-37.el6.x86_64
>
> [rkelly at hostname /]$ ipa sudocmdgroup-add-member --sudocmds
> "/usr/bin/yum --disableexcludes=all localinstall example*" yumsita
>    Sudo Command Group: yumexample
>    Description: Yum install Priviledges for example.com specific packages
>    Member Sudo commands: /usr/bin/yum info example*, /usr/bin/yum update
> example*,
>              /usr/bin/yum remove example*, /usr/bin/yum install
>              example*, /usr/bin/yum localinstall example*, /usr/bin/yum
>              localupdate example*
>    Failed members:
>      member sudo command: /usr/bin/yum --disableexcludes=all
> localinstall example*: no such entry
> -------------------------
> Number of members added 0
> -------------------------
>
>
> Thank You,
> *Rashard Kelly**
> *
>
> This document is strictly confidential and intended only for use by the
> addressee unless otherwise stated. If you are not the intended
> recipient, please notify the sender immediately and delete it from your
> system. See you at 2014 Air Transport IT Summit, 17-19 June 2014 Click
> here to register http://www.sitasummit.aero
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>



From devel at jasonwoods.me.uk  Thu Mar 13 14:08:29 2014
From: devel at jasonwoods.me.uk (Jason Woods)
Date: Thu, 13 Mar 2014 14:08:29 +0000
Subject: [Freeipa-users] Mountain Lion GUI Login (Expired passwords /
	Mavericks too)
Message-ID: <07FC32E2-B2FE-4615-B5D4-AF20F5B96CDB@jasonwoods.me.uk>

Hi all,

This has been raised previously, here: https://www.redhat.com/archives/freeipa-users/2013-August/msg00043.html

I'm experiencing the same issue and I will summarise.

Mac OS X (Mavericks in my case, but it was the same before I upgraded it from Mountain Lion.)
Using RHEL 6.5 and ipa packages 3.0.0-37.

Directory Utility is connected to IPA domain using the RFC2307 templates, slightly modified so that the Groups is based from cn=compat,dc=domain and Users from cn=accounts,dc=domain, and so NFSHomeDirectory and HomeDirectory are set to "#/Users/$uid$". Reason for compat for groups is so membership works correctly (it needs memberUid format) and reason for accounts on Users is so all main info is available and regular change password works. Homes are set as such to keep everything local as I don't want networked home folders.

Logons work great. Groups are all populated fully. Users can go to System Preferences -> Users & Groups -> Change password and change password successfully. Home directories are kept local. Running the createmobileaccount manually allows an account to successfully be marked as mobile so credential cache works, even if the home directories are local (it seems the GUI won't do it properly, maybe because they're already local.) So far, fantastic.

Now if I create a new user in IPA. It will require a password change on logon.

When I logon on the Mac with this new user. The password box wiggles and a box appears underneath it. "Reset your password". Saying I need to set a new password. So I enter a new password and I verify it. Then I click "Reset Password" and it wiggle... no matter how many times I try, it doesn't move on.

The log I get is somewhat smaller as I've not yet added kerberos to the pam.d/authorization (shouldn't be required for this since regular change password works.) And possibly because less logging enabled but I'm not sure what to modify and how.

12:50:47 SecurityAgent: User info context values set for testuser
12:50:48 authorizationhost: Failed to authenticate user <testuser> (error: 10).

Any thoughts on what the issue may be? Apple issue maybe or some incompatibility on the FreeIPA side? Are there any logs from anywhere on the IPA that might help? I can see no apparent issues in the slapd access log, it seems to return successful for various attributes and just stop and no change comes in for the password - it doesn't seem to even request the global_policy which it does when using regular Change password.

Regards,

Jason



From rstory at tislabs.com  Thu Mar 13 14:29:09 2014
From: rstory at tislabs.com (Robert Story)
Date: Thu, 13 Mar 2014 10:29:09 -0400
Subject: [Freeipa-users] Mountain Lion GUI Login (Expired passwords /
 Mavericks too)
In-Reply-To: <07FC32E2-B2FE-4615-B5D4-AF20F5B96CDB@jasonwoods.me.uk>
References: <07FC32E2-B2FE-4615-B5D4-AF20F5B96CDB@jasonwoods.me.uk>
Message-ID: <20140313102909.744c56da@ispx.vb.futz.org>

On Thu, 13 Mar 2014 14:08:29 +0000 Jason wrote:
JW> Now if I create a new user in IPA. It will require a password change on
JW> logon.
JW> 
JW> When I logon on the Mac with this new user. The password box wiggles
JW> and a box appears underneath it. "Reset your password". Saying I need
JW> to set a new password. So I enter a new password and I verify it. Then
JW> I click "Reset Password" and it wiggle... no matter how many times I
JW> try, it doesn't move on.

I don't have OS X, but every time I create a new test user on linux and log
in to test it, I get bit by the fact that the passwd change always asks for
the existing password first, before asking for the new password. So I have
to enter the original password once to login, once to make passwd happy,
and then enter the new password. Are you sure the dialog box isn't asking
for the existing password first?


Robert

--
Senior Software Engineer @ Parsons
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/70dee01a/attachment.sig>

From Rashard.Kelly at sita.aero  Thu Mar 13 14:59:15 2014
From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero)
Date: Thu, 13 Mar 2014 10:59:15 -0400
Subject: [Freeipa-users] Sudo Rule Command Line Option Arguments (Solved)
In-Reply-To: <5321B7F4.9080807@redhat.com>
References: <OF79190430.8B641110-ON85257C99.0056262F-85257C99.0056C0F2@LocalDomain>
	<OFACEDEC2F.AEAC4F63-ON85257C9A.004A2907-85257C9A.004AD948@sita.aero>
	<5321B7F4.9080807@redhat.com>
Message-ID: <OFAC57C55F.1DCB9553-ON85257C9A.00524A12-85257C9A.00525436@sita.aero>

I would be happy to open a ticket, where do I go to do that?


Thank You,
Rashard Kelly



From:   Rob Crittenden <rcritten at redhat.com>
To:     Rashard.Kelly at sita.aero, freeipa-users at redhat.com
Date:   03/13/2014 09:52 AM
Subject:        Re: [Freeipa-users] Sudo Rule Command Line Option 
Arguments (Solved)



Rashard.Kelly at sita.aero wrote:
> The command had not been added into the sudocmd database.
>
>     member sudo command: /usr/bin/yum --disableexcludes=all localinstall
> example*: no such entry
>
> I think this error should point to someone checking to make sure the
> sudo command had been created, something along the lines of "no sudocmd
> entry defined yet" vs "no such entry" would improve workflow for people
> stuck using the CMD.

Yes, having more specific "not found" errors might be nice. I believe we 
percolate this error up directly from LDAP. Can you open a trac ticket 
on this?

rob

>
>
> Thank You,
> *Rashard Kelly**
> *
>
>
>
> From: Rashard Kelly/Atlanta/SITA/WW
> To: freeipa-users at redhat.com
> Date: 03/12/2014 11:47 AM
> Subject: Sudo Rule Command Line Option Arguments
> ------------------------------------------------------------------------
>
>
> What is the correct way to add a flag inside a sudo command that will be
> added to a command group? When adding commands with no flags I have no
> issue such as "/usr/bin/yum info example*" but when I try to add options
> to the command like this "/usr/bin/yum --disableexcludes=all
> localinstall example*", It does not work even when escaping items like
> --. How does IPA handle a request like that?
>
> ipa-client-3.0.0-37.el6.x86_64
>
> [rkelly at hostname /]$ ipa sudocmdgroup-add-member --sudocmds
> "/usr/bin/yum --disableexcludes=all localinstall example*" yumsita
>    Sudo Command Group: yumexample
>    Description: Yum install Priviledges for example.com specific 
packages
>    Member Sudo commands: /usr/bin/yum info example*, /usr/bin/yum update
> example*,
>              /usr/bin/yum remove example*, /usr/bin/yum install
>              example*, /usr/bin/yum localinstall example*, /usr/bin/yum
>              localupdate example*
>    Failed members:
>      member sudo command: /usr/bin/yum --disableexcludes=all
> localinstall example*: no such entry
> -------------------------
> Number of members added 0
> -------------------------
>
>
> Thank You,
> *Rashard Kelly**
> *
>
> This document is strictly confidential and intended only for use by the
> addressee unless otherwise stated. If you are not the intended
> recipient, please notify the sender immediately and delete it from your
> system. See you at 2014 Air Transport IT Summit, 17-19 June 2014 Click
> here to register http://www.sitasummit.aero
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>



This document is strictly confidential and intended only for use by the
addressee unless otherwise stated.  If you are not the intended recipient,
please notify the sender immediately and delete it from your system.
See you at 2014 Air Transport IT Summit, 17-19 June 2014

Click here to register  http://www.sitasummit.aero


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/e125acf0/attachment.htm>

From pspacek at redhat.com  Thu Mar 13 15:12:06 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Thu, 13 Mar 2014 16:12:06 +0100
Subject: [Freeipa-users] Sudo Rule Command Line Option Arguments (Solved)
In-Reply-To: <OFAC57C55F.1DCB9553-ON85257C9A.00524A12-85257C9A.00525436@sita.aero>
References: <OF79190430.8B641110-ON85257C99.0056262F-85257C99.0056C0F2@LocalDomain>	<OFACEDEC2F.AEAC4F63-ON85257C9A.004A2907-85257C9A.004AD948@sita.aero>	<5321B7F4.9080807@redhat.com>
	<OFAC57C55F.1DCB9553-ON85257C9A.00524A12-85257C9A.00525436@sita.aero>
Message-ID: <5321CAC6.3000506@redhat.com>

On 13.3.2014 15:59, Rashard.Kelly at sita.aero wrote:
> I would be happy to open a ticket, where do I go to do that?
https://fedorahosted.org/freeipa/newticket

You need an Fedora account to open a new ticket:
https://admin.fedoraproject.org/accounts/user/new

Petr^2 Spacek

> From:   Rob Crittenden <rcritten at redhat.com>
> To:     Rashard.Kelly at sita.aero, freeipa-users at redhat.com
> Date:   03/13/2014 09:52 AM
> Subject:        Re: [Freeipa-users] Sudo Rule Command Line Option
> Arguments (Solved)
>
>
>
> Rashard.Kelly at sita.aero wrote:
>> The command had not been added into the sudocmd database.
>>
>>      member sudo command: /usr/bin/yum --disableexcludes=all localinstall
>> example*: no such entry
>>
>> I think this error should point to someone checking to make sure the
>> sudo command had been created, something along the lines of "no sudocmd
>> entry defined yet" vs "no such entry" would improve workflow for people
>> stuck using the CMD.
>
> Yes, having more specific "not found" errors might be nice. I believe we
> percolate this error up directly from LDAP. Can you open a trac ticket
> on this?
>
> rob
>
>>
>>
>> Thank You,
>> *Rashard Kelly**
>> *
>>
>>
>>
>> From: Rashard Kelly/Atlanta/SITA/WW
>> To: freeipa-users at redhat.com
>> Date: 03/12/2014 11:47 AM
>> Subject: Sudo Rule Command Line Option Arguments
>> ------------------------------------------------------------------------
>>
>>
>> What is the correct way to add a flag inside a sudo command that will be
>> added to a command group? When adding commands with no flags I have no
>> issue such as "/usr/bin/yum info example*" but when I try to add options
>> to the command like this "/usr/bin/yum --disableexcludes=all
>> localinstall example*", It does not work even when escaping items like
>> --. How does IPA handle a request like that?
>>
>> ipa-client-3.0.0-37.el6.x86_64
>>
>> [rkelly at hostname /]$ ipa sudocmdgroup-add-member --sudocmds
>> "/usr/bin/yum --disableexcludes=all localinstall example*" yumsita
>>     Sudo Command Group: yumexample
>>     Description: Yum install Priviledges for example.com specific
> packages
>>     Member Sudo commands: /usr/bin/yum info example*, /usr/bin/yum update
>> example*,
>>               /usr/bin/yum remove example*, /usr/bin/yum install
>>               example*, /usr/bin/yum localinstall example*, /usr/bin/yum
>>               localupdate example*
>>     Failed members:
>>       member sudo command: /usr/bin/yum --disableexcludes=all
>> localinstall example*: no such entry
>> -------------------------
>> Number of members added 0
>> -------------------------


-- 
Petr^2 Spacek



From lslebodn at redhat.com  Thu Mar 13 17:00:18 2014
From: lslebodn at redhat.com (Lukas Slebodnik)
Date: Thu, 13 Mar 2014 18:00:18 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <CALj8Ak-69Zti3nG6AKaHdiFQYH=nYXk-MQRYW8Hqsis4nV4gdg@mail.gmail.com>
References: <531DE71F.5000907@gmail.com>
	<20140310175733.GN2763@localhost.localdomain>
	<531E0AC7.2090209@gmail.com>
	<20140310193416.GO2763@localhost.localdomain>
	<531E1C19.6020502@gmail.com>
	<20140310210631.GP2763@localhost.localdomain>
	<531E382C.6000801@gmail.com>
	<20140311140634.GR2763@localhost.localdomain>
	<531F28AD.60005@gmail.com>
	<CALj8Ak-69Zti3nG6AKaHdiFQYH=nYXk-MQRYW8Hqsis4nV4gdg@mail.gmail.com>
Message-ID: <20140313170017.GA15668@mail.corp.redhat.com>

On (13/03/14 14:51), Jitse Klomp wrote:
>2014-03-11 16:15 GMT+01:00 Jitse Klomp <jitseklomp at gmail.com>:
>
>> On 03/11/2014 03:06 PM, Sumit Bose wrote:
>>
>>> On Mon, Mar 10, 2014 at 11:09:48PM +0100, Jitse Klomp wrote:
>>>
>>>> On 10-03-14 22:06, Sumit Bose wrote:
>>>>
>>>>> Thank you. Maybe there is a change in return codes between MIT Kerberos
>>>>> 1.10 (Centos 6) and 1.11 (F20, RHEL7). Can you try to run
>>>>>
>>>>> KRB5_TRACE=/dev/stdout kinit unmigrated_user at DOMAIN.NL
>>>>>
>>>>> on the different platforms and paste the results? I would expect to see
>>>>> [Preauthentication failed] on Centos6 and [Program lacks support for
>>>>> encryption type] on F10 or RHEL7.
>>>>>
>>>>> bye,
>>>>> Sumit
>>>>>
>>>>
>>>> http://pastebin.centos.org/8336/
>>>> Top one is CentOS, bottom one Fedora. Output on RHEL7 is the same as
>>>> on Fedora.
>>>>
>>>
>>> Thank you for your patience. I was able to reproduce and fix the issue.
>>> Do you want a scratch build for F20 or can you wait for the official
>>> packages?
>>>
>>> bye,
>>> Sumit
>>>
>>
>> Great! Thanks! Do you know how long it will take for the fix to land in
>> the official packages?
>>
>>  - Jitse
>>
>
>A scratch build would be nice too, I need to do some more testing on
>Fedora...
>
> - Jitse

Upstream SSSD ticket: https://fedorahosted.org/sssd/ticket/2279

Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6630169

x86_64 packages from scratch build:
        http://koji.fedoraproject.org/koji/taskinfo?taskID=6630174

LS



From tmaugh at boingo.com  Thu Mar 13 17:02:32 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 13 Mar 2014 17:02:32 +0000
Subject: [Freeipa-users] quick question
Message-ID: <6FB698E172A95F49BE009B36D56F53E229703F@EXCHMB1-ELS.BWINC.local>

does IDM work with AD 2012 or only 2008

-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/4917f9e6/attachment.htm>

From rmeggins at redhat.com  Thu Mar 13 17:16:12 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 13 Mar 2014 11:16:12 -0600
Subject: [Freeipa-users] quick question
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229703F@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229703F@EXCHMB1-ELS.BWINC.local>
Message-ID: <5321E7DC.2090101@redhat.com>

On 03/13/2014 11:02 AM, Todd Maugh wrote:
> does IDM work with AD 2012 or only 2008

Are you talking about trusts?  Not sure.

Winsync?  The PassSync password sync agent?
I think so, with RHEL 6.5, or perhaps it is RHEL6.6.

>
> -Todd
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/02e15272/attachment.htm>

From abokovoy at redhat.com  Thu Mar 13 17:26:03 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Thu, 13 Mar 2014 19:26:03 +0200
Subject: [Freeipa-users] quick question
In-Reply-To: <5321E7DC.2090101@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E229703F@EXCHMB1-ELS.BWINC.local>
	<5321E7DC.2090101@redhat.com>
Message-ID: <20140313172603.GR16644@redhat.com>

On Thu, 13 Mar 2014, Rich Megginson wrote:
>On 03/13/2014 11:02 AM, Todd Maugh wrote:
>>does IDM work with AD 2012 or only 2008
>
>Are you talking about trusts?  Not sure.
>
>Winsync?  The PassSync password sync agent?
>I think so, with RHEL 6.5, or perhaps it is RHEL6.6.
Trusts work with 2008, 2008R2, 2012+. Some people made it working with
2003 at the expense of weak crypto.

-- 
/ Alexander Bokovoy



From tmaugh at boingo.com  Thu Mar 13 17:28:18 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 13 Mar 2014 17:28:18 +0000
Subject: [Freeipa-users] quick question
In-Reply-To: <5321E7DC.2090101@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E229703F@EXCHMB1-ELS.BWINC.local>
	<5321E7DC.2090101@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E229706A@EXCHMB1-ELS.BWINC.local>

Yes for trusts rhel6.5 with AD 2012 for winsync and password sync

From: Rich Megginson [mailto:rmeggins at redhat.com]
Sent: Thursday, March 13, 2014 10:16 AM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] quick question

On 03/13/2014 11:02 AM, Todd Maugh wrote:
does IDM work with AD 2012 or only 2008

Are you talking about trusts?  Not sure.

Winsync?  The PassSync password sync agent?
I think so, with RHEL 6.5, or perhaps it is RHEL6.6.



-Todd




_______________________________________________

Freeipa-users mailing list

Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>

https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/74c9e21f/attachment.htm>

From abokovoy at redhat.com  Thu Mar 13 17:40:46 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Thu, 13 Mar 2014 19:40:46 +0200
Subject: [Freeipa-users] quick question
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229706A@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229703F@EXCHMB1-ELS.BWINC.local>
	<5321E7DC.2090101@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229706A@EXCHMB1-ELS.BWINC.local>
Message-ID: <20140313174046.GS16644@redhat.com>

Todd,

On Thu, 13 Mar 2014, Todd Maugh wrote:
>Yes for trusts rhel6.5 with AD 2012 for winsync and password sync

You are mixing two different things.

- winsync/password sync is not trusts. AD accounts are physically cloned to
   IdM on each change at AD side. When logging to IdM with AD account,
   authentication is performed by IdM solely based on the password set in
   IdM.

- trusts is not winsync/password sync. Accounts are always managed at AD
   side and never duplicated in IdM LDAP. When logging to IdM with AD
   account, authentication is performed by AD and validated by IdM based
   on IdM's HBAC rules.

Both approaches have own benefits but they are not mixable.


>
>From: Rich Megginson [mailto:rmeggins at redhat.com]
>Sent: Thursday, March 13, 2014 10:16 AM
>To: Todd Maugh; freeipa-users at redhat.com
>Subject: Re: [Freeipa-users] quick question
>
>On 03/13/2014 11:02 AM, Todd Maugh wrote:
>does IDM work with AD 2012 or only 2008
>
>Are you talking about trusts?  Not sure.
>
>Winsync?  The PassSync password sync agent?
>I think so, with RHEL 6.5, or perhaps it is RHEL6.6.
>
>
>
>-Todd
>
>
>
>
>_______________________________________________
>
>Freeipa-users mailing list
>
>Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
>
>https://www.redhat.com/mailman/listinfo/freeipa-users
>

>_______________________________________________
>Freeipa-users mailing list
>Freeipa-users at redhat.com
>https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
/ Alexander Bokovoy



From tmaugh at boingo.com  Thu Mar 13 18:01:50 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 13 Mar 2014 18:01:50 +0000
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <5320EC62.5040802@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E22965ED@EXCHMB1-ELS.BWINC.local>,
	<5320EC62.5040802@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E22971CB@EXCHMB1-ELS.BWINC.local>

Ok I got the credentials error worked out, my ad admin had the IDMadmin account in the wrong OU

but now i get this


Added CA certificate ADC13-ELS.CA.cer to certificate database for idm-master-els.ops.boingo.com
ipa: INFO: AD Suffix is: DC=BWINC,DC=local
The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=ops,dc=boingo,dc=com
ipa: INFO: Added new sync agreement, waiting for it to become ready . . .
ipa: INFO: Replication Update in progress: FALSE: status: -11  - LDAP error: Connect error: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.
[idm-master-els.ops.boingo.com] reports: Update failed! Status: [-11  - LDAP error: Connect error]
Failed to start replication



not sure where to look for more errors about this


________________________________
From: Rich Megginson [rmeggins at redhat.com]
Sent: Wednesday, March 12, 2014 4:23 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 05:07 PM, Todd Maugh wrote:
so to verify this

I am able to log in to the AD server as idmadmin with the password I'm using in the winsync agreement.

I guess you mean that login to Windows using the standard Windows login dialog is working correctly?  And that this is still not working correctly:

[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"

Do you have the Windows administrator password?  If so, can you try something like this:

[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=administrator,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"

Is AD configured to allow external LDAP binds?

is there a log I can  look at to see what it is getting tripped up on.

I suppose you could try somewhere in the Windows Event Viewer . . .


I double checked all the security groups  for the AD user and they all look good


________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:47 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:39 PM, Todd Maugh wrote:
thanks Rich,

when I run that  I get the following:


[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
ldap_bind: Invalid credentials (49)

Invalid credentials almost always means your password "XXXXXX" is not correct for user "cn=idmadmin,cn=Users,dc=bwinc,dc=local"

    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580



________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:30 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:18 PM, Todd Maugh wrote:
Hello.

I'm using latest IPA build on red hat 6.5

I retrieved my CA cert from the AD Domain controller

I try to set up my winsyncagreement and I am getting this



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ ipa-replica-manage connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to certificate database for idm-master-els.ops.boingo.com
ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 'Invalid credentials'}
Failed to setup winsync replication


not sure where to look for the logs for this to see what the invalivd credentials are or wether this might still be a cert issue or a log in issue or what not?

You can test with ldapsearch like this:

$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"



Thanks in advance for the help

-Todd





_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/75ca43c5/attachment.htm>

From davis.goodman at digital-district.ca  Thu Mar 13 18:12:05 2014
From: davis.goodman at digital-district.ca (Davis Goodman)
Date: Thu, 13 Mar 2014 14:12:05 -0400
Subject: [Freeipa-users] Mountain Lion GUI Login (Expired passwords /
	Mavericks too)
In-Reply-To: <20140313102909.744c56da@ispx.vb.futz.org>
References: <07FC32E2-B2FE-4615-B5D4-AF20F5B96CDB@jasonwoods.me.uk>
	<20140313102909.744c56da@ispx.vb.futz.org>
Message-ID: <148FB38E-345C-42ED-A210-D072CA0408CD@digital-district.ca>




-- 


Davis Goodman
Directeur Informatique  |  IT Manager

5605 Avenue de Gasp?, Suite 408  |  Montr?al, QC H2T 2A4 
T?l: +1 (514) 360-3253 x104            Cell: +1 (514) 994-7360 





On Mar 13, 2014, at 10:29 , Robert Story <rstory at tislabs.com> wrote:

> On Thu, 13 Mar 2014 14:08:29 +0000 Jason wrote:
> JW> Now if I create a new user in IPA. It will require a password change on
> JW> logon.
> JW> 
> JW> When I logon on the Mac with this new user. The password box wiggles
> JW> and a box appears underneath it. "Reset your password". Saying I need
> JW> to set a new password. So I enter a new password and I verify it. Then
> JW> I click "Reset Password" and it wiggle... no matter how many times I
> JW> try, it doesn't move on.
> 
> I don't have OS X, but every time I create a new test user on linux and log
> in to test it, I get bit by the fact that the passwd change always asks for
> the existing password first, before asking for the new password. So I have
> to enter the original password once to login, once to make passwd happy,
> and then enter the new password. Are you sure the dialog box isn't asking
> for the existing password first?
> 
> 
> Robert
> 
> --
> Senior Software Engineer @ Parsons
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
Well I still haven?t had any responses since that time.

I wish we could resolve this since it?s the only little bit remaining to have a full FreeIPA integration.

BTW we also integrated sudo-ldap on our OSX machines. The only thing is that you have to upgrade the sudo packages with this one.

sudo-1.8.9p3.pkg

and then:

installer -pkg /prod/sysadmin/darwin/software/sudo/sudo-1.8.9p3.pkg -target /
mv /usr/bin/sudo /usr/bin/sudo.orig
ln -s /usr/local/bin/sudo /usr/bin

then you modify sudo-ldap and nsswitch.conf same thing as on the linux boxes.




-- 


Davis Goodman
Directeur Informatique  |  IT Manager

5605 Avenue de Gasp?, Suite 408  |  Montr?al, QC H2T 2A4 
T?l: +1 (514) 360-3253 x104            Cell: +1 (514) 994-7360 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/f99a2a02/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_dd_small.png
Type: image/png
Size: 7313 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/f99a2a02/attachment.png>

From rmeggins at redhat.com  Thu Mar 13 18:22:49 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 13 Mar 2014 12:22:49 -0600
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E22971CB@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E22965ED@EXCHMB1-ELS.BWINC.local>,
	<5320EC62.5040802@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E22971CB@EXCHMB1-ELS.BWINC.local>
Message-ID: <5321F779.2030600@redhat.com>

On 03/13/2014 12:01 PM, Todd Maugh wrote:
> Ok I got the credentials error worked out, my ad admin had the 
> IDMadmin account in the wrong OU
>
> but now i get this
>
>
> Added CA certificate ADC13-ELS.CA.cer to certificate database for 
> idm-master-els.ops.boingo.com
> ipa: INFO: AD Suffix is: DC=BWINC,DC=local
> The user for the Windows PassSync service is 
> uid=passsync,cn=sysaccounts,cn=etc,dc=ops,dc=boingo,dc=com
> ipa: INFO: Added new sync agreement, waiting for it to become ready . . .
> ipa: INFO: Replication Update in progress: FALSE: status: -11  - LDAP 
> error: Connect error: start: 0: end: 0
> ipa: INFO: Agreement is ready, starting replication . . .
> Starting replication, please wait until this has completed.
> [idm-master-els.ops.boingo.com] reports: Update failed! Status: [-11  
> - LDAP error: Connect error]
> Failed to start replication

Ok.  First step is to use ldapsearch to check connection, certs, 
passwords, etc.

[root at idm-master-els.ops.boingo.com ipa]$ 
LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h 
adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w 
"XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"

Or whatever your actual idmadmin DN is.

>
>
>
> not sure where to look for more errors about this
>
>
> ------------------------------------------------------------------------
> *From:* Rich Megginson [rmeggins at redhat.com]
> *Sent:* Wednesday, March 12, 2014 4:23 PM
> *To:* Todd Maugh; freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>
> On 03/12/2014 05:07 PM, Todd Maugh wrote:
>> so to verify this
>>
>> I am able to log in to the AD server as idmadmin with the password 
>> I'm using in the winsync agreement.
>
> I guess you mean that login to Windows using the standard Windows 
> login dialog is working correctly?  And that this is still not working 
> correctly:
>
> [root at idm-master-els.ops.boingo.com ipa]$ 
> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ 
> -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" 
> -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
>
> Do you have the Windows administrator password?  If so, can you try 
> something like this:
>
> [root at idm-master-els.ops.boingo.com ipa]$ 
> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ 
> -h adc13-els.bwinc.local -D 
> "cn=administrator,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b 
> "cn=Users,dc=bwinc,dc=local"
>
> Is AD configured to allow external LDAP binds?
>
>> is there a log I can look at to see what it is getting tripped up on.
>
> I suppose you could try somewhere in the Windows Event Viewer . . .
>
>>
>> I double checked all the security groups  for the AD user and they 
>> all look good
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Rich Megginson [rmeggins at redhat.com]
>> *Sent:* Wednesday, March 12, 2014 3:47 PM
>> *To:* Todd Maugh; freeipa-users at redhat.com
>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>
>> On 03/12/2014 04:39 PM, Todd Maugh wrote:
>>> thanks Rich,
>>>
>>> when I run that  I get the following:
>>>
>>>
>>> *[root at idm-master-els.ops.boingo.com ipa]$ 
>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch 
>>> -xLLLZZ -h adc13-els.bwinc.local -D 
>>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b 
>>> "cn=Users,dc=bwinc,dc=local"
>>> ldap_bind: Invalid credentials (49)
>>> *
>>
>> *Invalid credentials almost always means your password "XXXXXX" is 
>> not correct for user "**cn=idmadmin,cn=Users,dc=bwinc,dc=local"
>>
>> *
>>> *    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: 
>>> AcceptSecurityContext error, data 52e, v2580
>>> *
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>> *Sent:* Wednesday, March 12, 2014 3:30 PM
>>> *To:* Todd Maugh; freeipa-users at redhat.com
>>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>>
>>> On 03/12/2014 04:18 PM, Todd Maugh wrote:
>>>> Hello.
>>>>
>>>> I'm using latest IPA build on red hat 6.5
>>>>
>>>> I retrieved my CA cert from the AD Domain controller
>>>>
>>>> I try to set up my winsyncagreement and I am getting this
>>>>
>>>>
>>>>
>>>> [root at idm-master-els.ops.boingo.com ipa]$ ipa-replica-manage 
>>>> connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, 
>>>> dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" 
>>>> --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
>>>> Directory Manager password:
>>>>
>>>> Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to 
>>>> certificate database for idm-master-els.ops.boingo.com
>>>> ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
>>>> ipa: INFO: The error was: {'info': '80090308: LdapErr: 
>>>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, 
>>>> v2580', 'desc': 'Invalid credentials'}
>>>> Failed to setup winsync replication
>>>>
>>>>
>>>> not sure where to look for the logs for this to see what the 
>>>> invalivd credentials are or wether this might still be a cert issue 
>>>> or a log in issue or what not?
>>>
>>> You can test with ldapsearch like this:
>>>
>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ 
>>> -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" 
>>> -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"
>>>
>>>>
>>>>
>>>> Thanks in advance for the help
>>>>
>>>> -Todd
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeipa-users mailing list
>>>> Freeipa-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/f165f1a8/attachment.htm>

From tmaugh at boingo.com  Thu Mar 13 18:29:44 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 13 Mar 2014 18:29:44 +0000
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <5320E40E.4030604@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>

ok so I ran that and Get this output


[root at idm-master-els.ops.boingo.com cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local"
dn: cn=Users,dc=bwinc,dc=local
objectClass: top
objectClass: container
cn: Users
description: Default container for upgraded user accounts
distinguishedName: CN=Users,DC=BWINC,DC=local
instanceType: 4
whenCreated: 20060824234034.0Z
whenChanged: 20140306190741.0Z
uSNCreated: 17702
uSNChanged: 17702
showInAdvancedViewOnly: FALSE
name: Users
objectGUID:: kCZ7CbnIZk+0GpmCr3PCfw==
systemFlags: -1946157056
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=BWINC,DC=local
isCriticalSystemObject: TRUE
dSCorePropagationData: 20140306234416.0Z
dSCorePropagationData: 20140306234348.0Z
dSCorePropagationData: 20140306225101.0Z
dSCorePropagationData: 20140306225055.0Z
dSCorePropagationData: 16010101000000.0Z

________________________________
From: Rich Megginson [rmeggins at redhat.com]
Sent: Wednesday, March 12, 2014 3:47 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:39 PM, Todd Maugh wrote:
thanks Rich,

when I run that  I get the following:


[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
ldap_bind: Invalid credentials (49)

Invalid credentials almost always means your password "XXXXXX" is not correct for user "cn=idmadmin,cn=Users,dc=bwinc,dc=local"

    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580



________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:30 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:18 PM, Todd Maugh wrote:
Hello.

I'm using latest IPA build on red hat 6.5

I retrieved my CA cert from the AD Domain controller

I try to set up my winsyncagreement and I am getting this



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ ipa-replica-manage connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to certificate database for idm-master-els.ops.boingo.com
ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 'Invalid credentials'}
Failed to setup winsync replication


not sure where to look for the logs for this to see what the invalivd credentials are or wether this might still be a cert issue or a log in issue or what not?

You can test with ldapsearch like this:

$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"



Thanks in advance for the help

-Todd





_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/ca258ea0/attachment.htm>

From devel at jasonwoods.me.uk  Thu Mar 13 18:32:08 2014
From: devel at jasonwoods.me.uk (Jason Woods)
Date: Thu, 13 Mar 2014 18:32:08 +0000
Subject: [Freeipa-users] Mountain Lion GUI Login (Expired passwords /
	Mavericks too)
In-Reply-To: <148FB38E-345C-42ED-A210-D072CA0408CD@digital-district.ca>
References: <07FC32E2-B2FE-4615-B5D4-AF20F5B96CDB@jasonwoods.me.uk>
	<20140313102909.744c56da@ispx.vb.futz.org>
	<148FB38E-345C-42ED-A210-D072CA0408CD@digital-district.ca>
Message-ID: <05DF1AD1-E8D5-451D-B4C7-A5577F549C9D@jasonwoods.me.uk>

Hi

>> 
>> I don't have OS X, but every time I create a new test user on linux and log
>> in to test it, I get bit by the fact that the passwd change always asks for
>> the existing password first, before asking for the new password. So I have
>> to enter the original password once to login, once to make passwd happy,
>> and then enter the new password. Are you sure the dialog box isn't asking
>> for the existing password first?
>> 
>> 
>> Robert
>> 
>> --
>> Senior Software Engineer @ Parsons
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
> Well I still haven?t had any responses since that time.
> 
> I wish we could resolve this since it?s the only little bit remaining to have a full FreeIPA integration.
> 

Yeh it's the only thing wrong for me.

To answer Robert's question though - the reset password is a pop up with an arrow to the login and the original password is still there - so I would assume so. Guessing this is gonna need deeper investigation though but I suspect it's more on the Apple side :-(

> BTW we also integrated sudo-ldap on our OSX machines. The only thing is that you have to upgrade the sudo packages with this one.
> 
> sudo-1.8.9p3.pkg
> 
> and then:
> 
> installer -pkg /prod/sysadmin/darwin/software/sudo/sudo-1.8.9p3.pkg -target /
> mv /usr/bin/sudo /usr/bin/sudo.orig
> ln -s /usr/local/bin/sudo /usr/bin
> 
> then you modify sudo-ldap and nsswitch.conf same thing as on the linux boxes.
> 
> 
> 
> 
> -- 
> 
> 
> Davis Goodman
> Directeur Informatique  |  IT Manager
> <logo_dd_small.png>
> 5605 Avenue de Gasp?, Suite 408  |  Montr?al, QC H2T 2A4 
> T?l: +1 (514) 360-3253 x104            Cell: +1 (514) 994-7360 
> 

Thanks for that! We've not got around to any sudo and not really needed but it's great to know it's certainly possible and fairly straightforward!

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/460ec6f6/attachment.htm>

From jitseklomp at gmail.com  Thu Mar 13 18:36:55 2014
From: jitseklomp at gmail.com (Jitse Klomp)
Date: Thu, 13 Mar 2014 19:36:55 +0100
Subject: [Freeipa-users] Migration mode
In-Reply-To: <20140313170017.GA15668@mail.corp.redhat.com>
References: <531DE71F.5000907@gmail.com>
	<20140310175733.GN2763@localhost.localdomain>
	<531E0AC7.2090209@gmail.com>
	<20140310193416.GO2763@localhost.localdomain>
	<531E1C19.6020502@gmail.com>
	<20140310210631.GP2763@localhost.localdomain>
	<531E382C.6000801@gmail.com>
	<20140311140634.GR2763@localhost.localdomain>
	<531F28AD.60005@gmail.com>
	<CALj8Ak-69Zti3nG6AKaHdiFQYH=nYXk-MQRYW8Hqsis4nV4gdg@mail.gmail.com>
	<20140313170017.GA15668@mail.corp.redhat.com>
Message-ID: <CALj8Ak9DUHw_tBrHDDug_LiZ32x9A5d6WS79tJm1MgAHM8f6Ag@mail.gmail.com>

2014-03-13 18:00 GMT+01:00 Lukas Slebodnik <lslebodn at redhat.com>:

> On (13/03/14 14:51), Jitse Klomp wrote:
> >2014-03-11 16:15 GMT+01:00 Jitse Klomp <jitseklomp at gmail.com>:
> >
> >> On 03/11/2014 03:06 PM, Sumit Bose wrote:
> >>
> >>> On Mon, Mar 10, 2014 at 11:09:48PM +0100, Jitse Klomp wrote:
> >>>
> >>>> On 10-03-14 22:06, Sumit Bose wrote:
> >>>>
> >>>>> Thank you. Maybe there is a change in return codes between MIT
> Kerberos
> >>>>> 1.10 (Centos 6) and 1.11 (F20, RHEL7). Can you try to run
> >>>>>
> >>>>> KRB5_TRACE=/dev/stdout kinit unmigrated_user at DOMAIN.NL
> >>>>>
> >>>>> on the different platforms and paste the results? I would expect to
> see
> >>>>> [Preauthentication failed] on Centos6 and [Program lacks support for
> >>>>> encryption type] on F10 or RHEL7.
> >>>>>
> >>>>> bye,
> >>>>> Sumit
> >>>>>
> >>>>
> >>>> http://pastebin.centos.org/8336/
> >>>> Top one is CentOS, bottom one Fedora. Output on RHEL7 is the same as
> >>>> on Fedora.
> >>>>
> >>>
> >>> Thank you for your patience. I was able to reproduce and fix the issue.
> >>> Do you want a scratch build for F20 or can you wait for the official
> >>> packages?
> >>>
> >>> bye,
> >>> Sumit
> >>>
> >>
> >> Great! Thanks! Do you know how long it will take for the fix to land in
> >> the official packages?
> >>
> >>  - Jitse
> >>
> >
> >A scratch build would be nice too, I need to do some more testing on
> >Fedora...
> >
> > - Jitse
>
> Upstream SSSD ticket: https://fedorahosted.org/sssd/ticket/2279
>
> Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6630169
>
> x86_64 packages from scratch build:
>         http://koji.fedoraproject.org/koji/taskinfo?taskID=6630174
>
>
Brilliant! Thank for the help!

 - Jitse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/c5579340/attachment.htm>

From rmeggins at redhat.com  Thu Mar 13 18:43:42 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 13 Mar 2014 12:43:42 -0600
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>
Message-ID: <5321FC5E.1070101@redhat.com>

On 03/13/2014 12:29 PM, Todd Maugh wrote:
> ok so I ran that and Get this output

Ok.  Next, take a look at /var/log/dirsrv/slapd-OPS-BOINGO-COM/errors

>
>
> [root at idm-master-els.ops.boingo.com cacerts]$ 
> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ 
> -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" 
> -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local"
> dn: cn=Users,dc=bwinc,dc=local
> objectClass: top
> objectClass: container
> cn: Users
> description: Default container for upgraded user accounts
> distinguishedName: CN=Users,DC=BWINC,DC=local
> instanceType: 4
> whenCreated: 20060824234034.0Z
> whenChanged: 20140306190741.0Z
> uSNCreated: 17702
> uSNChanged: 17702
> showInAdvancedViewOnly: FALSE
> name: Users
> objectGUID:: kCZ7CbnIZk+0GpmCr3PCfw==
> systemFlags: -1946157056
> objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=BWINC,DC=local
> isCriticalSystemObject: TRUE
> dSCorePropagationData: 20140306234416.0Z
> dSCorePropagationData: 20140306234348.0Z
> dSCorePropagationData: 20140306225101.0Z
> dSCorePropagationData: 20140306225055.0Z
> dSCorePropagationData: 16010101000000.0Z
>
> ------------------------------------------------------------------------
> *From:* Rich Megginson [rmeggins at redhat.com]
> *Sent:* Wednesday, March 12, 2014 3:47 PM
> *To:* Todd Maugh; freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>
> On 03/12/2014 04:39 PM, Todd Maugh wrote:
>> thanks Rich,
>>
>> when I run that  I get the following:
>>
>>
>> *[root at idm-master-els.ops.boingo.com ipa]$ 
>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ 
>> -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" 
>> -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
>> ldap_bind: Invalid credentials (49)
>> *
>
> *Invalid credentials almost always means your password "XXXXXX" is not 
> correct for user "**cn=idmadmin,cn=Users,dc=bwinc,dc=local"
>
> *
>> *additional info: 80090308: LdapErr: DSID-0C0903C5, comment: 
>> AcceptSecurityContext error, data 52e, v2580
>> *
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Rich Megginson [rmeggins at redhat.com]
>> *Sent:* Wednesday, March 12, 2014 3:30 PM
>> *To:* Todd Maugh; freeipa-users at redhat.com
>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>
>> On 03/12/2014 04:18 PM, Todd Maugh wrote:
>>> Hello.
>>>
>>> I'm using latest IPA build on red hat 6.5
>>>
>>> I retrieved my CA cert from the AD Domain controller
>>>
>>> I try to set up my winsyncagreement and I am getting this
>>>
>>>
>>>
>>> [root at idm-master-els.ops.boingo.com ipa]$ ipa-replica-manage connect 
>>> --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" 
>>> --bindpw "XXXXXX" --passsync "XXXXXX" 
>>> --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
>>> Directory Manager password:
>>>
>>> Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to 
>>> certificate database for idm-master-els.ops.boingo.com
>>> ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
>>> ipa: INFO: The error was: {'info': '80090308: LdapErr: 
>>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, 
>>> v2580', 'desc': 'Invalid credentials'}
>>> Failed to setup winsync replication
>>>
>>>
>>> not sure where to look for the logs for this to see what the 
>>> invalivd credentials are or wether this might still be a cert issue 
>>> or a log in issue or what not?
>>
>> You can test with ldapsearch like this:
>>
>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ 
>> -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" 
>> -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"
>>
>>>
>>>
>>> Thanks in advance for the help
>>>
>>> -Todd
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/d40b1105/attachment.htm>

From tmaugh at boingo.com  Thu Mar 13 18:50:38 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 13 Mar 2014 18:50:38 +0000
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <5321FC5E.1070101@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>,
	<5321FC5E.1070101@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E229730C@EXCHMB1-ELS.BWINC.local>

Ok the error I see repeated in the log is

[13/Mar/2014:18:41:21 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:11 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:14 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:56 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:44:30 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success)
[13/Mar/2014:18:44:33 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:44:44 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:46:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:29 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:38 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:50 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:11 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:14 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:56 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[root at idm-master-els.ops.boingo.com cacerts]$

________________________________
From: Rich Megginson [rmeggins at redhat.com]
Sent: Thursday, March 13, 2014 11:43 AM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 12:29 PM, Todd Maugh wrote:
ok so I ran that and Get this output

Ok.  Next, take a look at /var/log/dirsrv/slapd-OPS-BOINGO-COM/errors



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local"
dn: cn=Users,dc=bwinc,dc=local
objectClass: top
objectClass: container
cn: Users
description: Default container for upgraded user accounts
distinguishedName: CN=Users,DC=BWINC,DC=local
instanceType: 4
whenCreated: 20060824234034.0Z
whenChanged: 20140306190741.0Z
uSNCreated: 17702
uSNChanged: 17702
showInAdvancedViewOnly: FALSE
name: Users
objectGUID:: kCZ7CbnIZk+0GpmCr3PCfw==
systemFlags: -1946157056
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=BWINC,DC=local
isCriticalSystemObject: TRUE
dSCorePropagationData: 20140306234416.0Z
dSCorePropagationData: 20140306234348.0Z
dSCorePropagationData: 20140306225101.0Z
dSCorePropagationData: 20140306225055.0Z
dSCorePropagationData: 16010101000000.0Z

________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:47 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:39 PM, Todd Maugh wrote:
thanks Rich,

when I run that  I get the following:


[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
ldap_bind: Invalid credentials (49)

Invalid credentials almost always means your password "XXXXXX" is not correct for user "cn=idmadmin,cn=Users,dc=bwinc,dc=local"

    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580



________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:30 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:18 PM, Todd Maugh wrote:
Hello.

I'm using latest IPA build on red hat 6.5

I retrieved my CA cert from the AD Domain controller

I try to set up my winsyncagreement and I am getting this



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ ipa-replica-manage connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to certificate database for idm-master-els.ops.boingo.com
ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 'Invalid credentials'}
Failed to setup winsync replication


not sure where to look for the logs for this to see what the invalivd credentials are or wether this might still be a cert issue or a log in issue or what not?

You can test with ldapsearch like this:

$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"



Thanks in advance for the help

-Todd





_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/d6e6da3d/attachment.htm>

From rmeggins at redhat.com  Thu Mar 13 19:05:22 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 13 Mar 2014 13:05:22 -0600
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229730C@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>,
	<5321FC5E.1070101@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229730C@EXCHMB1-ELS.BWINC.local>
Message-ID: <53220172.8030700@redhat.com>

On 03/13/2014 12:50 PM, Todd Maugh wrote:
> Ok the error I see repeated in the log is
>
> [13/Mar/2014:18:41:21 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:43:11 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:43:14 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:43:20 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:43:32 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:43:56 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:44:30 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success)
> [13/Mar/2014:18:44:33 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:44:44 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:46:20 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:47:29 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:47:32 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:47:38 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:47:50 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:48:11 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:48:14 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:48:20 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:48:32 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:18:48:56 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [root at idm-master-els.ops.boingo.com cacerts]$

Are all of these associated with the winsync agreement?

>
> ------------------------------------------------------------------------
> *From:* Rich Megginson [rmeggins at redhat.com]
> *Sent:* Thursday, March 13, 2014 11:43 AM
> *To:* Todd Maugh; freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>
> On 03/13/2014 12:29 PM, Todd Maugh wrote:
>> ok so I ran that and Get this output
>
> Ok.  Next, take a look at /var/log/dirsrv/slapd-OPS-BOINGO-COM/errors
>
>>
>>
>> [root at idm-master-els.ops.boingo.com cacerts]$ 
>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ 
>> -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" 
>> -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local"
>> dn: cn=Users,dc=bwinc,dc=local
>> objectClass: top
>> objectClass: container
>> cn: Users
>> description: Default container for upgraded user accounts
>> distinguishedName: CN=Users,DC=BWINC,DC=local
>> instanceType: 4
>> whenCreated: 20060824234034.0Z
>> whenChanged: 20140306190741.0Z
>> uSNCreated: 17702
>> uSNChanged: 17702
>> showInAdvancedViewOnly: FALSE
>> name: Users
>> objectGUID:: kCZ7CbnIZk+0GpmCr3PCfw==
>> systemFlags: -1946157056
>> objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=BWINC,DC=local
>> isCriticalSystemObject: TRUE
>> dSCorePropagationData: 20140306234416.0Z
>> dSCorePropagationData: 20140306234348.0Z
>> dSCorePropagationData: 20140306225101.0Z
>> dSCorePropagationData: 20140306225055.0Z
>> dSCorePropagationData: 16010101000000.0Z
>>
>> ------------------------------------------------------------------------
>> *From:* Rich Megginson [rmeggins at redhat.com]
>> *Sent:* Wednesday, March 12, 2014 3:47 PM
>> *To:* Todd Maugh; freeipa-users at redhat.com
>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>
>> On 03/12/2014 04:39 PM, Todd Maugh wrote:
>>> thanks Rich,
>>>
>>> when I run that  I get the following:
>>>
>>>
>>> *[root at idm-master-els.ops.boingo.com ipa]$ 
>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch 
>>> -xLLLZZ -h adc13-els.bwinc.local -D 
>>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b 
>>> "cn=Users,dc=bwinc,dc=local"
>>> ldap_bind: Invalid credentials (49)
>>> *
>>
>> *Invalid credentials almost always means your password "XXXXXX" is 
>> not correct for user "**cn=idmadmin,cn=Users,dc=bwinc,dc=local"
>>
>> *
>>> *    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: 
>>> AcceptSecurityContext error, data 52e, v2580
>>> *
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>> *Sent:* Wednesday, March 12, 2014 3:30 PM
>>> *To:* Todd Maugh; freeipa-users at redhat.com
>>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>>
>>> On 03/12/2014 04:18 PM, Todd Maugh wrote:
>>>> Hello.
>>>>
>>>> I'm using latest IPA build on red hat 6.5
>>>>
>>>> I retrieved my CA cert from the AD Domain controller
>>>>
>>>> I try to set up my winsyncagreement and I am getting this
>>>>
>>>>
>>>>
>>>> [root at idm-master-els.ops.boingo.com ipa]$ ipa-replica-manage 
>>>> connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, 
>>>> dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" 
>>>> --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
>>>> Directory Manager password:
>>>>
>>>> Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to 
>>>> certificate database for idm-master-els.ops.boingo.com
>>>> ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
>>>> ipa: INFO: The error was: {'info': '80090308: LdapErr: 
>>>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, 
>>>> v2580', 'desc': 'Invalid credentials'}
>>>> Failed to setup winsync replication
>>>>
>>>>
>>>> not sure where to look for the logs for this to see what the 
>>>> invalivd credentials are or wether this might still be a cert issue 
>>>> or a log in issue or what not?
>>>
>>> You can test with ldapsearch like this:
>>>
>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ 
>>> -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" 
>>> -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"
>>>
>>>>
>>>>
>>>> Thanks in advance for the help
>>>>
>>>> -Todd
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeipa-users mailing list
>>>> Freeipa-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/a3112b18/attachment.htm>

From tmaugh at boingo.com  Thu Mar 13 19:58:50 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 13 Mar 2014 19:58:50 +0000
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <53220172.8030700@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>,
	<5321FC5E.1070101@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229730C@EXCHMB1-ELS.BWINC.local>,
	<53220172.8030700@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E229744B@EXCHMB1-ELS.BWINC.local>

I believe they are.

so here is the out put of the log. it was showing those errors, I deleted the wynsync agreement and then restarted ipa and then readded the winsync and the errors returned. could this be a cert issue?

[13/Mar/2014:19:48:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:48:44 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:49:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:51:08 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)

here I removed the winsync agreement :ipa-replica-manage del adc13-els.bwinc.local
then restartd ipa

ipactl restart

[13/Mar/2014:19:51:50 +0000] NSMMReplicationPlugin - agmt_delete: begin
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - signaling operation threads
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - waiting for 29 threads to terminate
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - closing down internal subsystems and plugins
[13/Mar/2014:19:51:59 +0000] - Waiting for 4 database threads to stop
[13/Mar/2014:19:51:59 +0000] - All database threads now stopped
[13/Mar/2014:19:51:59 +0000] - slapd stopped.
[13/Mar/2014:19:52:14 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:52:14 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/idm-master-els.ops.boingo.com at OPS.BOINGO.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
[13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:52:14 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success)
[13/Mar/2014:19:52:14 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
[13/Mar/2014:19:52:14 +0000] NSMMReplicationPlugin - agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found))
[13/Mar/2014:19:52:14 +0000] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[13/Mar/2014:19:52:14 +0000] - Listening on All Interfaces port 636 for LDAPS requests
[13/Mar/2014:19:52:14 +0000] - Listening on /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
[13/Mar/2014:19:52:18 +0000] NSMMReplicationPlugin - agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): Replication bind with GSSAPI auth resumed

here i added the winsync agreement again

[13/Mar/2014:19:53:16 +0000] - slapd shutting down - signaling operation threads
[13/Mar/2014:19:53:16 +0000] - slapd shutting down - waiting for 30 threads to terminate
[13/Mar/2014:19:53:16 +0000] - slapd shutting down - closing down internal subsystems and plugins
[13/Mar/2014:19:53:16 +0000] - Waiting for 4 database threads to stop
[13/Mar/2014:19:53:16 +0000] - All database threads now stopped
[13/Mar/2014:19:53:16 +0000] - slapd stopped.
[13/Mar/2014:19:53:20 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:53:20 +0000] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[13/Mar/2014:19:53:20 +0000] - Listening on All Interfaces port 636 for LDAPS requests
[13/Mar/2014:19:53:20 +0000] - Listening on /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:22 +0000] NSMMReplicationPlugin - agmt="cn=meToadc13-els.bwinc.local" (adc13-els:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's Certificate issuer is not recognized.)
[13/Mar/2014:19:53:22 +0000] - Entry "cn=meToadc13-els.bwinc.local,cn=replica,cn=dc\3Dops\2Cdc\3Dboingo\2Cdc\3Dcom,cn=mapping tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not allowed
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)


________________________________
From: Rich Megginson [rmeggins at redhat.com]
Sent: Thursday, March 13, 2014 12:05 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 12:50 PM, Todd Maugh wrote:
Ok the error I see repeated in the log is

[13/Mar/2014:18:41:21 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:11 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:14 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:56 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:44:30 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success)
[13/Mar/2014:18:44:33 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:44:44 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:46:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:29 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:38 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:50 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:11 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:14 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:56 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$

Are all of these associated with the winsync agreement?


________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Thursday, March 13, 2014 11:43 AM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 12:29 PM, Todd Maugh wrote:
ok so I ran that and Get this output

Ok.  Next, take a look at /var/log/dirsrv/slapd-OPS-BOINGO-COM/errors



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local"
dn: cn=Users,dc=bwinc,dc=local
objectClass: top
objectClass: container
cn: Users
description: Default container for upgraded user accounts
distinguishedName: CN=Users,DC=BWINC,DC=local
instanceType: 4
whenCreated: 20060824234034.0Z
whenChanged: 20140306190741.0Z
uSNCreated: 17702
uSNChanged: 17702
showInAdvancedViewOnly: FALSE
name: Users
objectGUID:: kCZ7CbnIZk+0GpmCr3PCfw==
systemFlags: -1946157056
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=BWINC,DC=local
isCriticalSystemObject: TRUE
dSCorePropagationData: 20140306234416.0Z
dSCorePropagationData: 20140306234348.0Z
dSCorePropagationData: 20140306225101.0Z
dSCorePropagationData: 20140306225055.0Z
dSCorePropagationData: 16010101000000.0Z

________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:47 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:39 PM, Todd Maugh wrote:
thanks Rich,

when I run that  I get the following:


[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
ldap_bind: Invalid credentials (49)

Invalid credentials almost always means your password "XXXXXX" is not correct for user "cn=idmadmin,cn=Users,dc=bwinc,dc=local"

    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580



________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:30 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:18 PM, Todd Maugh wrote:
Hello.

I'm using latest IPA build on red hat 6.5

I retrieved my CA cert from the AD Domain controller

I try to set up my winsyncagreement and I am getting this



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ ipa-replica-manage connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to certificate database for idm-master-els.ops.boingo.com
ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 'Invalid credentials'}
Failed to setup winsync replication


not sure where to look for the logs for this to see what the invalivd credentials are or wether this might still be a cert issue or a log in issue or what not?

You can test with ldapsearch like this:

$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"



Thanks in advance for the help

-Todd





_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/6190f8ee/attachment.htm>

From rmeggins at redhat.com  Thu Mar 13 20:29:15 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 13 Mar 2014 14:29:15 -0600
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229744B@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>,
	<5321FC5E.1070101@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229730C@EXCHMB1-ELS.BWINC.local>,
	<53220172.8030700@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229744B@EXCHMB1-ELS.BWINC.local>
Message-ID: <5322151B.2040101@redhat.com>

On 03/13/2014 01:58 PM, Todd Maugh wrote:
> I believe they are.
>
> so here is the out put of the log. it was showing those errors, I 
> deleted the wynsync agreement and then restarted ipa and then readded 
> the winsync and the errors returned. could this be a cert issue?
>
> [13/Mar/2014:19:48:20 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:19:48:44 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:19:49:32 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:19:51:08 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
>
> here I removed the winsync agreement :ipa-replica-manage del 
> adc13-els.bwinc.local
> then restartd ipa
>
> ipactl restart
>
> [13/Mar/2014:19:51:50 +0000] NSMMReplicationPlugin - agmt_delete: begin
> [13/Mar/2014:19:51:59 +0000] - slapd shutting down - signaling 
> operation threads
> [13/Mar/2014:19:51:59 +0000] - slapd shutting down - waiting for 29 
> threads to terminate
> [13/Mar/2014:19:51:59 +0000] - slapd shutting down - closing down 
> internal subsystems and plugins
> [13/Mar/2014:19:51:59 +0000] - Waiting for 4 database threads to stop
> [13/Mar/2014:19:51:59 +0000] - All database threads now stopped
> [13/Mar/2014:19:51:59 +0000] - slapd stopped.
> [13/Mar/2014:19:52:14 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 
> starting up
> [13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no 
> entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
> [13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no 
> entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
> [13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no 
> entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
> [13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, 
> which should be added before the CoS Definition.
> [13/Mar/2014:19:52:14 +0000] set_krb5_creds - Could not get initial 
> credentials for principal 
> [ldap/idm-master-els.ops.boingo.com at OPS.BOINGO.COM] in keytab 
> [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
> [13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, 
> which should be added before the CoS Definition.
> [13/Mar/2014:19:52:14 +0000] slapd_ldap_sasl_interactive_bind - Error: 
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
> -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified 
> GSS failure.  Minor code may provide more information (Credentials 
> cache file '/tmp/krb5cc_495' not found)) errno 0 (Success)
> [13/Mar/2014:19:52:14 +0000] slapi_ldap_bind - Error: could not 
> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
> [13/Mar/2014:19:52:14 +0000] NSMMReplicationPlugin - 
> agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): 
> Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) 
> (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
> Minor code may provide more information (Credentials cache file 
> '/tmp/krb5cc_495' not found))
> [13/Mar/2014:19:52:14 +0000] - slapd started.  Listening on All 
> Interfaces port 389 for LDAP requests
> [13/Mar/2014:19:52:14 +0000] - Listening on All Interfaces port 636 
> for LDAPS requests
> [13/Mar/2014:19:52:14 +0000] - Listening on 
> /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
> [13/Mar/2014:19:52:18 +0000] NSMMReplicationPlugin - 
> agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): 
> Replication bind with GSSAPI auth resumed
>
> here i added the winsync agreement again
>
> [13/Mar/2014:19:53:16 +0000] - slapd shutting down - signaling 
> operation threads
> [13/Mar/2014:19:53:16 +0000] - slapd shutting down - waiting for 30 
> threads to terminate
> [13/Mar/2014:19:53:16 +0000] - slapd shutting down - closing down 
> internal subsystems and plugins
> [13/Mar/2014:19:53:16 +0000] - Waiting for 4 database threads to stop
> [13/Mar/2014:19:53:16 +0000] - All database threads now stopped
> [13/Mar/2014:19:53:16 +0000] - slapd stopped.
> [13/Mar/2014:19:53:20 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 
> starting up
> [13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no 
> entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
> [13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no 
> entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
> [13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no 
> entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
> [13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, 
> which should be added before the CoS Definition.
> [13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, 
> which should be added before the CoS Definition.
> [13/Mar/2014:19:53:20 +0000] - slapd started.  Listening on All 
> Interfaces port 389 for LDAP requests
> [13/Mar/2014:19:53:20 +0000] - Listening on All Interfaces port 636 
> for LDAPS requests
> [13/Mar/2014:19:53:20 +0000] - Listening on 
> /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
> [13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:19:53:22 +0000] NSMMReplicationPlugin - 
> agmt="cn=meToadc13-els.bwinc.local" (adc13-els:389): Replication bind 
> with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error 
> -8179:Peer's Certificate issuer is not recognized.)

This is seems like a cert issue.  "Peer's" the AD server "Certificate 
issuer" the CA that issued the AD server cert "is not recognized" IdM 
has no knowledge of the CA cert.

But you verified that ldapsearch was working?  LDAPTLS_CACERTDIR tells 
ldapsearch to use /etc/dirsrv/slapd-OPS-BOINGO-COM, which is the same as 
winsync is using.

Try doing the ldapsearch again, like this:

[root at idm-master-els.ops.boingo.com cacerts]$ 
LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 
-xLLLZZ -h adc13-els.bwinc.local -D 
"cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b 
"cn=Users,dc=bwinc,dc=local" "objectclass=*" dn

The -d 1 will make it spew debugging information.  Perhaps ldapsearch is 
picking up some option from /etc/openldap/ldap.conf or ~/.ldaprc which 
tells it to ignore certificate verification.

> [13/Mar/2014:19:53:22 +0000] - Entry 
> "cn=meToadc13-els.bwinc.local,cn=replica,cn=dc\3Dops\2Cdc\3Dboingo\2Cdc\3Dcom,cn=mapping 
> tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not 
> allowed
> [13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
> [13/Mar/2014:19:53:25 +0000] slapi_ldap_bind - Error: could not send 
> startTLS request: error -11 (Connect error) errno 0 (Success)
>
>
> ------------------------------------------------------------------------
> *From:* Rich Megginson [rmeggins at redhat.com]
> *Sent:* Thursday, March 13, 2014 12:05 PM
> *To:* Todd Maugh; freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>
> On 03/13/2014 12:50 PM, Todd Maugh wrote:
>> Ok the error I see repeated in the log is
>>
>> [13/Mar/2014:18:41:21 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:43:11 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:43:14 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:43:20 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:43:32 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:43:56 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:44:30 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success)
>> [13/Mar/2014:18:44:33 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:44:44 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:46:20 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:47:29 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:47:32 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:47:38 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:47:50 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:48:11 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:48:14 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:48:20 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:48:32 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:18:48:56 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [root at idm-master-els.ops.boingo.com cacerts]$
>
> Are all of these associated with the winsync agreement?
>
>>
>> ------------------------------------------------------------------------
>> *From:* Rich Megginson [rmeggins at redhat.com]
>> *Sent:* Thursday, March 13, 2014 11:43 AM
>> *To:* Todd Maugh; freeipa-users at redhat.com
>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>
>> On 03/13/2014 12:29 PM, Todd Maugh wrote:
>>> ok so I ran that and Get this output
>>
>> Ok.  Next, take a look at /var/log/dirsrv/slapd-OPS-BOINGO-COM/errors
>>
>>>
>>>
>>> [root at idm-master-els.ops.boingo.com cacerts]$ 
>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch 
>>> -xLLLZZ -h adc13-els.bwinc.local -D 
>>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b 
>>> "cn=Users,dc=bwinc,dc=local"
>>> dn: cn=Users,dc=bwinc,dc=local
>>> objectClass: top
>>> objectClass: container
>>> cn: Users
>>> description: Default container for upgraded user accounts
>>> distinguishedName: CN=Users,DC=BWINC,DC=local
>>> instanceType: 4
>>> whenCreated: 20060824234034.0Z
>>> whenChanged: 20140306190741.0Z
>>> uSNCreated: 17702
>>> uSNChanged: 17702
>>> showInAdvancedViewOnly: FALSE
>>> name: Users
>>> objectGUID:: kCZ7CbnIZk+0GpmCr3PCfw==
>>> systemFlags: -1946157056
>>> objectCategory: 
>>> CN=Container,CN=Schema,CN=Configuration,DC=BWINC,DC=local
>>> isCriticalSystemObject: TRUE
>>> dSCorePropagationData: 20140306234416.0Z
>>> dSCorePropagationData: 20140306234348.0Z
>>> dSCorePropagationData: 20140306225101.0Z
>>> dSCorePropagationData: 20140306225055.0Z
>>> dSCorePropagationData: 16010101000000.0Z
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>> *Sent:* Wednesday, March 12, 2014 3:47 PM
>>> *To:* Todd Maugh; freeipa-users at redhat.com
>>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>>
>>> On 03/12/2014 04:39 PM, Todd Maugh wrote:
>>>> thanks Rich,
>>>>
>>>> when I run that  I get the following:
>>>>
>>>>
>>>> *[root at idm-master-els.ops.boingo.com ipa]$ 
>>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch 
>>>> -xLLLZZ -h adc13-els.bwinc.local -D 
>>>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b 
>>>> "cn=Users,dc=bwinc,dc=local"
>>>> ldap_bind: Invalid credentials (49)
>>>> *
>>>
>>> *Invalid credentials almost always means your password "XXXXXX" is 
>>> not correct for user "**cn=idmadmin,cn=Users,dc=bwinc,dc=local"
>>>
>>> *
>>>> *additional info: 80090308: LdapErr: DSID-0C0903C5, comment: 
>>>> AcceptSecurityContext error, data 52e, v2580
>>>> *
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>>> *Sent:* Wednesday, March 12, 2014 3:30 PM
>>>> *To:* Todd Maugh; freeipa-users at redhat.com
>>>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>>>
>>>> On 03/12/2014 04:18 PM, Todd Maugh wrote:
>>>>> Hello.
>>>>>
>>>>> I'm using latest IPA build on red hat 6.5
>>>>>
>>>>> I retrieved my CA cert from the AD Domain controller
>>>>>
>>>>> I try to set up my winsyncagreement and I am getting this
>>>>>
>>>>>
>>>>>
>>>>> [root at idm-master-els.ops.boingo.com ipa]$ ipa-replica-manage 
>>>>> connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, 
>>>>> dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" 
>>>>> --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
>>>>> Directory Manager password:
>>>>>
>>>>> Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to 
>>>>> certificate database for idm-master-els.ops.boingo.com
>>>>> ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
>>>>> ipa: INFO: The error was: {'info': '80090308: LdapErr: 
>>>>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, 
>>>>> v2580', 'desc': 'Invalid credentials'}
>>>>> Failed to setup winsync replication
>>>>>
>>>>>
>>>>> not sure where to look for the logs for this to see what the 
>>>>> invalivd credentials are or wether this might still be a cert 
>>>>> issue or a log in issue or what not?
>>>>
>>>> You can test with ldapsearch like this:
>>>>
>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ 
>>>> -h adc13-els.bwinc.local -D 
>>>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b 
>>>> "cn=Users,dc=bwinc,dc=local"
>>>>
>>>>>
>>>>>
>>>>> Thanks in advance for the help
>>>>>
>>>>> -Todd
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Freeipa-users mailing list
>>>>> Freeipa-users at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/c77411e9/attachment.htm>

From tmaugh at boingo.com  Thu Mar 13 20:47:41 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 13 Mar 2014 20:47:41 +0000
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <5322151B.2040101@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>,
	<5321FC5E.1070101@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229730C@EXCHMB1-ELS.BWINC.local>,
	<53220172.8030700@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229744B@EXCHMB1-ELS.BWINC.local>,
	<5322151B.2040101@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E2297527@EXCHMB1-ELS.BWINC.local>

thank you Rich for all your help as I am inclined to think its a cert issue as well

so I ran the new command, and there are some lines that stick out to me in reference to the cert:

[root at idm-master-els.ops.boingo.com ~]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "g0_b0ing0" -s base -b "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn
ldap_create
ldap_url_parse_ext(ldap://adc13-els.bwinc.local)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP adc13-els.bwinc.local:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 172.22.170.13:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 31 bytes to sd 3
ldap_result ld 0x25c4210 msgid 1
wait4msg ld 0x25c4210 msgid 1 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid 1 all 1
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid 1 all 1
ldap_chkResponseList returns ld 0x25c4210 NULL
ldap_int_select
read1msg: ld 0x25c4210 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 40 contents:
read1msg: ld 0x25c4210 msgid 1 message type extended-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x25c4210 0 new referrals
read1msg:  mark request completed, ld 0x25c4210 msgid 1
request done: ld 0x25c4210 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_extended_result
ber_scanf fmt ({eAA) ber:
ber_scanf fmt (a) ber:
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (x) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
TLS: certdb config: configDir='/etc/dirsrv/slapd-OPS-BOINGO-COM' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly
TLS: using moznss security dir /etc/dirsrv/slapd-OPS-BOINGO-COM prefix .
TLS: error: the certificate file /etc/openldap/cacerts/ is not a file.
TLS: /etc/openldap/cacerts/ is not a valid CA certificate file - error -5953:Cannot perform a normal file operation on a directory.
TLS: certificate [CN=ADC13-ELS.BWINC.local] is not valid - error -8179:Peer's Certificate issuer is not recognized..
TLS certificate verification: subject: CN=ADC13-ELS.BWINC.local, issuer: CN=BoingoWirelessCA,DC=BWINC,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 61 bytes to sd 3
ldap_result ld 0x25c4210 msgid 2
wait4msg ld 0x25c4210 msgid 2 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid 2 all 1
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid 2 all 1
ldap_chkResponseList returns ld 0x25c4210 NULL
ldap_int_select
read1msg: ld 0x25c4210 msgid 2 all 1
ber_get_next
ber_get_next: tag 0x30 len 16 contents:
read1msg: ld 0x25c4210 msgid 2 message type bind
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x25c4210 0 new referrals
read1msg:  mark request completed, ld 0x25c4210 msgid 2
request done: ld 0x25c4210 msgid 2
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_search_ext
put_filter: "objectclass=*"
put_filter: default
put_simple_filter: "objectclass=*"
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 69 bytes to sd 3
ldap_result ld 0x25c4210 msgid -1
wait4msg ld 0x25c4210 msgid -1 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid -1 all 0
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 3,  origid 3, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid -1 all 0
ldap_chkResponseList returns ld 0x25c4210 NULL
ldap_int_select
read1msg: ld 0x25c4210 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 43 contents:
read1msg: ld 0x25c4210 msgid 3 message type search-entry
ldap_get_dn_ber
ber_scanf fmt ({ml{) ber:
dn: cn=Users,dc=bwinc,dc=local
ber_scanf fmt ({xx) ber:
ldap_get_attribute_ber
ldap_msgfree
ldap_result ld 0x25c4210 msgid -1
wait4msg ld 0x25c4210 msgid -1 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid -1 all 0
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 3,  origid 3, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid -1 all 0
ldap_chkResponseList returns ld 0x25c4210 NULL
read1msg: ld 0x25c4210 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 16 contents:
read1msg: ld 0x25c4210 msgid 3 message type search-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x25c4210 0 new referrals
read1msg:  mark request completed, ld 0x25c4210 msgid 3
request done: ld 0x25c4210 msgid 3
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 3, msgid 3)

ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 3
ldap_free_connection: actually freed

________________________________
From: Rich Megginson [rmeggins at redhat.com]
Sent: Thursday, March 13, 2014 1:29 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 01:58 PM, Todd Maugh wrote:
I believe they are.

so here is the out put of the log. it was showing those errors, I deleted the wynsync agreement and then restarted ipa and then readded the winsync and the errors returned. could this be a cert issue?

[13/Mar/2014:19:48:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:48:44 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:49:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:51:08 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)

here I removed the winsync agreement :ipa-replica-manage del adc13-els.bwinc.local
then restartd ipa

ipactl restart

[13/Mar/2014:19:51:50 +0000] NSMMReplicationPlugin - agmt_delete: begin
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - signaling operation threads
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - waiting for 29 threads to terminate
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - closing down internal subsystems and plugins
[13/Mar/2014:19:51:59 +0000] - Waiting for 4 database threads to stop
[13/Mar/2014:19:51:59 +0000] - All database threads now stopped
[13/Mar/2014:19:51:59 +0000] - slapd stopped.
[13/Mar/2014:19:52:14 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:52:14 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/idm-master-els.ops.boingo.com at OPS.BOINGO.COM<mailto:ldap/idm-master-els.ops.boingo.com at OPS.BOINGO.COM>] in keytab [FILE:/etc/dirsrv/ds.keytab<UrlBlockedError.aspx>]: -1765328324 (Generic error (see e-text))
[13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:52:14 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success)
[13/Mar/2014:19:52:14 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
[13/Mar/2014:19:52:14 +0000] NSMMReplicationPlugin - agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found))
[13/Mar/2014:19:52:14 +0000] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[13/Mar/2014:19:52:14 +0000] - Listening on All Interfaces port 636 for LDAPS requests
[13/Mar/2014:19:52:14 +0000] - Listening on /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
[13/Mar/2014:19:52:18 +0000] NSMMReplicationPlugin - agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): Replication bind with GSSAPI auth resumed

here i added the winsync agreement again

[13/Mar/2014:19:53:16 +0000] - slapd shutting down - signaling operation threads
[13/Mar/2014:19:53:16 +0000] - slapd shutting down - waiting for 30 threads to terminate
[13/Mar/2014:19:53:16 +0000] - slapd shutting down - closing down internal subsystems and plugins
[13/Mar/2014:19:53:16 +0000] - Waiting for 4 database threads to stop
[13/Mar/2014:19:53:16 +0000] - All database threads now stopped
[13/Mar/2014:19:53:16 +0000] - slapd stopped.
[13/Mar/2014:19:53:20 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:53:20 +0000] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[13/Mar/2014:19:53:20 +0000] - Listening on All Interfaces port 636 for LDAPS requests
[13/Mar/2014:19:53:20 +0000] - Listening on /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:22 +0000] NSMMReplicationPlugin - agmt="cn=meToadc13-els.bwinc.local" (adc13-els:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's Certificate issuer is not recognized.)

This is seems like a cert issue.  "Peer's" the AD server "Certificate issuer" the CA that issued the AD server cert "is not recognized" IdM has no knowledge of the CA cert.

But you verified that ldapsearch was working?  LDAPTLS_CACERTDIR tells ldapsearch to use /etc/dirsrv/slapd-OPS-BOINGO-COM, which is the same as winsync is using.

Try doing the ldapsearch again, like this:

[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn

The -d 1 will make it spew debugging information.  Perhaps ldapsearch is picking up some option from /etc/openldap/ldap.conf or ~/.ldaprc which tells it to ignore certificate verification.

[13/Mar/2014:19:53:22 +0000] - Entry "cn=meToadc13-els.bwinc.local,cn=replica,cn=dc\3Dops\2Cdc\3Dboingo\2Cdc\3Dcom,cn=mapping tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not allowed
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)


________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Thursday, March 13, 2014 12:05 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 12:50 PM, Todd Maugh wrote:
Ok the error I see repeated in the log is

[13/Mar/2014:18:41:21 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:11 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:14 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:56 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:44:30 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success)
[13/Mar/2014:18:44:33 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:44:44 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:46:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:29 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:38 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:50 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:11 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:14 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:56 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$

Are all of these associated with the winsync agreement?


________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Thursday, March 13, 2014 11:43 AM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 12:29 PM, Todd Maugh wrote:
ok so I ran that and Get this output

Ok.  Next, take a look at /var/log/dirsrv/slapd-OPS-BOINGO-COM/errors



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local"
dn: cn=Users,dc=bwinc,dc=local
objectClass: top
objectClass: container
cn: Users
description: Default container for upgraded user accounts
distinguishedName: CN=Users,DC=BWINC,DC=local
instanceType: 4
whenCreated: 20060824234034.0Z
whenChanged: 20140306190741.0Z
uSNCreated: 17702
uSNChanged: 17702
showInAdvancedViewOnly: FALSE
name: Users
objectGUID:: kCZ7CbnIZk+0GpmCr3PCfw==
systemFlags: -1946157056
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=BWINC,DC=local
isCriticalSystemObject: TRUE
dSCorePropagationData: 20140306234416.0Z
dSCorePropagationData: 20140306234348.0Z
dSCorePropagationData: 20140306225101.0Z
dSCorePropagationData: 20140306225055.0Z
dSCorePropagationData: 16010101000000.0Z

________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:47 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:39 PM, Todd Maugh wrote:
thanks Rich,

when I run that  I get the following:


[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
ldap_bind: Invalid credentials (49)

Invalid credentials almost always means your password "XXXXXX" is not correct for user "cn=idmadmin,cn=Users,dc=bwinc,dc=local"

    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580



________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:30 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:18 PM, Todd Maugh wrote:
Hello.

I'm using latest IPA build on red hat 6.5

I retrieved my CA cert from the AD Domain controller

I try to set up my winsyncagreement and I am getting this



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ ipa-replica-manage connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to certificate database for idm-master-els.ops.boingo.com
ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 'Invalid credentials'}
Failed to setup winsync replication


not sure where to look for the logs for this to see what the invalivd credentials are or wether this might still be a cert issue or a log in issue or what not?

You can test with ldapsearch like this:

$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"



Thanks in advance for the help

-Todd





_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/3b908692/attachment.htm>

From tmaugh at boingo.com  Thu Mar 13 20:49:00 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 13 Mar 2014 20:49:00 +0000
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2297527@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>,
	<5321FC5E.1070101@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229730C@EXCHMB1-ELS.BWINC.local>,
	<53220172.8030700@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229744B@EXCHMB1-ELS.BWINC.local>,
	<5322151B.2040101@redhat.com>,
	<6FB698E172A95F49BE009B36D56F53E2297527@EXCHMB1-ELS.BWINC.local>
Message-ID: <6FB698E172A95F49BE009B36D56F53E2297543@EXCHMB1-ELS.BWINC.local>

I'm curious if the ldap.conf is wrong: heres what it looks like

#File modified by ipa-client-install

URI ldaps://idm-master-els.ops.boingo.com
BASE dc=ops,dc=boingo,dc=com
TLS_CACERT /etc/openldap/cacerts/
TLS_REQCERT allow

________________________________
From: Todd Maugh
Sent: Thursday, March 13, 2014 1:47 PM
To: Rich Megginson; freeipa-users at redhat.com
Subject: RE: [Freeipa-users] [freeipa] Issues with Winsync agreement

thank you Rich for all your help as I am inclined to think its a cert issue as well

so I ran the new command, and there are some lines that stick out to me in reference to the cert:

[root at idm-master-els.ops.boingo.com ~]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "g0_b0ing0" -s base -b "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn
ldap_create
ldap_url_parse_ext(ldap://adc13-els.bwinc.local)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP adc13-els.bwinc.local:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 172.22.170.13:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 31 bytes to sd 3
ldap_result ld 0x25c4210 msgid 1
wait4msg ld 0x25c4210 msgid 1 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid 1 all 1
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid 1 all 1
ldap_chkResponseList returns ld 0x25c4210 NULL
ldap_int_select
read1msg: ld 0x25c4210 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 40 contents:
read1msg: ld 0x25c4210 msgid 1 message type extended-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x25c4210 0 new referrals
read1msg:  mark request completed, ld 0x25c4210 msgid 1
request done: ld 0x25c4210 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_extended_result
ber_scanf fmt ({eAA) ber:
ber_scanf fmt (a) ber:
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (x) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
TLS: certdb config: configDir='/etc/dirsrv/slapd-OPS-BOINGO-COM' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly
TLS: using moznss security dir /etc/dirsrv/slapd-OPS-BOINGO-COM prefix .
TLS: error: the certificate file /etc/openldap/cacerts/ is not a file.
TLS: /etc/openldap/cacerts/ is not a valid CA certificate file - error -5953:Cannot perform a normal file operation on a directory.
TLS: certificate [CN=ADC13-ELS.BWINC.local] is not valid - error -8179:Peer's Certificate issuer is not recognized..
TLS certificate verification: subject: CN=ADC13-ELS.BWINC.local, issuer: CN=BoingoWirelessCA,DC=BWINC,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 61 bytes to sd 3
ldap_result ld 0x25c4210 msgid 2
wait4msg ld 0x25c4210 msgid 2 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid 2 all 1
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid 2 all 1
ldap_chkResponseList returns ld 0x25c4210 NULL
ldap_int_select
read1msg: ld 0x25c4210 msgid 2 all 1
ber_get_next
ber_get_next: tag 0x30 len 16 contents:
read1msg: ld 0x25c4210 msgid 2 message type bind
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x25c4210 0 new referrals
read1msg:  mark request completed, ld 0x25c4210 msgid 2
request done: ld 0x25c4210 msgid 2
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_search_ext
put_filter: "objectclass=*"
put_filter: default
put_simple_filter: "objectclass=*"
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 69 bytes to sd 3
ldap_result ld 0x25c4210 msgid -1
wait4msg ld 0x25c4210 msgid -1 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid -1 all 0
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 3,  origid 3, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid -1 all 0
ldap_chkResponseList returns ld 0x25c4210 NULL
ldap_int_select
read1msg: ld 0x25c4210 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 43 contents:
read1msg: ld 0x25c4210 msgid 3 message type search-entry
ldap_get_dn_ber
ber_scanf fmt ({ml{) ber:
dn: cn=Users,dc=bwinc,dc=local
ber_scanf fmt ({xx) ber:
ldap_get_attribute_ber
ldap_msgfree
ldap_result ld 0x25c4210 msgid -1
wait4msg ld 0x25c4210 msgid -1 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid -1 all 0
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 3,  origid 3, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid -1 all 0
ldap_chkResponseList returns ld 0x25c4210 NULL
read1msg: ld 0x25c4210 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 16 contents:
read1msg: ld 0x25c4210 msgid 3 message type search-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x25c4210 0 new referrals
read1msg:  mark request completed, ld 0x25c4210 msgid 3
request done: ld 0x25c4210 msgid 3
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 3, msgid 3)

ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 3
ldap_free_connection: actually freed

________________________________
From: Rich Megginson [rmeggins at redhat.com]
Sent: Thursday, March 13, 2014 1:29 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 01:58 PM, Todd Maugh wrote:
I believe they are.

so here is the out put of the log. it was showing those errors, I deleted the wynsync agreement and then restarted ipa and then readded the winsync and the errors returned. could this be a cert issue?

[13/Mar/2014:19:48:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:48:44 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:49:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:51:08 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)

here I removed the winsync agreement :ipa-replica-manage del adc13-els.bwinc.local
then restartd ipa

ipactl restart

[13/Mar/2014:19:51:50 +0000] NSMMReplicationPlugin - agmt_delete: begin
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - signaling operation threads
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - waiting for 29 threads to terminate
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - closing down internal subsystems and plugins
[13/Mar/2014:19:51:59 +0000] - Waiting for 4 database threads to stop
[13/Mar/2014:19:51:59 +0000] - All database threads now stopped
[13/Mar/2014:19:51:59 +0000] - slapd stopped.
[13/Mar/2014:19:52:14 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:52:14 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/idm-master-els.ops.boingo.com at OPS.BOINGO.COM<mailto:ldap/idm-master-els.ops.boingo.com at OPS.BOINGO.COM>] in keytab [FILE:/etc/dirsrv/ds.keytab<UrlBlockedError.aspx>]: -1765328324 (Generic error (see e-text))
[13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:52:14 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success)
[13/Mar/2014:19:52:14 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
[13/Mar/2014:19:52:14 +0000] NSMMReplicationPlugin - agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found))
[13/Mar/2014:19:52:14 +0000] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[13/Mar/2014:19:52:14 +0000] - Listening on All Interfaces port 636 for LDAPS requests
[13/Mar/2014:19:52:14 +0000] - Listening on /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
[13/Mar/2014:19:52:18 +0000] NSMMReplicationPlugin - agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): Replication bind with GSSAPI auth resumed

here i added the winsync agreement again

[13/Mar/2014:19:53:16 +0000] - slapd shutting down - signaling operation threads
[13/Mar/2014:19:53:16 +0000] - slapd shutting down - waiting for 30 threads to terminate
[13/Mar/2014:19:53:16 +0000] - slapd shutting down - closing down internal subsystems and plugins
[13/Mar/2014:19:53:16 +0000] - Waiting for 4 database threads to stop
[13/Mar/2014:19:53:16 +0000] - All database threads now stopped
[13/Mar/2014:19:53:16 +0000] - slapd stopped.
[13/Mar/2014:19:53:20 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:53:20 +0000] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[13/Mar/2014:19:53:20 +0000] - Listening on All Interfaces port 636 for LDAPS requests
[13/Mar/2014:19:53:20 +0000] - Listening on /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:22 +0000] NSMMReplicationPlugin - agmt="cn=meToadc13-els.bwinc.local" (adc13-els:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's Certificate issuer is not recognized.)

This is seems like a cert issue.  "Peer's" the AD server "Certificate issuer" the CA that issued the AD server cert "is not recognized" IdM has no knowledge of the CA cert.

But you verified that ldapsearch was working?  LDAPTLS_CACERTDIR tells ldapsearch to use /etc/dirsrv/slapd-OPS-BOINGO-COM, which is the same as winsync is using.

Try doing the ldapsearch again, like this:

[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn

The -d 1 will make it spew debugging information.  Perhaps ldapsearch is picking up some option from /etc/openldap/ldap.conf or ~/.ldaprc which tells it to ignore certificate verification.

[13/Mar/2014:19:53:22 +0000] - Entry "cn=meToadc13-els.bwinc.local,cn=replica,cn=dc\3Dops\2Cdc\3Dboingo\2Cdc\3Dcom,cn=mapping tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not allowed
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)


________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Thursday, March 13, 2014 12:05 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 12:50 PM, Todd Maugh wrote:
Ok the error I see repeated in the log is

[13/Mar/2014:18:41:21 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:11 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:14 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:56 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:44:30 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success)
[13/Mar/2014:18:44:33 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:44:44 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:46:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:29 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:38 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:50 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:11 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:14 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:56 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$

Are all of these associated with the winsync agreement?


________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Thursday, March 13, 2014 11:43 AM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 12:29 PM, Todd Maugh wrote:
ok so I ran that and Get this output

Ok.  Next, take a look at /var/log/dirsrv/slapd-OPS-BOINGO-COM/errors



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local"
dn: cn=Users,dc=bwinc,dc=local
objectClass: top
objectClass: container
cn: Users
description: Default container for upgraded user accounts
distinguishedName: CN=Users,DC=BWINC,DC=local
instanceType: 4
whenCreated: 20060824234034.0Z
whenChanged: 20140306190741.0Z
uSNCreated: 17702
uSNChanged: 17702
showInAdvancedViewOnly: FALSE
name: Users
objectGUID:: kCZ7CbnIZk+0GpmCr3PCfw==
systemFlags: -1946157056
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=BWINC,DC=local
isCriticalSystemObject: TRUE
dSCorePropagationData: 20140306234416.0Z
dSCorePropagationData: 20140306234348.0Z
dSCorePropagationData: 20140306225101.0Z
dSCorePropagationData: 20140306225055.0Z
dSCorePropagationData: 16010101000000.0Z

________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:47 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:39 PM, Todd Maugh wrote:
thanks Rich,

when I run that  I get the following:


[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
ldap_bind: Invalid credentials (49)

Invalid credentials almost always means your password "XXXXXX" is not correct for user "cn=idmadmin,cn=Users,dc=bwinc,dc=local"

    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580



________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:30 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:18 PM, Todd Maugh wrote:
Hello.

I'm using latest IPA build on red hat 6.5

I retrieved my CA cert from the AD Domain controller

I try to set up my winsyncagreement and I am getting this



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ ipa-replica-manage connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to certificate database for idm-master-els.ops.boingo.com
ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 'Invalid credentials'}
Failed to setup winsync replication


not sure where to look for the logs for this to see what the invalivd credentials are or wether this might still be a cert issue or a log in issue or what not?

You can test with ldapsearch like this:

$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"



Thanks in advance for the help

-Todd





_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/c14a197b/attachment.htm>

From tmaugh at boingo.com  Thu Mar 13 20:50:35 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 13 Mar 2014 20:50:35 +0000
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2297543@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>,
	<5321FC5E.1070101@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229730C@EXCHMB1-ELS.BWINC.local>,
	<53220172.8030700@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229744B@EXCHMB1-ELS.BWINC.local>,
	<5322151B.2040101@redhat.com>,
	<6FB698E172A95F49BE009B36D56F53E2297527@EXCHMB1-ELS.BWINC.local>,
	<6FB698E172A95F49BE009B36D56F53E2297543@EXCHMB1-ELS.BWINC.local>
Message-ID: <6FB698E172A95F49BE009B36D56F53E2297557@EXCHMB1-ELS.BWINC.local>

so in changing my ldap.conf  the error I get is now this


TLS: certdb config: configDir='/etc/dirsrv/slapd-OPS-BOINGO-COM' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly
TLS: using moznss security dir /etc/dirsrv/slapd-OPS-BOINGO-COM prefix .
TLS: loaded CA certificate file /etc/ipa/ca.crt.
TLS: certificate [CN=ADC13-ELS.BWINC.local] is not valid - error -8179:Peer's Certificate issuer is not recognized..
TLS certificate verification: subject: CN=ADC13-ELS.BWINC.local, issuer: CN=BoingoWirelessCA,DC=BWINC,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0
ldap_sasl_bind

________________________________
From: Todd Maugh
Sent: Thursday, March 13, 2014 1:49 PM
To: Rich Megginson; freeipa-users at redhat.com
Subject: RE: [Freeipa-users] [freeipa] Issues with Winsync agreement

I'm curious if the ldap.conf is wrong: heres what it looks like

#File modified by ipa-client-install

URI ldaps://idm-master-els.ops.boingo.com
BASE dc=ops,dc=boingo,dc=com
TLS_CACERT /etc/openldap/cacerts/
TLS_REQCERT allow

________________________________
From: Todd Maugh
Sent: Thursday, March 13, 2014 1:47 PM
To: Rich Megginson; freeipa-users at redhat.com
Subject: RE: [Freeipa-users] [freeipa] Issues with Winsync agreement

thank you Rich for all your help as I am inclined to think its a cert issue as well

so I ran the new command, and there are some lines that stick out to me in reference to the cert:

[root at idm-master-els.ops.boingo.com ~]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "g0_b0ing0" -s base -b "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn
ldap_create
ldap_url_parse_ext(ldap://adc13-els.bwinc.local)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP adc13-els.bwinc.local:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 172.22.170.13:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 31 bytes to sd 3
ldap_result ld 0x25c4210 msgid 1
wait4msg ld 0x25c4210 msgid 1 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid 1 all 1
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid 1 all 1
ldap_chkResponseList returns ld 0x25c4210 NULL
ldap_int_select
read1msg: ld 0x25c4210 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 40 contents:
read1msg: ld 0x25c4210 msgid 1 message type extended-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x25c4210 0 new referrals
read1msg:  mark request completed, ld 0x25c4210 msgid 1
request done: ld 0x25c4210 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_extended_result
ber_scanf fmt ({eAA) ber:
ber_scanf fmt (a) ber:
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (x) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
TLS: certdb config: configDir='/etc/dirsrv/slapd-OPS-BOINGO-COM' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly
TLS: using moznss security dir /etc/dirsrv/slapd-OPS-BOINGO-COM prefix .
TLS: error: the certificate file /etc/openldap/cacerts/ is not a file.
TLS: /etc/openldap/cacerts/ is not a valid CA certificate file - error -5953:Cannot perform a normal file operation on a directory.
TLS: certificate [CN=ADC13-ELS.BWINC.local] is not valid - error -8179:Peer's Certificate issuer is not recognized..
TLS certificate verification: subject: CN=ADC13-ELS.BWINC.local, issuer: CN=BoingoWirelessCA,DC=BWINC,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 61 bytes to sd 3
ldap_result ld 0x25c4210 msgid 2
wait4msg ld 0x25c4210 msgid 2 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid 2 all 1
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid 2 all 1
ldap_chkResponseList returns ld 0x25c4210 NULL
ldap_int_select
read1msg: ld 0x25c4210 msgid 2 all 1
ber_get_next
ber_get_next: tag 0x30 len 16 contents:
read1msg: ld 0x25c4210 msgid 2 message type bind
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x25c4210 0 new referrals
read1msg:  mark request completed, ld 0x25c4210 msgid 2
request done: ld 0x25c4210 msgid 2
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_search_ext
put_filter: "objectclass=*"
put_filter: default
put_simple_filter: "objectclass=*"
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 69 bytes to sd 3
ldap_result ld 0x25c4210 msgid -1
wait4msg ld 0x25c4210 msgid -1 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid -1 all 0
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 3,  origid 3, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid -1 all 0
ldap_chkResponseList returns ld 0x25c4210 NULL
ldap_int_select
read1msg: ld 0x25c4210 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 43 contents:
read1msg: ld 0x25c4210 msgid 3 message type search-entry
ldap_get_dn_ber
ber_scanf fmt ({ml{) ber:
dn: cn=Users,dc=bwinc,dc=local
ber_scanf fmt ({xx) ber:
ldap_get_attribute_ber
ldap_msgfree
ldap_result ld 0x25c4210 msgid -1
wait4msg ld 0x25c4210 msgid -1 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid -1 all 0
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 3,  origid 3, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid -1 all 0
ldap_chkResponseList returns ld 0x25c4210 NULL
read1msg: ld 0x25c4210 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 16 contents:
read1msg: ld 0x25c4210 msgid 3 message type search-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x25c4210 0 new referrals
read1msg:  mark request completed, ld 0x25c4210 msgid 3
request done: ld 0x25c4210 msgid 3
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 3, msgid 3)

ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 3
ldap_free_connection: actually freed

________________________________
From: Rich Megginson [rmeggins at redhat.com]
Sent: Thursday, March 13, 2014 1:29 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 01:58 PM, Todd Maugh wrote:
I believe they are.

so here is the out put of the log. it was showing those errors, I deleted the wynsync agreement and then restarted ipa and then readded the winsync and the errors returned. could this be a cert issue?

[13/Mar/2014:19:48:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:48:44 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:49:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:51:08 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)

here I removed the winsync agreement :ipa-replica-manage del adc13-els.bwinc.local
then restartd ipa

ipactl restart

[13/Mar/2014:19:51:50 +0000] NSMMReplicationPlugin - agmt_delete: begin
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - signaling operation threads
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - waiting for 29 threads to terminate
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - closing down internal subsystems and plugins
[13/Mar/2014:19:51:59 +0000] - Waiting for 4 database threads to stop
[13/Mar/2014:19:51:59 +0000] - All database threads now stopped
[13/Mar/2014:19:51:59 +0000] - slapd stopped.
[13/Mar/2014:19:52:14 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:52:14 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/idm-master-els.ops.boingo.com at OPS.BOINGO.COM<mailto:ldap/idm-master-els.ops.boingo.com at OPS.BOINGO.COM>] in keytab [FILE:/etc/dirsrv/ds.keytab<UrlBlockedError.aspx>]: -1765328324 (Generic error (see e-text))
[13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:52:14 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success)
[13/Mar/2014:19:52:14 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
[13/Mar/2014:19:52:14 +0000] NSMMReplicationPlugin - agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found))
[13/Mar/2014:19:52:14 +0000] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[13/Mar/2014:19:52:14 +0000] - Listening on All Interfaces port 636 for LDAPS requests
[13/Mar/2014:19:52:14 +0000] - Listening on /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
[13/Mar/2014:19:52:18 +0000] NSMMReplicationPlugin - agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): Replication bind with GSSAPI auth resumed

here i added the winsync agreement again

[13/Mar/2014:19:53:16 +0000] - slapd shutting down - signaling operation threads
[13/Mar/2014:19:53:16 +0000] - slapd shutting down - waiting for 30 threads to terminate
[13/Mar/2014:19:53:16 +0000] - slapd shutting down - closing down internal subsystems and plugins
[13/Mar/2014:19:53:16 +0000] - Waiting for 4 database threads to stop
[13/Mar/2014:19:53:16 +0000] - All database threads now stopped
[13/Mar/2014:19:53:16 +0000] - slapd stopped.
[13/Mar/2014:19:53:20 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:53:20 +0000] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[13/Mar/2014:19:53:20 +0000] - Listening on All Interfaces port 636 for LDAPS requests
[13/Mar/2014:19:53:20 +0000] - Listening on /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:22 +0000] NSMMReplicationPlugin - agmt="cn=meToadc13-els.bwinc.local" (adc13-els:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's Certificate issuer is not recognized.)

This is seems like a cert issue.  "Peer's" the AD server "Certificate issuer" the CA that issued the AD server cert "is not recognized" IdM has no knowledge of the CA cert.

But you verified that ldapsearch was working?  LDAPTLS_CACERTDIR tells ldapsearch to use /etc/dirsrv/slapd-OPS-BOINGO-COM, which is the same as winsync is using.

Try doing the ldapsearch again, like this:

[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn

The -d 1 will make it spew debugging information.  Perhaps ldapsearch is picking up some option from /etc/openldap/ldap.conf or ~/.ldaprc which tells it to ignore certificate verification.

[13/Mar/2014:19:53:22 +0000] - Entry "cn=meToadc13-els.bwinc.local,cn=replica,cn=dc\3Dops\2Cdc\3Dboingo\2Cdc\3Dcom,cn=mapping tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not allowed
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)


________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Thursday, March 13, 2014 12:05 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 12:50 PM, Todd Maugh wrote:
Ok the error I see repeated in the log is

[13/Mar/2014:18:41:21 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:11 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:14 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:56 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:44:30 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success)
[13/Mar/2014:18:44:33 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:44:44 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:46:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:29 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:38 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:50 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:11 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:14 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:56 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$

Are all of these associated with the winsync agreement?


________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Thursday, March 13, 2014 11:43 AM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 12:29 PM, Todd Maugh wrote:
ok so I ran that and Get this output

Ok.  Next, take a look at /var/log/dirsrv/slapd-OPS-BOINGO-COM/errors



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local"
dn: cn=Users,dc=bwinc,dc=local
objectClass: top
objectClass: container
cn: Users
description: Default container for upgraded user accounts
distinguishedName: CN=Users,DC=BWINC,DC=local
instanceType: 4
whenCreated: 20060824234034.0Z
whenChanged: 20140306190741.0Z
uSNCreated: 17702
uSNChanged: 17702
showInAdvancedViewOnly: FALSE
name: Users
objectGUID:: kCZ7CbnIZk+0GpmCr3PCfw==
systemFlags: -1946157056
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=BWINC,DC=local
isCriticalSystemObject: TRUE
dSCorePropagationData: 20140306234416.0Z
dSCorePropagationData: 20140306234348.0Z
dSCorePropagationData: 20140306225101.0Z
dSCorePropagationData: 20140306225055.0Z
dSCorePropagationData: 16010101000000.0Z

________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:47 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:39 PM, Todd Maugh wrote:
thanks Rich,

when I run that  I get the following:


[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
ldap_bind: Invalid credentials (49)

Invalid credentials almost always means your password "XXXXXX" is not correct for user "cn=idmadmin,cn=Users,dc=bwinc,dc=local"

    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580



________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:30 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:18 PM, Todd Maugh wrote:
Hello.

I'm using latest IPA build on red hat 6.5

I retrieved my CA cert from the AD Domain controller

I try to set up my winsyncagreement and I am getting this



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ ipa-replica-manage connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to certificate database for idm-master-els.ops.boingo.com
ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 'Invalid credentials'}
Failed to setup winsync replication


not sure where to look for the logs for this to see what the invalivd credentials are or wether this might still be a cert issue or a log in issue or what not?

You can test with ldapsearch like this:

$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"



Thanks in advance for the help

-Todd





_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/9b30cf44/attachment.htm>

From rmeggins at redhat.com  Thu Mar 13 21:04:47 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 13 Mar 2014 15:04:47 -0600
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2297543@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>,
	<5321FC5E.1070101@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229730C@EXCHMB1-ELS.BWINC.local>,
	<53220172.8030700@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229744B@EXCHMB1-ELS.BWINC.local>,
	<5322151B.2040101@redhat.com>,
	<6FB698E172A95F49BE009B36D56F53E2297527@EXCHMB1-ELS.BWINC.local>
	<6FB698E172A95F49BE009B36D56F53E2297543@EXCHMB1-ELS.BWINC.local>
Message-ID: <53221D6F.2030606@redhat.com>

On 03/13/2014 02:49 PM, Todd Maugh wrote:
> I'm curious if the ldap.conf is wrong: heres what it looks like
>
> #File modified by ipa-client-install
>
> URI ldaps://idm-master-els.ops.boingo.com
> BASE dc=ops,dc=boingo,dc=com
> TLS_CACERT /etc/openldap/cacerts/

This is wrong - TLS_CACERT should be a single _file_, containing one or 
more CA certs, not a directory.  For a directory, use TLS_CACERTDIR.

> TLS_REQCERT allow

This tells ldapsearch et. al. to warn but allow certificate validation 
errors.

Try the ldapsearch like this:

[root at idm-master-els.ops.boingo.com ~]$ LDAPTLS_REQCERT=demand 
LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 
-xLLLZZ -h adc13-els.bwinc.local -D 
"cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXXX" -s base -b 
"cn=Users,dc=bwinc,dc=local" "objectclass=*" dn

But if that fails with the same error as below, that means you are not 
using the correct CA cert for the CA that issued the Windows AD server cert.

>
> ------------------------------------------------------------------------
> *From:* Todd Maugh
> *Sent:* Thursday, March 13, 2014 1:47 PM
> *To:* Rich Megginson; freeipa-users at redhat.com
> *Subject:* RE: [Freeipa-users] [freeipa] Issues with Winsync agreement
>
> thank you Rich for all your help as I am inclined to think its a cert 
> issue as well
>
> so I ran the new command, and there are some lines that stick out to 
> me in reference to the cert:
>
> [root at idm-master-els.ops.boingo.com ~]$ 
> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 
> -xLLLZZ -h adc13-els.bwinc.local -D 
> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b 
> "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn
> ldap_create
> ldap_url_parse_ext(ldap://adc13-els.bwinc.local)
> ldap_extended_operation_s
> ldap_extended_operation
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP adc13-els.bwinc.local:389
> ldap_new_socket: 3
> ldap_prepare_socket: 3
> ldap_connect_to_host: Trying 172.22.170.13:389
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
> ldap_open_defconn: successful
> ldap_send_server_request
> ber_scanf fmt ({it) ber:
> ber_scanf fmt ({) ber:
> ber_flush2: 31 bytes to sd 3
> ldap_result ld 0x25c4210 msgid 1
> wait4msg ld 0x25c4210 msgid 1 (infinite timeout)
> wait4msg continue ld 0x25c4210 msgid 1 all 1
> ** ld 0x25c4210 Connections:
> * host: adc13-els.bwinc.local  port: 389  (default)
>   refcnt: 2  status: Connected
>   last used: Thu Mar 13 20:44:41 2014
>
>
> ** ld 0x25c4210 Outstanding Requests:
>  * msgid 1,  origid 1, status InProgress
>    outstanding referrals 0, parent count 0
>   ld 0x25c4210 request count 1 (abandoned 0)
> ** ld 0x25c4210 Response Queue:
>    Empty
>   ld 0x25c4210 response count 0
> ldap_chkResponseList ld 0x25c4210 msgid 1 all 1
> ldap_chkResponseList returns ld 0x25c4210 NULL
> ldap_int_select
> read1msg: ld 0x25c4210 msgid 1 all 1
> ber_get_next
> ber_get_next: tag 0x30 len 40 contents:
> read1msg: ld 0x25c4210 msgid 1 message type extended-result
> ber_scanf fmt ({eAA) ber:
> read1msg: ld 0x25c4210 0 new referrals
> read1msg:  mark request completed, ld 0x25c4210 msgid 1
> request done: ld 0x25c4210 msgid 1
> res_errno: 0, res_error: <>, res_matched: <>
> ldap_free_request (origid 1, msgid 1)
> ldap_parse_extended_result
> ber_scanf fmt ({eAA) ber:
> ber_scanf fmt (a) ber:
> ldap_parse_result
> ber_scanf fmt ({iAA) ber:
> ber_scanf fmt (x) ber:
> ber_scanf fmt (}) ber:
> ldap_msgfree
> *TLS: certdb config: configDir='/etc/dirsrv/slapd-OPS-BOINGO-COM' 
> tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly
> TLS: using moznss security dir /etc/dirsrv/slapd-OPS-BOINGO-COM prefix .
> TLS: error: the certificate file /etc/openldap/cacerts/ is not a file.
> TLS: /etc/openldap/cacerts/ is not a valid CA certificate file - error 
> -5953:Cannot perform a normal file operation on a directory.
> TLS: certificate [CN=ADC13-ELS.BWINC.local] is not valid - error 
> -8179:Peer's Certificate issuer is not recognized..
> TLS certificate verification: subject: CN=ADC13-ELS.BWINC.local, 
> issuer: CN=BoingoWirelessCA,DC=BWINC,DC=local, cipher: AES-128, 
> security level: high, secret key bits: 128, total key bits: 128, cache 
> hits: 0, cache misses: 0, cache not reusable: 0*
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_send_server_request
> ber_scanf fmt ({it) ber:
> ber_scanf fmt ({i) ber:
> ber_flush2: 61 bytes to sd 3
> ldap_result ld 0x25c4210 msgid 2
> wait4msg ld 0x25c4210 msgid 2 (infinite timeout)
> wait4msg continue ld 0x25c4210 msgid 2 all 1
> ** ld 0x25c4210 Connections:
> * host: adc13-els.bwinc.local  port: 389  (default)
>   refcnt: 2  status: Connected
>   last used: Thu Mar 13 20:44:41 2014
>
>
> ** ld 0x25c4210 Outstanding Requests:
>  * msgid 2,  origid 2, status InProgress
>    outstanding referrals 0, parent count 0
>   ld 0x25c4210 request count 1 (abandoned 0)
> ** ld 0x25c4210 Response Queue:
>    Empty
>   ld 0x25c4210 response count 0
> ldap_chkResponseList ld 0x25c4210 msgid 2 all 1
> ldap_chkResponseList returns ld 0x25c4210 NULL
> ldap_int_select
> read1msg: ld 0x25c4210 msgid 2 all 1
> ber_get_next
> ber_get_next: tag 0x30 len 16 contents:
> read1msg: ld 0x25c4210 msgid 2 message type bind
> ber_scanf fmt ({eAA) ber:
> read1msg: ld 0x25c4210 0 new referrals
> read1msg:  mark request completed, ld 0x25c4210 msgid 2
> request done: ld 0x25c4210 msgid 2
> res_errno: 0, res_error: <>, res_matched: <>
> ldap_free_request (origid 2, msgid 2)
> ldap_parse_result
> ber_scanf fmt ({iAA) ber:
> ber_scanf fmt (}) ber:
> ldap_msgfree
> ldap_search_ext
> put_filter: "objectclass=*"
> put_filter: default
> put_simple_filter: "objectclass=*"
> ldap_send_initial_request
> ldap_send_server_request
> ber_scanf fmt ({it) ber:
> ber_scanf fmt ({) ber:
> ber_flush2: 69 bytes to sd 3
> ldap_result ld 0x25c4210 msgid -1
> wait4msg ld 0x25c4210 msgid -1 (infinite timeout)
> wait4msg continue ld 0x25c4210 msgid -1 all 0
> ** ld 0x25c4210 Connections:
> * host: adc13-els.bwinc.local  port: 389  (default)
>   refcnt: 2  status: Connected
>   last used: Thu Mar 13 20:44:41 2014
>
>
> ** ld 0x25c4210 Outstanding Requests:
>  * msgid 3,  origid 3, status InProgress
>    outstanding referrals 0, parent count 0
>   ld 0x25c4210 request count 1 (abandoned 0)
> ** ld 0x25c4210 Response Queue:
>    Empty
>   ld 0x25c4210 response count 0
> ldap_chkResponseList ld 0x25c4210 msgid -1 all 0
> ldap_chkResponseList returns ld 0x25c4210 NULL
> ldap_int_select
> read1msg: ld 0x25c4210 msgid -1 all 0
> ber_get_next
> ber_get_next: tag 0x30 len 43 contents:
> read1msg: ld 0x25c4210 msgid 3 message type search-entry
> ldap_get_dn_ber
> ber_scanf fmt ({ml{) ber:
> dn: cn=Users,dc=bwinc,dc=local
> ber_scanf fmt ({xx) ber:
> ldap_get_attribute_ber
> ldap_msgfree
> ldap_result ld 0x25c4210 msgid -1
> wait4msg ld 0x25c4210 msgid -1 (infinite timeout)
> wait4msg continue ld 0x25c4210 msgid -1 all 0
> ** ld 0x25c4210 Connections:
> * host: adc13-els.bwinc.local  port: 389  (default)
>   refcnt: 2  status: Connected
>   last used: Thu Mar 13 20:44:41 2014
>
>
> ** ld 0x25c4210 Outstanding Requests:
>  * msgid 3,  origid 3, status InProgress
>    outstanding referrals 0, parent count 0
>   ld 0x25c4210 request count 1 (abandoned 0)
> ** ld 0x25c4210 Response Queue:
>    Empty
>   ld 0x25c4210 response count 0
> ldap_chkResponseList ld 0x25c4210 msgid -1 all 0
> ldap_chkResponseList returns ld 0x25c4210 NULL
> read1msg: ld 0x25c4210 msgid -1 all 0
> ber_get_next
> ber_get_next: tag 0x30 len 16 contents:
> read1msg: ld 0x25c4210 msgid 3 message type search-result
> ber_scanf fmt ({eAA) ber:
> read1msg: ld 0x25c4210 0 new referrals
> read1msg:  mark request completed, ld 0x25c4210 msgid 3
> request done: ld 0x25c4210 msgid 3
> res_errno: 0, res_error: <>, res_matched: <>
> ldap_free_request (origid 3, msgid 3)
>
> ldap_parse_result
> ber_scanf fmt ({iAA) ber:
> ber_scanf fmt (}) ber:
> ldap_msgfree
> ldap_free_connection 1 1
> ldap_send_unbind
> ber_flush2: 7 bytes to sd 3
> ldap_free_connection: actually freed
>
> ------------------------------------------------------------------------
> *From:* Rich Megginson [rmeggins at redhat.com]
> *Sent:* Thursday, March 13, 2014 1:29 PM
> *To:* Todd Maugh; freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>
> On 03/13/2014 01:58 PM, Todd Maugh wrote:
>> I believe they are.
>>
>> so here is the out put of the log. it was showing those errors, I 
>> deleted the wynsync agreement and then restarted ipa and then readded 
>> the winsync and the errors returned. could this be a cert issue?
>>
>> [13/Mar/2014:19:48:20 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:19:48:44 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:19:49:32 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:19:51:08 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>
>> here I removed the winsync agreement :ipa-replica-manage del 
>> adc13-els.bwinc.local
>> then restartd ipa
>>
>> ipactl restart
>>
>> [13/Mar/2014:19:51:50 +0000] NSMMReplicationPlugin - agmt_delete: begin
>> [13/Mar/2014:19:51:59 +0000] - slapd shutting down - signaling 
>> operation threads
>> [13/Mar/2014:19:51:59 +0000] - slapd shutting down - waiting for 29 
>> threads to terminate
>> [13/Mar/2014:19:51:59 +0000] - slapd shutting down - closing down 
>> internal subsystems and plugins
>> [13/Mar/2014:19:51:59 +0000] - Waiting for 4 database threads to stop
>> [13/Mar/2014:19:51:59 +0000] - All database threads now stopped
>> [13/Mar/2014:19:51:59 +0000] - slapd stopped.
>> [13/Mar/2014:19:52:14 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 
>> starting up
>> [13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no 
>> entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
>> [13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no 
>> entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
>> [13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no 
>> entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
>> [13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password 
>> Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, 
>> which should be added before the CoS Definition.
>> [13/Mar/2014:19:52:14 +0000] set_krb5_creds - Could not get initial 
>> credentials for principal 
>> [ldap/idm-master-els.ops.boingo.com at OPS.BOINGO.COM] in keytab 
>> [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
>> [13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password 
>> Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, 
>> which should be added before the CoS Definition.
>> [13/Mar/2014:19:52:14 +0000] slapd_ldap_sasl_interactive_bind - 
>> Error: could not perform interactive bind for id [] mech [GSSAPI]: 
>> LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: 
>> Unspecified GSS failure.  Minor code may provide more information 
>> (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success)
>> [13/Mar/2014:19:52:14 +0000] slapi_ldap_bind - Error: could not 
>> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
>> [13/Mar/2014:19:52:14 +0000] NSMMReplicationPlugin - 
>> agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): 
>> Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) 
>> (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
>> Minor code may provide more information (Credentials cache file 
>> '/tmp/krb5cc_495' not found))
>> [13/Mar/2014:19:52:14 +0000] - slapd started. Listening on All 
>> Interfaces port 389 for LDAP requests
>> [13/Mar/2014:19:52:14 +0000] - Listening on All Interfaces port 636 
>> for LDAPS requests
>> [13/Mar/2014:19:52:14 +0000] - Listening on 
>> /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
>> [13/Mar/2014:19:52:18 +0000] NSMMReplicationPlugin - 
>> agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): 
>> Replication bind with GSSAPI auth resumed
>>
>> here i added the winsync agreement again
>>
>> [13/Mar/2014:19:53:16 +0000] - slapd shutting down - signaling 
>> operation threads
>> [13/Mar/2014:19:53:16 +0000] - slapd shutting down - waiting for 30 
>> threads to terminate
>> [13/Mar/2014:19:53:16 +0000] - slapd shutting down - closing down 
>> internal subsystems and plugins
>> [13/Mar/2014:19:53:16 +0000] - Waiting for 4 database threads to stop
>> [13/Mar/2014:19:53:16 +0000] - All database threads now stopped
>> [13/Mar/2014:19:53:16 +0000] - slapd stopped.
>> [13/Mar/2014:19:53:20 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 
>> starting up
>> [13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no 
>> entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
>> [13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no 
>> entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
>> [13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no 
>> entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
>> [13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password 
>> Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, 
>> which should be added before the CoS Definition.
>> [13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password 
>> Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, 
>> which should be added before the CoS Definition.
>> [13/Mar/2014:19:53:20 +0000] - slapd started. Listening on All 
>> Interfaces port 389 for LDAP requests
>> [13/Mar/2014:19:53:20 +0000] - Listening on All Interfaces port 636 
>> for LDAPS requests
>> [13/Mar/2014:19:53:20 +0000] - Listening on 
>> /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
>> [13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:19:53:22 +0000] NSMMReplicationPlugin - 
>> agmt="cn=meToadc13-els.bwinc.local" (adc13-els:389): Replication bind 
>> with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error 
>> -8179:Peer's Certificate issuer is not recognized.)
>
> This is seems like a cert issue.  "Peer's" the AD server "Certificate 
> issuer" the CA that issued the AD server cert "is not recognized" IdM 
> has no knowledge of the CA cert.
>
> But you verified that ldapsearch was working? LDAPTLS_CACERTDIR tells 
> ldapsearch to use /etc/dirsrv/slapd-OPS-BOINGO-COM, which is the same 
> as winsync is using.
>
> Try doing the ldapsearch again, like this:
>
> [root at idm-master-els.ops.boingo.com cacerts]$ 
> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 
> -xLLLZZ -h adc13-els.bwinc.local -D 
> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b 
> "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn
>
> The -d 1 will make it spew debugging information. Perhaps ldapsearch 
> is picking up some option from /etc/openldap/ldap.conf or ~/.ldaprc 
> which tells it to ignore certificate verification.
>
>> [13/Mar/2014:19:53:22 +0000] - Entry 
>> "cn=meToadc13-els.bwinc.local,cn=replica,cn=dc\3Dops\2Cdc\3Dboingo\2Cdc\3Dcom,cn=mapping 
>> tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not 
>> allowed
>> [13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>> [13/Mar/2014:19:53:25 +0000] slapi_ldap_bind - Error: could not send 
>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Rich Megginson [rmeggins at redhat.com]
>> *Sent:* Thursday, March 13, 2014 12:05 PM
>> *To:* Todd Maugh; freeipa-users at redhat.com
>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>
>> On 03/13/2014 12:50 PM, Todd Maugh wrote:
>>> Ok the error I see repeated in the log is
>>>
>>> [13/Mar/2014:18:41:21 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:43:11 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:43:14 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:43:20 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:43:32 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:43:56 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:44:30 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success)
>>> [13/Mar/2014:18:44:33 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:44:44 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:46:20 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:47:29 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:47:32 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:47:38 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:47:50 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:48:11 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:48:14 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:48:20 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:48:32 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:18:48:56 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [root at idm-master-els.ops.boingo.com cacerts]$
>>
>> Are all of these associated with the winsync agreement?
>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>> *Sent:* Thursday, March 13, 2014 11:43 AM
>>> *To:* Todd Maugh; freeipa-users at redhat.com
>>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>>
>>> On 03/13/2014 12:29 PM, Todd Maugh wrote:
>>>> ok so I ran that and Get this output
>>>
>>> Ok.  Next, take a look at /var/log/dirsrv/slapd-OPS-BOINGO-COM/errors
>>>
>>>>
>>>>
>>>> [root at idm-master-els.ops.boingo.com cacerts]$ 
>>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch 
>>>> -xLLLZZ -h adc13-els.bwinc.local -D 
>>>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b 
>>>> "cn=Users,dc=bwinc,dc=local"
>>>> dn: cn=Users,dc=bwinc,dc=local
>>>> objectClass: top
>>>> objectClass: container
>>>> cn: Users
>>>> description: Default container for upgraded user accounts
>>>> distinguishedName: CN=Users,DC=BWINC,DC=local
>>>> instanceType: 4
>>>> whenCreated: 20060824234034.0Z
>>>> whenChanged: 20140306190741.0Z
>>>> uSNCreated: 17702
>>>> uSNChanged: 17702
>>>> showInAdvancedViewOnly: FALSE
>>>> name: Users
>>>> objectGUID:: kCZ7CbnIZk+0GpmCr3PCfw==
>>>> systemFlags: -1946157056
>>>> objectCategory: 
>>>> CN=Container,CN=Schema,CN=Configuration,DC=BWINC,DC=local
>>>> isCriticalSystemObject: TRUE
>>>> dSCorePropagationData: 20140306234416.0Z
>>>> dSCorePropagationData: 20140306234348.0Z
>>>> dSCorePropagationData: 20140306225101.0Z
>>>> dSCorePropagationData: 20140306225055.0Z
>>>> dSCorePropagationData: 16010101000000.0Z
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>>> *Sent:* Wednesday, March 12, 2014 3:47 PM
>>>> *To:* Todd Maugh; freeipa-users at redhat.com
>>>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>>>
>>>> On 03/12/2014 04:39 PM, Todd Maugh wrote:
>>>>> thanks Rich,
>>>>>
>>>>> when I run that  I get the following:
>>>>>
>>>>>
>>>>> *[root at idm-master-els.ops.boingo.com ipa]$ 
>>>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch 
>>>>> -xLLLZZ -h adc13-els.bwinc.local -D 
>>>>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b 
>>>>> "cn=Users,dc=bwinc,dc=local"
>>>>> ldap_bind: Invalid credentials (49)
>>>>> *
>>>>
>>>> *Invalid credentials almost always means your password "XXXXXX" is 
>>>> not correct for user "**cn=idmadmin,cn=Users,dc=bwinc,dc=local"
>>>>
>>>> *
>>>>> *additional info: 80090308: LdapErr: DSID-0C0903C5, comment: 
>>>>> AcceptSecurityContext error, data 52e, v2580
>>>>> *
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>>>> *Sent:* Wednesday, March 12, 2014 3:30 PM
>>>>> *To:* Todd Maugh; freeipa-users at redhat.com
>>>>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>>>>
>>>>> On 03/12/2014 04:18 PM, Todd Maugh wrote:
>>>>>> Hello.
>>>>>>
>>>>>> I'm using latest IPA build on red hat 6.5
>>>>>>
>>>>>> I retrieved my CA cert from the AD Domain controller
>>>>>>
>>>>>> I try to set up my winsyncagreement and I am getting this
>>>>>>
>>>>>>
>>>>>>
>>>>>> [root at idm-master-els.ops.boingo.com ipa]$ ipa-replica-manage 
>>>>>> connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, 
>>>>>> dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" 
>>>>>> --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
>>>>>> Directory Manager password:
>>>>>>
>>>>>> Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to 
>>>>>> certificate database for idm-master-els.ops.boingo.com
>>>>>> ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
>>>>>> ipa: INFO: The error was: {'info': '80090308: LdapErr: 
>>>>>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, 
>>>>>> v2580', 'desc': 'Invalid credentials'}
>>>>>> Failed to setup winsync replication
>>>>>>
>>>>>>
>>>>>> not sure where to look for the logs for this to see what the 
>>>>>> invalivd credentials are or wether this might still be a cert 
>>>>>> issue or a log in issue or what not?
>>>>>
>>>>> You can test with ldapsearch like this:
>>>>>
>>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch 
>>>>> -xLLLZZ -h adc13-els.bwinc.local -D 
>>>>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b 
>>>>> "cn=Users,dc=bwinc,dc=local"
>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks in advance for the help
>>>>>>
>>>>>> -Todd
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Freeipa-users mailing list
>>>>>> Freeipa-users at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/00d1fa59/attachment.htm>

From tmaugh at boingo.com  Thu Mar 13 22:30:14 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 13 Mar 2014 22:30:14 +0000
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <53221D6F.2030606@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>,
	<5321FC5E.1070101@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229730C@EXCHMB1-ELS.BWINC.local>,
	<53220172.8030700@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229744B@EXCHMB1-ELS.BWINC.local>,
	<5322151B.2040101@redhat.com>,
	<6FB698E172A95F49BE009B36D56F53E2297527@EXCHMB1-ELS.BWINC.local>
	<6FB698E172A95F49BE009B36D56F53E2297543@EXCHMB1-ELS.BWINC.local>,
	<53221D6F.2030606@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E22977A0@EXCHMB1-ELS.BWINC.local>

ok Rich thanks for all the Help, I got the windows cert issue resolved and now the repication agreement is working


________________________________
From: Rich Megginson [rmeggins at redhat.com]
Sent: Thursday, March 13, 2014 2:04 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 02:49 PM, Todd Maugh wrote:
I'm curious if the ldap.conf is wrong: heres what it looks like

#File modified by ipa-client-install

URI ldaps://idm-master-els.ops.boingo.com<UrlBlockedError.aspx>
BASE dc=ops,dc=boingo,dc=com
TLS_CACERT /etc/openldap/cacerts/

This is wrong - TLS_CACERT should be a single _file_, containing one or more CA certs, not a directory.  For a directory, use TLS_CACERTDIR.

TLS_REQCERT allow

This tells ldapsearch et. al. to warn but allow certificate validation errors.

Try the ldapsearch like this:

[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ~]$ LDAPTLS_REQCERT=demand LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn

But if that fails with the same error as below, that means you are not using the correct CA cert for the CA that issued the Windows AD server cert.


________________________________
From: Todd Maugh
Sent: Thursday, March 13, 2014 1:47 PM
To: Rich Megginson; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: RE: [Freeipa-users] [freeipa] Issues with Winsync agreement

thank you Rich for all your help as I am inclined to think its a cert issue as well

so I ran the new command, and there are some lines that stick out to me in reference to the cert:

[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ~]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn
ldap_create
ldap_url_parse_ext(ldap://adc13-els.bwinc.local<UrlBlockedError.aspx>)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP adc13-els.bwinc.local:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 172.22.170.13:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 31 bytes to sd 3
ldap_result ld 0x25c4210 msgid 1
wait4msg ld 0x25c4210 msgid 1 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid 1 all 1
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid 1 all 1
ldap_chkResponseList returns ld 0x25c4210 NULL
ldap_int_select
read1msg: ld 0x25c4210 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 40 contents:
read1msg: ld 0x25c4210 msgid 1 message type extended-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x25c4210 0 new referrals
read1msg:  mark request completed, ld 0x25c4210 msgid 1
request done: ld 0x25c4210 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_extended_result
ber_scanf fmt ({eAA) ber:
ber_scanf fmt (a) ber:
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (x) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
TLS: certdb config: configDir='/etc/dirsrv/slapd-OPS-BOINGO-COM' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly
TLS: using moznss security dir /etc/dirsrv/slapd-OPS-BOINGO-COM prefix .
TLS: error: the certificate file /etc/openldap/cacerts/ is not a file.
TLS: /etc/openldap/cacerts/ is not a valid CA certificate file - error -5953:Cannot perform a normal file operation on a directory.
TLS: certificate [CN=ADC13-ELS.BWINC.local] is not valid - error -8179:Peer's Certificate issuer is not recognized..
TLS certificate verification: subject: CN=ADC13-ELS.BWINC.local, issuer: CN=BoingoWirelessCA,DC=BWINC,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 61 bytes to sd 3
ldap_result ld 0x25c4210 msgid 2
wait4msg ld 0x25c4210 msgid 2 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid 2 all 1
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid 2 all 1
ldap_chkResponseList returns ld 0x25c4210 NULL
ldap_int_select
read1msg: ld 0x25c4210 msgid 2 all 1
ber_get_next
ber_get_next: tag 0x30 len 16 contents:
read1msg: ld 0x25c4210 msgid 2 message type bind
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x25c4210 0 new referrals
read1msg:  mark request completed, ld 0x25c4210 msgid 2
request done: ld 0x25c4210 msgid 2
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_search_ext
put_filter: "objectclass=*"
put_filter: default
put_simple_filter: "objectclass=*"
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 69 bytes to sd 3
ldap_result ld 0x25c4210 msgid -1
wait4msg ld 0x25c4210 msgid -1 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid -1 all 0
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 3,  origid 3, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid -1 all 0
ldap_chkResponseList returns ld 0x25c4210 NULL
ldap_int_select
read1msg: ld 0x25c4210 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 43 contents:
read1msg: ld 0x25c4210 msgid 3 message type search-entry
ldap_get_dn_ber
ber_scanf fmt ({ml{) ber:
dn: cn=Users,dc=bwinc,dc=local
ber_scanf fmt ({xx) ber:
ldap_get_attribute_ber
ldap_msgfree
ldap_result ld 0x25c4210 msgid -1
wait4msg ld 0x25c4210 msgid -1 (infinite timeout)
wait4msg continue ld 0x25c4210 msgid -1 all 0
** ld 0x25c4210 Connections:
* host: adc13-els.bwinc.local  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Mar 13 20:44:41 2014


** ld 0x25c4210 Outstanding Requests:
 * msgid 3,  origid 3, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x25c4210 request count 1 (abandoned 0)
** ld 0x25c4210 Response Queue:
   Empty
  ld 0x25c4210 response count 0
ldap_chkResponseList ld 0x25c4210 msgid -1 all 0
ldap_chkResponseList returns ld 0x25c4210 NULL
read1msg: ld 0x25c4210 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 16 contents:
read1msg: ld 0x25c4210 msgid 3 message type search-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x25c4210 0 new referrals
read1msg:  mark request completed, ld 0x25c4210 msgid 3
request done: ld 0x25c4210 msgid 3
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 3, msgid 3)

ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 3
ldap_free_connection: actually freed

________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Thursday, March 13, 2014 1:29 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 01:58 PM, Todd Maugh wrote:
I believe they are.

so here is the out put of the log. it was showing those errors, I deleted the wynsync agreement and then restarted ipa and then readded the winsync and the errors returned. could this be a cert issue?

[13/Mar/2014:19:48:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:48:44 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:49:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:51:08 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)

here I removed the winsync agreement :ipa-replica-manage del adc13-els.bwinc.local
then restartd ipa

ipactl restart

[13/Mar/2014:19:51:50 +0000] NSMMReplicationPlugin - agmt_delete: begin
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - signaling operation threads
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - waiting for 29 threads to terminate
[13/Mar/2014:19:51:59 +0000] - slapd shutting down - closing down internal subsystems and plugins
[13/Mar/2014:19:51:59 +0000] - Waiting for 4 database threads to stop
[13/Mar/2014:19:51:59 +0000] - All database threads now stopped
[13/Mar/2014:19:51:59 +0000] - slapd stopped.
[13/Mar/2014:19:52:14 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:52:14 +0000] set_krb5_creds - Could not get initial credentials for principal [ldap/idm-master-els.ops.boingo.com at OPS.BOINGO.COM<mailto:ldap/idm-master-els.ops.boingo.com at OPS.BOINGO.COM>] in keytab [FILE:/etc/dirsrv/ds.keytab<UrlBlockedError.aspx>]: -1765328324 (Generic error (see e-text))
[13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:52:14 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found)) errno 0 (Success)
[13/Mar/2014:19:52:14 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
[13/Mar/2014:19:52:14 +0000] NSMMReplicationPlugin - agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_495' not found))
[13/Mar/2014:19:52:14 +0000] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[13/Mar/2014:19:52:14 +0000] - Listening on All Interfaces port 636 for LDAPS requests
[13/Mar/2014:19:52:14 +0000] - Listening on /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
[13/Mar/2014:19:52:18 +0000] NSMMReplicationPlugin - agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): Replication bind with GSSAPI auth resumed

here i added the winsync agreement again

[13/Mar/2014:19:53:16 +0000] - slapd shutting down - signaling operation threads
[13/Mar/2014:19:53:16 +0000] - slapd shutting down - waiting for 30 threads to terminate
[13/Mar/2014:19:53:16 +0000] - slapd shutting down - closing down internal subsystems and plugins
[13/Mar/2014:19:53:16 +0000] - Waiting for 4 database threads to stop
[13/Mar/2014:19:53:16 +0000] - All database threads now stopped
[13/Mar/2014:19:53:16 +0000] - slapd stopped.
[13/Mar/2014:19:53:20 +0000] - 389-Directory/1.2.11.15 B2013.337.1530 starting up
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
[13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, which should be added before the CoS Definition.
[13/Mar/2014:19:53:20 +0000] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[13/Mar/2014:19:53:20 +0000] - Listening on All Interfaces port 636 for LDAPS requests
[13/Mar/2014:19:53:20 +0000] - Listening on /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:22 +0000] NSMMReplicationPlugin - agmt="cn=meToadc13-els.bwinc.local" (adc13-els:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's Certificate issuer is not recognized.)

This is seems like a cert issue.  "Peer's" the AD server "Certificate issuer" the CA that issued the AD server cert "is not recognized" IdM has no knowledge of the CA cert.

But you verified that ldapsearch was working?  LDAPTLS_CACERTDIR tells ldapsearch to use /etc/dirsrv/slapd-OPS-BOINGO-COM, which is the same as winsync is using.

Try doing the ldapsearch again, like this:

[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn

The -d 1 will make it spew debugging information.  Perhaps ldapsearch is picking up some option from /etc/openldap/ldap.conf or ~/.ldaprc which tells it to ignore certificate verification.

[13/Mar/2014:19:53:22 +0000] - Entry "cn=meToadc13-els.bwinc.local,cn=replica,cn=dc\3Dops\2Cdc\3Dboingo\2Cdc\3Dcom,cn=mapping tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not allowed
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:19:53:25 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)


________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Thursday, March 13, 2014 12:05 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 12:50 PM, Todd Maugh wrote:
Ok the error I see repeated in the log is

[13/Mar/2014:18:41:21 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:11 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:14 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:43:56 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:44:30 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success)
[13/Mar/2014:18:44:33 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:44:44 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:46:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:29 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:38 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:47:50 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:11 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:14 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:20 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:32 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[13/Mar/2014:18:48:56 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success)
[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$

Are all of these associated with the winsync agreement?


________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Thursday, March 13, 2014 11:43 AM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/13/2014 12:29 PM, Todd Maugh wrote:
ok so I ran that and Get this output

Ok.  Next, take a look at /var/log/dirsrv/slapd-OPS-BOINGO-COM/errors



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> cacerts]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b "cn=Users,dc=bwinc,dc=local"
dn: cn=Users,dc=bwinc,dc=local
objectClass: top
objectClass: container
cn: Users
description: Default container for upgraded user accounts
distinguishedName: CN=Users,DC=BWINC,DC=local
instanceType: 4
whenCreated: 20060824234034.0Z
whenChanged: 20140306190741.0Z
uSNCreated: 17702
uSNChanged: 17702
showInAdvancedViewOnly: FALSE
name: Users
objectGUID:: kCZ7CbnIZk+0GpmCr3PCfw==
systemFlags: -1946157056
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=BWINC,DC=local
isCriticalSystemObject: TRUE
dSCorePropagationData: 20140306234416.0Z
dSCorePropagationData: 20140306234348.0Z
dSCorePropagationData: 20140306225101.0Z
dSCorePropagationData: 20140306225055.0Z
dSCorePropagationData: 16010101000000.0Z

________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:47 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:39 PM, Todd Maugh wrote:
thanks Rich,

when I run that  I get the following:


[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b "cn=Users,dc=bwinc,dc=local"
ldap_bind: Invalid credentials (49)

Invalid credentials almost always means your password "XXXXXX" is not correct for user "cn=idmadmin,cn=Users,dc=bwinc,dc=local"

    additional info: 80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580



________________________________
From: Rich Megginson [rmeggins at redhat.com<mailto:rmeggins at redhat.com>]
Sent: Wednesday, March 12, 2014 3:30 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] [freeipa] Issues with Winsync agreement

On 03/12/2014 04:18 PM, Todd Maugh wrote:
Hello.

I'm using latest IPA build on red hat 6.5

I retrieved my CA cert from the AD Domain controller

I try to set up my winsyncagreement and I am getting this



[root at idm-master-els.ops.boingo.com<mailto:root at idm-master-els.ops.boingo.com> ipa]$ ipa-replica-manage connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer adc13-els.bwinc.local
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to certificate database for idm-master-els.ops.boingo.com
ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
ipa: INFO: The error was: {'info': '80090308: LdapErr: DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580', 'desc': 'Invalid credentials'}
Failed to setup winsync replication


not sure where to look for the logs for this to see what the invalivd credentials are or wether this might still be a cert issue or a log in issue or what not?

You can test with ldapsearch like this:

$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLLZZ -h adc13-els.bwinc.local -D "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b "cn=Users,dc=bwinc,dc=local"



Thanks in advance for the help

-Todd





_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/d1690ebb/attachment.htm>

From rmeggins at redhat.com  Thu Mar 13 22:46:41 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 13 Mar 2014 16:46:41 -0600
Subject: [Freeipa-users] [freeipa] Issues with Winsync agreement
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E22977A0@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229647F@EXCHMB1-ELS.BWINC.local>,
	<5320E004.4030903@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2296507@EXCHMB1-ELS.BWINC.local>,
	<5320E40E.4030604@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2297269@EXCHMB1-ELS.BWINC.local>,
	<5321FC5E.1070101@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229730C@EXCHMB1-ELS.BWINC.local>,
	<53220172.8030700@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229744B@EXCHMB1-ELS.BWINC.local>,
	<5322151B.2040101@redhat.com>,
	<6FB698E172A95F49BE009B36D56F53E2297527@EXCHMB1-ELS.BWINC.local>
	<6FB698E172A95F49BE009B36D56F53E2297543@EXCHMB1-ELS.BWINC.local>,
	<53221D6F.2030606@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E22977A0@EXCHMB1-ELS.BWINC.local>
Message-ID: <53223551.9080705@redhat.com>

On 03/13/2014 04:30 PM, Todd Maugh wrote:
> ok Rich thanks for all the Help, I got the windows cert issue resolved 
> and now the repication agreement is working

Great!  Thanks for letting us know.

>
>
> ------------------------------------------------------------------------
> *From:* Rich Megginson [rmeggins at redhat.com]
> *Sent:* Thursday, March 13, 2014 2:04 PM
> *To:* Todd Maugh; freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>
> On 03/13/2014 02:49 PM, Todd Maugh wrote:
>> I'm curious if the ldap.conf is wrong: heres what it looks like
>>
>> #File modified by ipa-client-install
>>
>> URI ldaps://idm-master-els.ops.boingo.com
>> BASE dc=ops,dc=boingo,dc=com
>> TLS_CACERT /etc/openldap/cacerts/
>
> This is wrong - TLS_CACERT should be a single _file_, containing one 
> or more CA certs, not a directory.  For a directory, use TLS_CACERTDIR.
>
>> TLS_REQCERT allow
>
> This tells ldapsearch et. al. to warn but allow certificate validation 
> errors.
>
> Try the ldapsearch like this:
>
> [root at idm-master-els.ops.boingo.com ~]$ LDAPTLS_REQCERT=demand 
> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 
> -xLLLZZ -h adc13-els.bwinc.local -D 
> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXXX" -s base -b 
> "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn
>
> But if that fails with the same error as below, that means you are not 
> using the correct CA cert for the CA that issued the Windows AD server 
> cert.
>
>>
>> ------------------------------------------------------------------------
>> *From:* Todd Maugh
>> *Sent:* Thursday, March 13, 2014 1:47 PM
>> *To:* Rich Megginson; freeipa-users at redhat.com
>> *Subject:* RE: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>
>> thank you Rich for all your help as I am inclined to think its a cert 
>> issue as well
>>
>> so I ran the new command, and there are some lines that stick out to 
>> me in reference to the cert:
>>
>> [root at idm-master-els.ops.boingo.com ~]$ 
>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 
>> -xLLLZZ -h adc13-els.bwinc.local -D 
>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b 
>> "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn
>> ldap_create
>> ldap_url_parse_ext(ldap://adc13-els.bwinc.local)
>> ldap_extended_operation_s
>> ldap_extended_operation
>> ldap_send_initial_request
>> ldap_new_connection 1 1 0
>> ldap_int_open_connection
>> ldap_connect_to_host: TCP adc13-els.bwinc.local:389
>> ldap_new_socket: 3
>> ldap_prepare_socket: 3
>> ldap_connect_to_host: Trying 172.22.170.13:389
>> ldap_pvt_connect: fd: 3 tm: -1 async: 0
>> ldap_open_defconn: successful
>> ldap_send_server_request
>> ber_scanf fmt ({it) ber:
>> ber_scanf fmt ({) ber:
>> ber_flush2: 31 bytes to sd 3
>> ldap_result ld 0x25c4210 msgid 1
>> wait4msg ld 0x25c4210 msgid 1 (infinite timeout)
>> wait4msg continue ld 0x25c4210 msgid 1 all 1
>> ** ld 0x25c4210 Connections:
>> * host: adc13-els.bwinc.local  port: 389 (default)
>>   refcnt: 2  status: Connected
>>   last used: Thu Mar 13 20:44:41 2014
>>
>>
>> ** ld 0x25c4210 Outstanding Requests:
>>  * msgid 1,  origid 1, status InProgress
>>    outstanding referrals 0, parent count 0
>>   ld 0x25c4210 request count 1 (abandoned 0)
>> ** ld 0x25c4210 Response Queue:
>>    Empty
>>   ld 0x25c4210 response count 0
>> ldap_chkResponseList ld 0x25c4210 msgid 1 all 1
>> ldap_chkResponseList returns ld 0x25c4210 NULL
>> ldap_int_select
>> read1msg: ld 0x25c4210 msgid 1 all 1
>> ber_get_next
>> ber_get_next: tag 0x30 len 40 contents:
>> read1msg: ld 0x25c4210 msgid 1 message type extended-result
>> ber_scanf fmt ({eAA) ber:
>> read1msg: ld 0x25c4210 0 new referrals
>> read1msg:  mark request completed, ld 0x25c4210 msgid 1
>> request done: ld 0x25c4210 msgid 1
>> res_errno: 0, res_error: <>, res_matched: <>
>> ldap_free_request (origid 1, msgid 1)
>> ldap_parse_extended_result
>> ber_scanf fmt ({eAA) ber:
>> ber_scanf fmt (a) ber:
>> ldap_parse_result
>> ber_scanf fmt ({iAA) ber:
>> ber_scanf fmt (x) ber:
>> ber_scanf fmt (}) ber:
>> ldap_msgfree
>> *TLS: certdb config: configDir='/etc/dirsrv/slapd-OPS-BOINGO-COM' 
>> tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly
>> TLS: using moznss security dir /etc/dirsrv/slapd-OPS-BOINGO-COM prefix .
>> TLS: error: the certificate file /etc/openldap/cacerts/ is not a file.
>> TLS: /etc/openldap/cacerts/ is not a valid CA certificate file - 
>> error -5953:Cannot perform a normal file operation on a directory.
>> TLS: certificate [CN=ADC13-ELS.BWINC.local] is not valid - error 
>> -8179:Peer's Certificate issuer is not recognized..
>> TLS certificate verification: subject: CN=ADC13-ELS.BWINC.local, 
>> issuer: CN=BoingoWirelessCA,DC=BWINC,DC=local, cipher: AES-128, 
>> security level: high, secret key bits: 128, total key bits: 128, 
>> cache hits: 0, cache misses: 0, cache not reusable: 0*
>> ldap_sasl_bind
>> ldap_send_initial_request
>> ldap_send_server_request
>> ber_scanf fmt ({it) ber:
>> ber_scanf fmt ({i) ber:
>> ber_flush2: 61 bytes to sd 3
>> ldap_result ld 0x25c4210 msgid 2
>> wait4msg ld 0x25c4210 msgid 2 (infinite timeout)
>> wait4msg continue ld 0x25c4210 msgid 2 all 1
>> ** ld 0x25c4210 Connections:
>> * host: adc13-els.bwinc.local  port: 389 (default)
>>   refcnt: 2  status: Connected
>>   last used: Thu Mar 13 20:44:41 2014
>>
>>
>> ** ld 0x25c4210 Outstanding Requests:
>>  * msgid 2,  origid 2, status InProgress
>>    outstanding referrals 0, parent count 0
>>   ld 0x25c4210 request count 1 (abandoned 0)
>> ** ld 0x25c4210 Response Queue:
>>    Empty
>>   ld 0x25c4210 response count 0
>> ldap_chkResponseList ld 0x25c4210 msgid 2 all 1
>> ldap_chkResponseList returns ld 0x25c4210 NULL
>> ldap_int_select
>> read1msg: ld 0x25c4210 msgid 2 all 1
>> ber_get_next
>> ber_get_next: tag 0x30 len 16 contents:
>> read1msg: ld 0x25c4210 msgid 2 message type bind
>> ber_scanf fmt ({eAA) ber:
>> read1msg: ld 0x25c4210 0 new referrals
>> read1msg:  mark request completed, ld 0x25c4210 msgid 2
>> request done: ld 0x25c4210 msgid 2
>> res_errno: 0, res_error: <>, res_matched: <>
>> ldap_free_request (origid 2, msgid 2)
>> ldap_parse_result
>> ber_scanf fmt ({iAA) ber:
>> ber_scanf fmt (}) ber:
>> ldap_msgfree
>> ldap_search_ext
>> put_filter: "objectclass=*"
>> put_filter: default
>> put_simple_filter: "objectclass=*"
>> ldap_send_initial_request
>> ldap_send_server_request
>> ber_scanf fmt ({it) ber:
>> ber_scanf fmt ({) ber:
>> ber_flush2: 69 bytes to sd 3
>> ldap_result ld 0x25c4210 msgid -1
>> wait4msg ld 0x25c4210 msgid -1 (infinite timeout)
>> wait4msg continue ld 0x25c4210 msgid -1 all 0
>> ** ld 0x25c4210 Connections:
>> * host: adc13-els.bwinc.local  port: 389 (default)
>>   refcnt: 2  status: Connected
>>   last used: Thu Mar 13 20:44:41 2014
>>
>>
>> ** ld 0x25c4210 Outstanding Requests:
>>  * msgid 3,  origid 3, status InProgress
>>    outstanding referrals 0, parent count 0
>>   ld 0x25c4210 request count 1 (abandoned 0)
>> ** ld 0x25c4210 Response Queue:
>>    Empty
>>   ld 0x25c4210 response count 0
>> ldap_chkResponseList ld 0x25c4210 msgid -1 all 0
>> ldap_chkResponseList returns ld 0x25c4210 NULL
>> ldap_int_select
>> read1msg: ld 0x25c4210 msgid -1 all 0
>> ber_get_next
>> ber_get_next: tag 0x30 len 43 contents:
>> read1msg: ld 0x25c4210 msgid 3 message type search-entry
>> ldap_get_dn_ber
>> ber_scanf fmt ({ml{) ber:
>> dn: cn=Users,dc=bwinc,dc=local
>> ber_scanf fmt ({xx) ber:
>> ldap_get_attribute_ber
>> ldap_msgfree
>> ldap_result ld 0x25c4210 msgid -1
>> wait4msg ld 0x25c4210 msgid -1 (infinite timeout)
>> wait4msg continue ld 0x25c4210 msgid -1 all 0
>> ** ld 0x25c4210 Connections:
>> * host: adc13-els.bwinc.local  port: 389 (default)
>>   refcnt: 2  status: Connected
>>   last used: Thu Mar 13 20:44:41 2014
>>
>>
>> ** ld 0x25c4210 Outstanding Requests:
>>  * msgid 3,  origid 3, status InProgress
>>    outstanding referrals 0, parent count 0
>>   ld 0x25c4210 request count 1 (abandoned 0)
>> ** ld 0x25c4210 Response Queue:
>>    Empty
>>   ld 0x25c4210 response count 0
>> ldap_chkResponseList ld 0x25c4210 msgid -1 all 0
>> ldap_chkResponseList returns ld 0x25c4210 NULL
>> read1msg: ld 0x25c4210 msgid -1 all 0
>> ber_get_next
>> ber_get_next: tag 0x30 len 16 contents:
>> read1msg: ld 0x25c4210 msgid 3 message type search-result
>> ber_scanf fmt ({eAA) ber:
>> read1msg: ld 0x25c4210 0 new referrals
>> read1msg:  mark request completed, ld 0x25c4210 msgid 3
>> request done: ld 0x25c4210 msgid 3
>> res_errno: 0, res_error: <>, res_matched: <>
>> ldap_free_request (origid 3, msgid 3)
>>
>> ldap_parse_result
>> ber_scanf fmt ({iAA) ber:
>> ber_scanf fmt (}) ber:
>> ldap_msgfree
>> ldap_free_connection 1 1
>> ldap_send_unbind
>> ber_flush2: 7 bytes to sd 3
>> ldap_free_connection: actually freed
>>
>> ------------------------------------------------------------------------
>> *From:* Rich Megginson [rmeggins at redhat.com]
>> *Sent:* Thursday, March 13, 2014 1:29 PM
>> *To:* Todd Maugh; freeipa-users at redhat.com
>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>
>> On 03/13/2014 01:58 PM, Todd Maugh wrote:
>>> I believe they are.
>>>
>>> so here is the out put of the log. it was showing those errors, I 
>>> deleted the wynsync agreement and then restarted ipa and then 
>>> readded the winsync and the errors returned. could this be a cert issue?
>>>
>>> [13/Mar/2014:19:48:20 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:19:48:44 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:19:49:32 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:19:51:08 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>>
>>> here I removed the winsync agreement :ipa-replica-manage del 
>>> adc13-els.bwinc.local
>>> then restartd ipa
>>>
>>> ipactl restart
>>>
>>> [13/Mar/2014:19:51:50 +0000] NSMMReplicationPlugin - agmt_delete: begin
>>> [13/Mar/2014:19:51:59 +0000] - slapd shutting down - signaling 
>>> operation threads
>>> [13/Mar/2014:19:51:59 +0000] - slapd shutting down - waiting for 29 
>>> threads to terminate
>>> [13/Mar/2014:19:51:59 +0000] - slapd shutting down - closing down 
>>> internal subsystems and plugins
>>> [13/Mar/2014:19:51:59 +0000] - Waiting for 4 database threads to stop
>>> [13/Mar/2014:19:51:59 +0000] - All database threads now stopped
>>> [13/Mar/2014:19:51:59 +0000] - slapd stopped.
>>> [13/Mar/2014:19:52:14 +0000] - 389-Directory/1.2.11.15 
>>> B2013.337.1530 starting up
>>> [13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no 
>>> entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
>>> [13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no 
>>> entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
>>> [13/Mar/2014:19:52:14 +0000] schema-compat-plugin - warning: no 
>>> entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
>>> [13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password 
>>> Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, 
>>> which should be added before the CoS Definition.
>>> [13/Mar/2014:19:52:14 +0000] set_krb5_creds - Could not get initial 
>>> credentials for principal 
>>> [ldap/idm-master-els.ops.boingo.com at OPS.BOINGO.COM] in keytab 
>>> [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
>>> [13/Mar/2014:19:52:14 +0000] - Skipping CoS Definition cn=Password 
>>> Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, 
>>> which should be added before the CoS Definition.
>>> [13/Mar/2014:19:52:14 +0000] slapd_ldap_sasl_interactive_bind - 
>>> Error: could not perform interactive bind for id [] mech [GSSAPI]: 
>>> LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI 
>>> Error: Unspecified GSS failure.  Minor code may provide more 
>>> information (Credentials cache file '/tmp/krb5cc_495' not found)) 
>>> errno 0 (Success)
>>> [13/Mar/2014:19:52:14 +0000] slapi_ldap_bind - Error: could not 
>>> perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
>>> [13/Mar/2014:19:52:14 +0000] NSMMReplicationPlugin - 
>>> agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): 
>>> Replication bind with GSSAPI auth failed: LDAP error -2 (Local 
>>> error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS 
>>> failure.  Minor code may provide more information (Credentials cache 
>>> file '/tmp/krb5cc_495' not found))
>>> [13/Mar/2014:19:52:14 +0000] - slapd started.  Listening on All 
>>> Interfaces port 389 for LDAP requests
>>> [13/Mar/2014:19:52:14 +0000] - Listening on All Interfaces port 636 
>>> for LDAPS requests
>>> [13/Mar/2014:19:52:14 +0000] - Listening on 
>>> /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
>>> [13/Mar/2014:19:52:18 +0000] NSMMReplicationPlugin - 
>>> agmt="cn=meToidm-rep01-els.ops.boingo.com" (idm-rep01-els:389): 
>>> Replication bind with GSSAPI auth resumed
>>>
>>> here i added the winsync agreement again
>>>
>>> [13/Mar/2014:19:53:16 +0000] - slapd shutting down - signaling 
>>> operation threads
>>> [13/Mar/2014:19:53:16 +0000] - slapd shutting down - waiting for 30 
>>> threads to terminate
>>> [13/Mar/2014:19:53:16 +0000] - slapd shutting down - closing down 
>>> internal subsystems and plugins
>>> [13/Mar/2014:19:53:16 +0000] - Waiting for 4 database threads to stop
>>> [13/Mar/2014:19:53:16 +0000] - All database threads now stopped
>>> [13/Mar/2014:19:53:16 +0000] - slapd stopped.
>>> [13/Mar/2014:19:53:20 +0000] - 389-Directory/1.2.11.15 
>>> B2013.337.1530 starting up
>>> [13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no 
>>> entries set up under cn=computers, cn=compat,dc=ops,dc=boingo,dc=com
>>> [13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no 
>>> entries set up under cn=ng, cn=compat,dc=ops,dc=boingo,dc=com
>>> [13/Mar/2014:19:53:20 +0000] schema-compat-plugin - warning: no 
>>> entries set up under ou=sudoers,dc=ops,dc=boingo,dc=com
>>> [13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password 
>>> Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, 
>>> which should be added before the CoS Definition.
>>> [13/Mar/2014:19:53:20 +0000] - Skipping CoS Definition cn=Password 
>>> Policy,cn=accounts,dc=ops,dc=boingo,dc=com--no CoS Templates found, 
>>> which should be added before the CoS Definition.
>>> [13/Mar/2014:19:53:20 +0000] - slapd started.  Listening on All 
>>> Interfaces port 389 for LDAP requests
>>> [13/Mar/2014:19:53:20 +0000] - Listening on All Interfaces port 636 
>>> for LDAPS requests
>>> [13/Mar/2014:19:53:20 +0000] - Listening on 
>>> /var/run/slapd-OPS-BOINGO-COM.socket for LDAPI requests
>>> [13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:19:53:22 +0000] NSMMReplicationPlugin - 
>>> agmt="cn=meToadc13-els.bwinc.local" (adc13-els:389): Replication 
>>> bind with SIMPLE auth failed: LDAP error -11 (Connect error) (TLS 
>>> error -8179:Peer's Certificate issuer is not recognized.)
>>
>> This is seems like a cert issue.  "Peer's" the AD server "Certificate 
>> issuer" the CA that issued the AD server cert "is not recognized" IdM 
>> has no knowledge of the CA cert.
>>
>> But you verified that ldapsearch was working? LDAPTLS_CACERTDIR tells 
>> ldapsearch to use /etc/dirsrv/slapd-OPS-BOINGO-COM, which is the same 
>> as winsync is using.
>>
>> Try doing the ldapsearch again, like this:
>>
>> [root at idm-master-els.ops.boingo.com cacerts]$ 
>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch -d 1 
>> -xLLLZZ -h adc13-els.bwinc.local -D 
>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b 
>> "cn=Users,dc=bwinc,dc=local" "objectclass=*" dn
>>
>> The -d 1 will make it spew debugging information.  Perhaps ldapsearch 
>> is picking up some option from /etc/openldap/ldap.conf or ~/.ldaprc 
>> which tells it to ignore certificate verification.
>>
>>> [13/Mar/2014:19:53:22 +0000] - Entry 
>>> "cn=meToadc13-els.bwinc.local,cn=replica,cn=dc\3Dops\2Cdc\3Dboingo\2Cdc\3Dcom,cn=mapping 
>>> tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not 
>>> allowed
>>> [13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:19:53:22 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:19:53:24 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>> [13/Mar/2014:19:53:25 +0000] slapi_ldap_bind - Error: could not send 
>>> startTLS request: error -11 (Connect error) errno 0 (Success)
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>> *Sent:* Thursday, March 13, 2014 12:05 PM
>>> *To:* Todd Maugh; freeipa-users at redhat.com
>>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>>
>>> On 03/13/2014 12:50 PM, Todd Maugh wrote:
>>>> Ok the error I see repeated in the log is
>>>>
>>>> [13/Mar/2014:18:41:21 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:43:11 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:43:14 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:43:20 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:43:32 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:43:56 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:44:30 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -1 (Can't contact LDAP server) errno 0 
>>>> (Success)
>>>> [13/Mar/2014:18:44:33 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:44:44 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:46:20 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:47:29 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:47:32 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:47:38 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:47:50 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:48:11 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:48:14 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:48:20 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:48:32 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [13/Mar/2014:18:48:56 +0000] slapi_ldap_bind - Error: could not 
>>>> send startTLS request: error -11 (Connect error) errno 0 (Success)
>>>> [root at idm-master-els.ops.boingo.com cacerts]$
>>>
>>> Are all of these associated with the winsync agreement?
>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>>> *Sent:* Thursday, March 13, 2014 11:43 AM
>>>> *To:* Todd Maugh; freeipa-users at redhat.com
>>>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>>>
>>>> On 03/13/2014 12:29 PM, Todd Maugh wrote:
>>>>> ok so I ran that and Get this output
>>>>
>>>> Ok.  Next, take a look at /var/log/dirsrv/slapd-OPS-BOINGO-COM/errors
>>>>
>>>>>
>>>>>
>>>>> [root at idm-master-els.ops.boingo.com cacerts]$ 
>>>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch 
>>>>> -xLLLZZ -h adc13-els.bwinc.local -D 
>>>>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX"  -s base -b 
>>>>> "cn=Users,dc=bwinc,dc=local"
>>>>> dn: cn=Users,dc=bwinc,dc=local
>>>>> objectClass: top
>>>>> objectClass: container
>>>>> cn: Users
>>>>> description: Default container for upgraded user accounts
>>>>> distinguishedName: CN=Users,DC=BWINC,DC=local
>>>>> instanceType: 4
>>>>> whenCreated: 20060824234034.0Z
>>>>> whenChanged: 20140306190741.0Z
>>>>> uSNCreated: 17702
>>>>> uSNChanged: 17702
>>>>> showInAdvancedViewOnly: FALSE
>>>>> name: Users
>>>>> objectGUID:: kCZ7CbnIZk+0GpmCr3PCfw==
>>>>> systemFlags: -1946157056
>>>>> objectCategory: 
>>>>> CN=Container,CN=Schema,CN=Configuration,DC=BWINC,DC=local
>>>>> isCriticalSystemObject: TRUE
>>>>> dSCorePropagationData: 20140306234416.0Z
>>>>> dSCorePropagationData: 20140306234348.0Z
>>>>> dSCorePropagationData: 20140306225101.0Z
>>>>> dSCorePropagationData: 20140306225055.0Z
>>>>> dSCorePropagationData: 16010101000000.0Z
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>>>> *Sent:* Wednesday, March 12, 2014 3:47 PM
>>>>> *To:* Todd Maugh; freeipa-users at redhat.com
>>>>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync agreement
>>>>>
>>>>> On 03/12/2014 04:39 PM, Todd Maugh wrote:
>>>>>> thanks Rich,
>>>>>>
>>>>>> when I run that  I get the following:
>>>>>>
>>>>>>
>>>>>> *[root at idm-master-els.ops.boingo.com ipa]$ 
>>>>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-OPS-BOINGO-COM ldapsearch 
>>>>>> -xLLLZZ -h adc13-els.bwinc.local -D 
>>>>>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" s base -b 
>>>>>> "cn=Users,dc=bwinc,dc=local"
>>>>>> ldap_bind: Invalid credentials (49)
>>>>>> *
>>>>>
>>>>> *Invalid credentials almost always means your password "XXXXXX" is 
>>>>> not correct for user "**cn=idmadmin,cn=Users,dc=bwinc,dc=local"
>>>>>
>>>>> *
>>>>>> *additional info: 80090308: LdapErr: DSID-0C0903C5, comment: 
>>>>>> AcceptSecurityContext error, data 52e, v2580
>>>>>> *
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>>>>> *Sent:* Wednesday, March 12, 2014 3:30 PM
>>>>>> *To:* Todd Maugh; freeipa-users at redhat.com
>>>>>> *Subject:* Re: [Freeipa-users] [freeipa] Issues with Winsync 
>>>>>> agreement
>>>>>>
>>>>>> On 03/12/2014 04:18 PM, Todd Maugh wrote:
>>>>>>> Hello.
>>>>>>>
>>>>>>> I'm using latest IPA build on red hat 6.5
>>>>>>>
>>>>>>> I retrieved my CA cert from the AD Domain controller
>>>>>>>
>>>>>>> I try to set up my winsyncagreement and I am getting this
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [root at idm-master-els.ops.boingo.com ipa]$ ipa-replica-manage 
>>>>>>> connect --winsync --binddn "cn=idmadmin, cn=Users, dc=bwinc, 
>>>>>>> dc=local" --bindpw "XXXXXX" --passsync "XXXXXX" 
>>>>>>> --cacert=/etc/openldap/cacerts/ADC13-ELS.CA.cer 
>>>>>>> adc13-els.bwinc.local
>>>>>>> Directory Manager password:
>>>>>>>
>>>>>>> Added CA certificate /etc/openldap/cacerts/ADC13-ELS.CA.cer to 
>>>>>>> certificate database for idm-master-els.ops.boingo.com
>>>>>>> ipa: INFO: Failed to connect to AD server adc13-els.bwinc.local
>>>>>>> ipa: INFO: The error was: {'info': '80090308: LdapErr: 
>>>>>>> DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, 
>>>>>>> v2580', 'desc': 'Invalid credentials'}
>>>>>>> Failed to setup winsync replication
>>>>>>>
>>>>>>>
>>>>>>> not sure where to look for the logs for this to see what the 
>>>>>>> invalivd credentials are or wether this might still be a cert 
>>>>>>> issue or a log in issue or what not?
>>>>>>
>>>>>> You can test with ldapsearch like this:
>>>>>>
>>>>>> $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch 
>>>>>> -xLLLZZ -h adc13-els.bwinc.local -D 
>>>>>> "cn=idmadmin,cn=Users,dc=bwinc,dc=local" -w "XXXXXX" -s base -b 
>>>>>> "cn=Users,dc=bwinc,dc=local"
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks in advance for the help
>>>>>>>
>>>>>>> -Todd
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Freeipa-users mailing list
>>>>>>> Freeipa-users at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/2d2fa0df/attachment.htm>

From tmaugh at boingo.com  Thu Mar 13 23:18:56 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 13 Mar 2014 23:18:56 +0000
Subject: [Freeipa-users] Password sync woes
Message-ID: <6FB698E172A95F49BE009B36D56F53E2297963@EXCHMB1-ELS.BWINC.local>

Sorry Guys me again.

So I have my winsync agreement up

and I know have my password sync setup

the cert has been imported

SSL is configured properly,

but when I go to change a password in AD

I see this error in passsync.log

LDAP error in QueryUsername
            32: No such object


any thoughts on this?

thanks

-Todd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/523dc3f5/attachment.htm>

From rmeggins at redhat.com  Thu Mar 13 23:24:09 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 13 Mar 2014 17:24:09 -0600
Subject: [Freeipa-users] Password sync woes
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2297963@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E2297963@EXCHMB1-ELS.BWINC.local>
Message-ID: <53223E19.7020803@redhat.com>

On 03/13/2014 05:18 PM, Todd Maugh wrote:
> Sorry Guys me again.
>
> So I have my winsync agreement up
>
> and I know have my password sync setup
>
> the cert has been imported
>
> SSL is configured properly,
>
> but when I go to change a password in AD
>
> I see this error in passsync.log
>
> LDAP error in QueryUsername
>             32: No such object

It means your suffix/base DN that you used in PassSync setup is incorrect.
You can check the access log to see what it is doing - 
/var/log/dirsrv/slapd-YOUR-DOMAIN/access - look for connections from the 
IP address of your AD machine.
Note that the suffix/base DN that you used in PassSync setup is the 
suffix/base DN of your IdM server, which is not necessarily the same as 
your AD server.

>
>
> any thoughts on this?
>
> thanks
>
> -Todd
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140313/c9eb45a3/attachment.htm>

From tmaugh at boingo.com  Fri Mar 14 16:58:27 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Fri, 14 Mar 2014 16:58:27 +0000
Subject: [Freeipa-users] Password sync woes
In-Reply-To: <53223E19.7020803@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E2297963@EXCHMB1-ELS.BWINC.local>
	<53223E19.7020803@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E2297F6B@EXCHMB1-ELS.BWINC.local>

Thank you Rich, must have been a type-o in my install, I gutted it restarted it and am All good now thank you

From: Rich Megginson [mailto:rmeggins at redhat.com]
Sent: Thursday, March 13, 2014 4:24 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] Password sync woes

On 03/13/2014 05:18 PM, Todd Maugh wrote:
Sorry Guys me again.

So I have my winsync agreement up

and I know have my password sync setup

the cert has been imported

SSL is configured properly,

but when I go to change a password in AD

I see this error in passsync.log

LDAP error in QueryUsername
            32: No such object

It means your suffix/base DN that you used in PassSync setup is incorrect.
You can check the access log to see what it is doing - /var/log/dirsrv/slapd-YOUR-DOMAIN/access - look for connections from the IP address of your AD machine.
Note that the suffix/base DN that you used in PassSync setup is the suffix/base DN of your IdM server, which is not necessarily the same as your AD server.




any thoughts on this?

thanks

-Todd




_______________________________________________

Freeipa-users mailing list

Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>

https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140314/68136a4b/attachment.htm>

From rmeggins at redhat.com  Fri Mar 14 16:59:31 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Fri, 14 Mar 2014 10:59:31 -0600
Subject: [Freeipa-users] Password sync woes
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2297F6B@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E2297963@EXCHMB1-ELS.BWINC.local>
	<53223E19.7020803@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E2297F6B@EXCHMB1-ELS.BWINC.local>
Message-ID: <53233573.4080200@redhat.com>

On 03/14/2014 10:58 AM, Todd Maugh wrote:
>
> Thank you Rich, must have been a type-o in my install, I gutted it 
> restarted it and am All good now thank you
>

Great!

> *From:*Rich Megginson [mailto:rmeggins at redhat.com]
> *Sent:* Thursday, March 13, 2014 4:24 PM
> *To:* Todd Maugh; freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] Password sync woes
>
> On 03/13/2014 05:18 PM, Todd Maugh wrote:
>
>     Sorry Guys me again.
>
>     So I have my winsync agreement up
>
>     and I know have my password sync setup
>
>     the cert has been imported
>
>     SSL is configured properly,
>
>     but when I go to change a password in AD
>
>     I see this error in passsync.log
>
>     LDAP error in QueryUsername
>                 32: No such object
>
>
> It means your suffix/base DN that you used in PassSync setup is incorrect.
> You can check the access log to see what it is doing - 
> /var/log/dirsrv/slapd-YOUR-DOMAIN/access - look for connections from 
> the IP address of your AD machine.
> Note that the suffix/base DN that you used in PassSync setup is the 
> suffix/base DN of your IdM server, which is not necessarily the same 
> as your AD server.
>
>
>
>
>     any thoughts on this?
>
>     thanks
>
>     -Todd
>
>
>
>
>     _______________________________________________
>
>     Freeipa-users mailing list
>
>     Freeipa-users at redhat.com  <mailto:Freeipa-users at redhat.com>
>
>     https://www.redhat.com/mailman/listinfo/freeipa-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140314/3483904a/attachment.htm>

From tmaugh at boingo.com  Fri Mar 14 17:13:24 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Fri, 14 Mar 2014 17:13:24 +0000
Subject: [Freeipa-users] winsync agreement for multiple subtrees
Message-ID: <041DAE97-7D6A-400F-BDEB-EF5613B79FEA@boingo.com>

good morning, every day it's something new.

so turns out my AD admin has built ad with user accounts spread out over multiple subtrees' and I need to handle them all.

is there a way to sync everything under dc=bwinc,dc=local. instead of doing cn=users,dc=bwinc,dc=local

does this make sense?

thank you

-Todd Maugh



From tmaugh at boingo.com  Fri Mar 14 18:06:35 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Fri, 14 Mar 2014 18:06:35 +0000
Subject: [Freeipa-users] winsync agreement for multiple subtrees
In-Reply-To: <041DAE97-7D6A-400F-BDEB-EF5613B79FEA@boingo.com>
References: <041DAE97-7D6A-400F-BDEB-EF5613B79FEA@boingo.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E2298592@EXCHMB1-ELS.BWINC.local>

I did find this similar request that I thought looked to be owned by Rich  Megginson

https://fedorahosted.org/389/ticket/460

Rich Can you shed any light on this, or the command I would use to winsync multiple subtrees?


________________________________________
From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com]
Sent: Friday, March 14, 2014 10:13 AM
To: freeipa-users at redhat.com
Subject: [Freeipa-users] winsync agreement for multiple subtrees

good morning, every day it's something new.

so turns out my AD admin has built ad with user accounts spread out over multiple subtrees' and I need to handle them all.

is there a way to sync everything under dc=bwinc,dc=local. instead of doing cn=users,dc=bwinc,dc=local

does this make sense?

thank you

-Todd Maugh

_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



From rmeggins at redhat.com  Fri Mar 14 18:12:37 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Fri, 14 Mar 2014 12:12:37 -0600
Subject: [Freeipa-users] winsync agreement for multiple subtrees
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E2298592@EXCHMB1-ELS.BWINC.local>
References: <041DAE97-7D6A-400F-BDEB-EF5613B79FEA@boingo.com>
	<6FB698E172A95F49BE009B36D56F53E2298592@EXCHMB1-ELS.BWINC.local>
Message-ID: <53234695.8060401@redhat.com>

On 03/14/2014 12:06 PM, Todd Maugh wrote:
> I did find this similar request that I thought looked to be owned by Rich  Megginson
>
> https://fedorahosted.org/389/ticket/460
>
> Rich Can you shed any light on this, or the command I would use to winsync multiple subtrees?

If you can't sync from the top level entry e.g. if you can't sync using 
dc=bwinc,dc=local as your AD subtree, then you can't do it. It may or 
may not work for you, I don't know, you'll just have to try it.

>
>
> ________________________________________
> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com]
> Sent: Friday, March 14, 2014 10:13 AM
> To: freeipa-users at redhat.com
> Subject: [Freeipa-users] winsync agreement for multiple subtrees
>
> good morning, every day it's something new.
>
> so turns out my AD admin has built ad with user accounts spread out over multiple subtrees' and I need to handle them all.
>
> is there a way to sync everything under dc=bwinc,dc=local. instead of doing cn=users,dc=bwinc,dc=local
>
> does this make sense?
>
> thank you
>
> -Todd Maugh
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users



From tmaugh at boingo.com  Fri Mar 14 18:24:32 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Fri, 14 Mar 2014 18:24:32 +0000
Subject: [Freeipa-users] winsync agreement for multiple subtrees
In-Reply-To: <53234695.8060401@redhat.com>
References: <041DAE97-7D6A-400F-BDEB-EF5613B79FEA@boingo.com>
	<6FB698E172A95F49BE009B36D56F53E2298592@EXCHMB1-ELS.BWINC.local>,
	<53234695.8060401@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E229865E@EXCHMB1-ELS.BWINC.local>

I actually hadnt tried yet to sync from the top level directory

would I just leave the CN out to try that? 
________________________________________
From: Rich Megginson [rmeggins at redhat.com]
Sent: Friday, March 14, 2014 11:12 AM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: winsync agreement for multiple subtrees

On 03/14/2014 12:06 PM, Todd Maugh wrote:
> I did find this similar request that I thought looked to be owned by Rich  Megginson
>
> https://fedorahosted.org/389/ticket/460
>
> Rich Can you shed any light on this, or the command I would use to winsync multiple subtrees?

If you can't sync from the top level entry e.g. if you can't sync using
dc=bwinc,dc=local as your AD subtree, then you can't do it. It may or
may not work for you, I don't know, you'll just have to try it.

>
>
> ________________________________________
> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com]
> Sent: Friday, March 14, 2014 10:13 AM
> To: freeipa-users at redhat.com
> Subject: [Freeipa-users] winsync agreement for multiple subtrees
>
> good morning, every day it's something new.
>
> so turns out my AD admin has built ad with user accounts spread out over multiple subtrees' and I need to handle them all.
>
> is there a way to sync everything under dc=bwinc,dc=local. instead of doing cn=users,dc=bwinc,dc=local
>
> does this make sense?
>
> thank you
>
> -Todd Maugh
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users




From rmeggins at redhat.com  Fri Mar 14 18:36:28 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Fri, 14 Mar 2014 12:36:28 -0600
Subject: [Freeipa-users] winsync agreement for multiple subtrees
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229865E@EXCHMB1-ELS.BWINC.local>
References: <041DAE97-7D6A-400F-BDEB-EF5613B79FEA@boingo.com>
	<6FB698E172A95F49BE009B36D56F53E2298592@EXCHMB1-ELS.BWINC.local>,
	<53234695.8060401@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229865E@EXCHMB1-ELS.BWINC.local>
Message-ID: <53234C2C.5070301@redhat.com>

On 03/14/2014 12:24 PM, Todd Maugh wrote:
> I actually hadnt tried yet to sync from the top level directory
>
> would I just leave the CN out to try that?
The cn=users? Yes.
>   
> ________________________________________
> From: Rich Megginson [rmeggins at redhat.com]
> Sent: Friday, March 14, 2014 11:12 AM
> To: Todd Maugh; freeipa-users at redhat.com
> Subject: Re: winsync agreement for multiple subtrees
>
> On 03/14/2014 12:06 PM, Todd Maugh wrote:
>> I did find this similar request that I thought looked to be owned by Rich  Megginson
>>
>> https://fedorahosted.org/389/ticket/460
>>
>> Rich Can you shed any light on this, or the command I would use to winsync multiple subtrees?
> If you can't sync from the top level entry e.g. if you can't sync using
> dc=bwinc,dc=local as your AD subtree, then you can't do it. It may or
> may not work for you, I don't know, you'll just have to try it.
>
>>
>> ________________________________________
>> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Todd Maugh [tmaugh at boingo.com]
>> Sent: Friday, March 14, 2014 10:13 AM
>> To: freeipa-users at redhat.com
>> Subject: [Freeipa-users] winsync agreement for multiple subtrees
>>
>> good morning, every day it's something new.
>>
>> so turns out my AD admin has built ad with user accounts spread out over multiple subtrees' and I need to handle them all.
>>
>> is there a way to sync everything under dc=bwinc,dc=local. instead of doing cn=users,dc=bwinc,dc=local
>>
>> does this make sense?
>>
>> thank you
>>
>> -Todd Maugh
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users



From shreerajkarulkar at yahoo.com  Fri Mar 14 18:43:40 2014
From: shreerajkarulkar at yahoo.com (Shree)
Date: Fri, 14 Mar 2014 11:43:40 -0700 (PDT)
Subject: [Freeipa-users] sudo to local users prompts for password
Message-ID: <1394822620.83910.YahooMailNeo@web160104.mail.bf1.yahoo.com>

Hello

We just upgraded our clients from ipa-client-2.2.0-16.el6.x86_64 to ipa-client-3.0.0-37.el6.x86_64 and started noticing this. We have some scripts which sudo to a local account like "apache" and run. Earlier we were never prompted to put apache's password, now it is. Any thoughts?


?
Shreeraj 
---------------------------------------------------------------------------------------- 

Change is the only Constant !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140314/6bba5195/attachment.htm>

From tmaugh at boingo.com  Fri Mar 14 19:20:24 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Fri, 14 Mar 2014 19:20:24 +0000
Subject: [Freeipa-users] IPA / AD Trust
Message-ID: <6FB698E172A95F49BE009B36D56F53E22987C4@EXCHMB1-ELS.BWINC.local>

Does IPA support a trust with AD yet.

I've seen that this is coming in a future release but I havent found something that said it has been released.

-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140314/07b21470/attachment.htm>

From dpal at redhat.com  Fri Mar 14 21:00:25 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 14 Mar 2014 17:00:25 -0400
Subject: [Freeipa-users] sudo to local users prompts for password
In-Reply-To: <1394822620.83910.YahooMailNeo@web160104.mail.bf1.yahoo.com>
References: <1394822620.83910.YahooMailNeo@web160104.mail.bf1.yahoo.com>
Message-ID: <53236DE9.6010707@redhat.com>

On 03/14/2014 02:43 PM, Shree wrote:
> Hello
>
> We just upgraded our clients from ipa-client-2.2.0-16.el6.x86_64 to 
> ipa-client-3.0.0-37.el6.x86_64 and started noticing this. We have some 
> scripts which sudo to a local account like "apache" and run. Earlier 
> we were never prompted to put apache's password, now it is. Any thoughts?
>
> Shreeraj
> ---------------------------------------------------------------------------------------- 
>
>
> Change is the only Constant !
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
No attachment.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140314/7da32104/attachment.htm>

From dpal at redhat.com  Fri Mar 14 21:01:21 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 14 Mar 2014 17:01:21 -0400
Subject: [Freeipa-users] IPA / AD Trust
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E22987C4@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E22987C4@EXCHMB1-ELS.BWINC.local>
Message-ID: <53236E21.5070606@redhat.com>

On 03/14/2014 03:20 PM, Todd Maugh wrote:
> Does IPA support a trust with AD yet.
>
> I've seen that this is coming in a future release but I havent found 
> something that said it has been released.
>
> -Todd
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
IPA 3.3.x + SSSD 1.11.x

It is release upstream and in Fedora. Will be a part of RHEL7 release.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140314/ecc68700/attachment.htm>

From rcritten at redhat.com  Fri Mar 14 21:03:23 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Fri, 14 Mar 2014 17:03:23 -0400
Subject: [Freeipa-users] sudo to local users prompts for password
In-Reply-To: <53236DE9.6010707@redhat.com>
References: <1394822620.83910.YahooMailNeo@web160104.mail.bf1.yahoo.com>
	<53236DE9.6010707@redhat.com>
Message-ID: <53236E9B.2060306@redhat.com>

Dmitri Pal wrote:
> On 03/14/2014 02:43 PM, Shree wrote:
>> Hello
>>
>> We just upgraded our clients from ipa-client-2.2.0-16.el6.x86_64 to
>> ipa-client-3.0.0-37.el6.x86_64 and started noticing this. We have some
>> scripts which sudo to a local account like "apache" and run. Earlier
>> we were never prompted to put apache's password, now it is. Any thoughts?
>>
>> Shreeraj
>> ----------------------------------------------------------------------------------------
>>
>>
>> Change is the only Constant !
>>
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
> No attachment.

I tend to agree with Dmitri here. What other package(s) were updated at 
the same time?

Normally merely updating packages won't affect the IPA client 
configuration. You'd need to re-run ipa-client-install. So I don't quite 
understand why the change either.

Are you using ldap or sssd for sudo? I would assume ldap given the old 
2.x client.

rob



From sigbjorn at nixtra.com  Sat Mar 15 09:51:05 2014
From: sigbjorn at nixtra.com (Sigbjorn Lie)
Date: Sat, 15 Mar 2014 10:51:05 +0100
Subject: [Freeipa-users] AIX kerberos client to IPA
In-Reply-To: <loom.20140312T224425-846@post.gmane.org>
References: <loom.20140312T224425-846@post.gmane.org>
Message-ID: <53242289.9090703@nixtra.com>

On 12/03/14 22:52, Rob wrote:
> Hi,
>
> I have configured an AIX 6.1 server to connect to a RHEL 6.5 IPA server. The
> AIX server is configured to use netgroups and all that works for existing the
> users.
>
> The problem is when a users password expires or when a new user is created.
> They cannot change their password
>
> WARNING: Your password has expired.
> You must change your password now and login again!
> Changing password for "testuser"
> testuser's Old password:
> testuser's New password:
> Connection to localhost closed.
>
> The problem seems to be related to not getting a kerberos ticket as kinit can
> be used to change the password.
>
> Logging is enabled but no logs ever get updated
>
> [logging]
>          kdc = FILE:/var/krb5/log/krb5kdc.log
>          admin_server = FILE:/var/krb5/log/kadmin.log
>          kadmin_local = FILE:/var/krb5/log/kadmin_local.log
>          default = FILE:/var/krb5/log/krb5lib.log
>
> Anybody ever come across this? Or know how to get logging working?
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

*

I am not familiar with AIX. Just quick tip for what we had to do on Solaris to make password changes work - as the issue sounded somewhat familiar... :)

We have to set "kpasswd_protocol = SET_CHANGE" to krb5.conf when used with any "non-Solaris KDC".

Perhaps you have a similar setting for AIX?



*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140315/bf1a0287/attachment.htm>

From barrykfl at gmail.com  Mon Mar 17 13:50:07 2014
From: barrykfl at gmail.com (barrykfl at gmail.com)
Date: Mon, 17 Mar 2014 21:50:07 +0800
Subject: [Freeipa-users] Any command can change the direcoty manager password
Message-ID: <CAELz9duXY=vzZcp70Ak2tf-_b0Z7yTJZqp5Fc42Je0PQzia-jg@mail.gmail.com>

hi:

I accidently changed uid admin 's password  ...and then change back orginal.

BUT it seem that it also modify CN+directory manager also can now conflcit.s

soem user cann not access using if cn= direcory manager.

any idea ? i tried the follwig command it says ssl conenection already
establsied and error.


~]# LDAPTLS_CACERT=/etc/ipa/ca.crt ldappasswd \
           -ZZ -D 'cn=directory manager' -W \
           -S uid=admin,cn=users,cn=accounts,dc=domain,dc=com
New password:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140317/ea151da1/attachment.htm>

From rmeggins at redhat.com  Mon Mar 17 14:02:38 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Mon, 17 Mar 2014 08:02:38 -0600
Subject: [Freeipa-users] Any command can change the direcoty manager
	password
In-Reply-To: <CAELz9duXY=vzZcp70Ak2tf-_b0Z7yTJZqp5Fc42Je0PQzia-jg@mail.gmail.com>
References: <CAELz9duXY=vzZcp70Ak2tf-_b0Z7yTJZqp5Fc42Je0PQzia-jg@mail.gmail.com>
Message-ID: <5327007E.3010203@redhat.com>

On 03/17/2014 07:50 AM, barrykfl at gmail.com wrote:
> hi:
>
> I accidently changed uid admin 's password  ...and then change back 
> orginal.
>
> BUT it seem that it also modify CN+directory manager also can now 
> conflcit.s

The below command changed the password for cn=directory manager?????

What do you mean by "conflicts"?

>
> soem user cann not access using if cn= direcory manager.

???

>
> any idea ? i tried the follwig command it says ssl conenection already 
> establsied and error.
>
>
> ~]# LDAPTLS_CACERT=/etc/ipa/ca.crt ldappasswd \
>            -ZZ -D 'cn=directory manager' -W \
>            -S uid=admin,cn=users,cn=accounts,dc=domain,dc=com
> New password:

Add -d 1 like this: ..... ldappasswd -d 1 .....

That will cause debugging output from ldappasswd

>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140317/1d78127b/attachment.htm>

From rcritten at redhat.com  Mon Mar 17 14:03:47 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 17 Mar 2014 10:03:47 -0400
Subject: [Freeipa-users] Any command can change the direcoty manager
	password
In-Reply-To: <CAELz9duXY=vzZcp70Ak2tf-_b0Z7yTJZqp5Fc42Je0PQzia-jg@mail.gmail.com>
References: <CAELz9duXY=vzZcp70Ak2tf-_b0Z7yTJZqp5Fc42Je0PQzia-jg@mail.gmail.com>
Message-ID: <532700C3.1050307@redhat.com>

barrykfl at gmail.com wrote:
> hi:
>
> I accidently changed uid admin 's password  ...and then change back orginal.
>
> BUT it seem that it also modify CN+directory manager also can now conflcit.s
>
> soem user cann not access using if cn= direcory manager.
>
> any idea ? i tried the follwig command it says ssl conenection already
> establsied and error.
>
>
> ~]# LDAPTLS_CACERT=/etc/ipa/ca.crt ldappasswd \
>             -ZZ -D 'cn=directory manager' -W \
>             -S uid=admin,cn=users,cn=accounts,dc=domain,dc=com
> New password:

I'm not sure I entirely follow you. From what I understand the admin 
password was changed and you'd like to change it back but are having a 
problem doing this using ldappasswd as Directory Manager?

/etc/openldap/ldap.conf may be pre-configured to use an ldaps URI which 
explains the SSL already established part. It will also define 
TLS_CACERT for you.

Try dropping the -ZZ, like this:

$ ldappasswd -D 'cn=directory manager' -W \
-S uid=admin,cn=users,cn=accounts,dc=domain,dc=com

rob



From barrykfl at gmail.com  Mon Mar 17 14:34:09 2014
From: barrykfl at gmail.com (barrykfl at gmail.com)
Date: Mon, 17 Mar 2014 22:34:09 +0800
Subject: [Freeipa-users] Change admin password will change directory manager
	also ???
Message-ID: <CAELz9dtGM1NfP_uSPTVtPRAGmTeBm1c+QrgjA9+vheTfPEBQ=g@mail.gmail.com>

Dear all:
As title ?

I changed admin (uid) and then change back orginal passwd . It seem it also
syn to directoy manager. I wonder

Now all applications integrated wih using CN=directory manger all fail to
connect authroization fail.

Any idea ? should i also change the directory manager password also ?

Any command annd ref can use ?


Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140317/16909960/attachment.htm>

From rmeggins at redhat.com  Mon Mar 17 14:43:50 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Mon, 17 Mar 2014 08:43:50 -0600
Subject: [Freeipa-users] Change admin password will change directory
 manager also ???
In-Reply-To: <CAELz9dtGM1NfP_uSPTVtPRAGmTeBm1c+QrgjA9+vheTfPEBQ=g@mail.gmail.com>
References: <CAELz9dtGM1NfP_uSPTVtPRAGmTeBm1c+QrgjA9+vheTfPEBQ=g@mail.gmail.com>
Message-ID: <53270A26.4000907@redhat.com>

On 03/17/2014 08:34 AM, barrykfl at gmail.com wrote:
> Dear all:
> As title ?
>
> I changed admin (uid) and then change back orginal passwd . It seem it 
> also syn to directoy manager. I wonder
>
> Now all applications integrated wih using CN=directory manger all fail 
> to connect authroization fail.
>
> Any idea ? should i also change the directory manager password also ?
>
> Any command annd ref can use ?
>
>
> Thanks
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140317/496de2d6/attachment.htm>

From rmeggins at redhat.com  Mon Mar 17 14:46:06 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Mon, 17 Mar 2014 08:46:06 -0600
Subject: [Freeipa-users] Change admin password will change directory
 manager also ???
In-Reply-To: <CAELz9dtGM1NfP_uSPTVtPRAGmTeBm1c+QrgjA9+vheTfPEBQ=g@mail.gmail.com>
References: <CAELz9dtGM1NfP_uSPTVtPRAGmTeBm1c+QrgjA9+vheTfPEBQ=g@mail.gmail.com>
Message-ID: <53270AAE.3020808@redhat.com>

On 03/17/2014 08:34 AM, barrykfl at gmail.com wrote:
> Dear all:
> As title ?
>
> I changed admin (uid) and then change back orginal passwd . It seem it 
> also syn to directoy manager. I wonder

Using ldappasswd changed both the uid=admin password, and directory 
manager password?

Can you confirm that using ldapwhoami?

>
> Now all applications integrated wih using CN=directory manger all fail 
> to connect authroization fail.

I can't encourage you strongly enough to _not_ use cn=directory manager 
for applications.

>
> Any idea ? should i also change the directory manager password also ?

Please confirm above.

>
> Any command annd ref can use ?
>
>
> Thanks
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140317/511e4af5/attachment.htm>

From tmaugh at boingo.com  Mon Mar 17 21:33:02 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Mon, 17 Mar 2014 21:33:02 +0000
Subject: [Freeipa-users] Has one successfully synched the entirety of their
 AD to IPA (multiple OUs and or Subtrees)
Message-ID: <6FB698E172A95F49BE009B36D56F53E229A2A1@EXCHMB1-ELS.BWINC.local>

I'm trying to sync all of my AD to IPA, I don't need to retain any of the original windows directory structure once in IPA.

I cannot find where to set ipaWinSyncUserFlatten to true (so I'm assuming it's on true by default)

I really need to be able to sync more than just the cn=users subtree

And I can find no documentation or help on line.


Has anyone had any success or practice with this?

Thanks

-Todd

Todd Maugh
Sr System Engineer
Boingo Wireless
tmaugh at boingo.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140317/6e3a0ec8/attachment.htm>

From rmeggins at redhat.com  Mon Mar 17 21:43:55 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Mon, 17 Mar 2014 15:43:55 -0600
Subject: [Freeipa-users] Has one successfully synched the entirety of
 their AD to IPA (multiple OUs and or Subtrees)
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229A2A1@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229A2A1@EXCHMB1-ELS.BWINC.local>
Message-ID: <53276C9B.7000909@redhat.com>

On 03/17/2014 03:33 PM, Todd Maugh wrote:
>
> I'm trying to sync all of my AD to IPA, I don't need to retain any of 
> the original windows directory structure once in IPA.
>
> I cannot find where to set ipaWinSyncUserFlatten to true (so I'm 
> assuming it's on true by default)
>

Yes, it is true by default.
dn: cn=ipa-winsync,cn=plugins,cn=config

> I really need to be able to sync more than just the cn=users subtree
>

There really isn't explicit support for this.  If it doesn't work to set 
your AD subtree to your root suffix (e.g. dc=domain,dc=com), then it's 
simply not going to work until 389 adds support for that.

> And I can find no documentation or help on line.
>

Because there probably isn't any.

> Has anyone had any success or practice with this?
>

See above.
>
> Thanks
>
> -Todd
>
> Todd Maugh
>
> Sr System Engineer
>
> *Boingo Wireless*
>
> *tmaugh at boingo.com*
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140317/f1c57094/attachment.htm>

From tmaugh at boingo.com  Mon Mar 17 21:52:11 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Mon, 17 Mar 2014 21:52:11 +0000
Subject: [Freeipa-users] Has one successfully synched the entirety of
 their AD to IPA (multiple OUs and or Subtrees)
In-Reply-To: <53276C9B.7000909@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E229A2A1@EXCHMB1-ELS.BWINC.local>
	<53276C9B.7000909@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E229A2CB@EXCHMB1-ELS.BWINC.local>

Thanks Rich,

I am able to create a successful winsync agreement from the top level.

Unfortunately, when I do this. I do not see any of the accounts from the sub trees populate my ipa server.

Is it possible to have all the subtrees (ous) live under cn=users. If I make this change to AD would IPA then sync all the accounts from the subtrees? I cant believe I am the first person with this issue or need.

Thanks again in advance.


From: Rich Megginson [mailto:rmeggins at redhat.com]
Sent: Monday, March 17, 2014 2:44 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] Has one successfully synched the entirety of their AD to IPA (multiple OUs and or Subtrees)

On 03/17/2014 03:33 PM, Todd Maugh wrote:
I'm trying to sync all of my AD to IPA, I don't need to retain any of the original windows directory structure once in IPA.

I cannot find where to set ipaWinSyncUserFlatten to true (so I'm assuming it's on true by default)

Yes, it is true by default.
dn: cn=ipa-winsync,cn=plugins,cn=config



I really need to be able to sync more than just the cn=users subtree

There really isn't explicit support for this.  If it doesn't work to set your AD subtree to your root suffix (e.g. dc=domain,dc=com), then it's simply not going to work until 389 adds support for that.



And I can find no documentation or help on line.

Because there probably isn't any.




Has anyone had any success or practice with this?

See above.


Thanks

-Todd

Todd Maugh
Sr System Engineer
Boingo Wireless
tmaugh at boingo.com<mailto:tmaugh at boingo.com>





_______________________________________________

Freeipa-users mailing list

Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>

https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140317/20635a9d/attachment.htm>

From rmeggins at redhat.com  Mon Mar 17 22:03:17 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Mon, 17 Mar 2014 16:03:17 -0600
Subject: [Freeipa-users] Has one successfully synched the entirety of
 their AD to IPA (multiple OUs and or Subtrees)
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229A2CB@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229A2A1@EXCHMB1-ELS.BWINC.local>
	<53276C9B.7000909@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229A2CB@EXCHMB1-ELS.BWINC.local>
Message-ID: <53277125.6020409@redhat.com>

On 03/17/2014 03:52 PM, Todd Maugh wrote:
>
> Thanks Rich,
>
> I am able to create a successful winsync agreement from the top level.
>
> Unfortunately, when I do this. I do not see any of the accounts from 
> the sub trees populate my ipa server.
>

Ok, so it doesn't work.

> Is it possible to have all the subtrees (ous) live under cn=users.If I 
> make this change to AD would IPA then sync all the accounts from the 
> subtrees?
>

Yes.

> I cant believe I am the first person with this issue or need.
>

You are certainly not - we have a couple of 389 to address this and 
similar issues with winsync.

https://fedorahosted.org/389/ticket/460

Unfortunately, this fix has been targeted for F20 (389-ds-base-1.3.2), 
and we don't have plans to backport to EL6.

Note that winsync is always going to be more or less painful - it is 
not, was never designed to be, and never will be a full blown 
meta-directory solution.  For more information:

https://fedorahosted.org/389/query?component=Sync+Service&status=accepted&status=assigned&status=new&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority&report=16

That's why we recommend that the best long term solution is cross domain 
trust - that removes winsync from the picture.

> Thanks again in advance.
>
> *From:*Rich Megginson [mailto:rmeggins at redhat.com]
> *Sent:* Monday, March 17, 2014 2:44 PM
> *To:* Todd Maugh; freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] Has one successfully synched the 
> entirety of their AD to IPA (multiple OUs and or Subtrees)
>
> On 03/17/2014 03:33 PM, Todd Maugh wrote:
>
>     I'm trying to sync all of my AD to IPA, I don't need to retain any
>     of the original windows directory structure once in IPA.
>
>     I cannot find where to set ipaWinSyncUserFlatten to true (so I'm
>     assuming it's on true by default)
>
>
> Yes, it is true by default.
> dn: cn=ipa-winsync,cn=plugins,cn=config
>
>
>     I really need to be able to sync more than just the cn=users subtree
>
>
> There really isn't explicit support for this.  If it doesn't work to 
> set your AD subtree to your root suffix (e.g. dc=domain,dc=com), then 
> it's simply not going to work until 389 adds support for that.
>
>
>     And I can find no documentation or help on line.
>
>
> Because there probably isn't any.
>
>
>     Has anyone had any success or practice with this?
>
>
> See above.
>
>     Thanks
>
>     -Todd
>
>     Todd Maugh
>
>     Sr System Engineer
>
>     *Boingo Wireless*
>
>     *tmaugh at boingo.com <mailto:tmaugh at boingo.com>*
>
>
>
>
>     _______________________________________________
>
>     Freeipa-users mailing list
>
>     Freeipa-users at redhat.com  <mailto:Freeipa-users at redhat.com>
>
>     https://www.redhat.com/mailman/listinfo/freeipa-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140317/d2956cdb/attachment.htm>

From tmaugh at boingo.com  Mon Mar 17 22:04:24 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Mon, 17 Mar 2014 22:04:24 +0000
Subject: [Freeipa-users] Has one successfully synched the entirety of
 their AD to IPA (multiple OUs and or Subtrees)
In-Reply-To: <53277125.6020409@redhat.com>
References: <6FB698E172A95F49BE009B36D56F53E229A2A1@EXCHMB1-ELS.BWINC.local>
	<53276C9B.7000909@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229A2CB@EXCHMB1-ELS.BWINC.local>
	<53277125.6020409@redhat.com>
Message-ID: <6FB698E172A95F49BE009B36D56F53E229A311@EXCHMB1-ELS.BWINC.local>

Thanks again Rich is there some good Documentation on setting up the trust?

From: Rich Megginson [mailto:rmeggins at redhat.com]
Sent: Monday, March 17, 2014 3:03 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] Has one successfully synched the entirety of their AD to IPA (multiple OUs and or Subtrees)

On 03/17/2014 03:52 PM, Todd Maugh wrote:
Thanks Rich,

I am able to create a successful winsync agreement from the top level.

Unfortunately, when I do this. I do not see any of the accounts from the sub trees populate my ipa server.

Ok, so it doesn't work.



Is it possible to have all the subtrees (ous) live under cn=users.If I make this change to AD would IPA then sync all the accounts from the subtrees?

Yes.


I cant believe I am the first person with this issue or need.

You are certainly not - we have a couple of 389 to address this and similar issues with winsync.

https://fedorahosted.org/389/ticket/460

Unfortunately, this fix has been targeted for F20 (389-ds-base-1.3.2), and we don't have plans to backport to EL6.

Note that winsync is always going to be more or less painful - it is not, was never designed to be, and never will be a full blown meta-directory solution.  For more information:

https://fedorahosted.org/389/query?component=Sync+Service&status=accepted&status=assigned&status=new&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority&report=16

That's why we recommend that the best long term solution is cross domain trust - that removes winsync from the picture.



Thanks again in advance.


From: Rich Megginson [mailto:rmeggins at redhat.com]
Sent: Monday, March 17, 2014 2:44 PM
To: Todd Maugh; freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: Re: [Freeipa-users] Has one successfully synched the entirety of their AD to IPA (multiple OUs and or Subtrees)

On 03/17/2014 03:33 PM, Todd Maugh wrote:
I'm trying to sync all of my AD to IPA, I don't need to retain any of the original windows directory structure once in IPA.

I cannot find where to set ipaWinSyncUserFlatten to true (so I'm assuming it's on true by default)

Yes, it is true by default.
dn: cn=ipa-winsync,cn=plugins,cn=config




I really need to be able to sync more than just the cn=users subtree

There really isn't explicit support for this.  If it doesn't work to set your AD subtree to your root suffix (e.g. dc=domain,dc=com), then it's simply not going to work until 389 adds support for that.




And I can find no documentation or help on line.

Because there probably isn't any.





Has anyone had any success or practice with this?

See above.



Thanks

-Todd

Todd Maugh
Sr System Engineer
Boingo Wireless
tmaugh at boingo.com<mailto:tmaugh at boingo.com>






_______________________________________________

Freeipa-users mailing list

Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>

https://www.redhat.com/mailman/listinfo/freeipa-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140317/d9c7eb12/attachment.htm>

From dpal at redhat.com  Mon Mar 17 22:12:42 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 17 Mar 2014 18:12:42 -0400
Subject: [Freeipa-users] Has one successfully synched the entirety of
 their AD to IPA (multiple OUs and or Subtrees)
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229A311@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229A2A1@EXCHMB1-ELS.BWINC.local>
	<53276C9B.7000909@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229A2CB@EXCHMB1-ELS.BWINC.local>
	<53277125.6020409@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229A311@EXCHMB1-ELS.BWINC.local>
Message-ID: <5327735A.2010909@redhat.com>

On 03/17/2014 06:04 PM, Todd Maugh wrote:
>
> Thanks again Rich is there some good Documentation on setting up the 
> trust?
>

http://www.freeipa.org/page/IPAv3_testing_AD_trust

> *From:*Rich Megginson [mailto:rmeggins at redhat.com]
> *Sent:* Monday, March 17, 2014 3:03 PM
> *To:* Todd Maugh; freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] Has one successfully synched the 
> entirety of their AD to IPA (multiple OUs and or Subtrees)
>
> On 03/17/2014 03:52 PM, Todd Maugh wrote:
>
>     Thanks Rich,
>
>     I am able to create a successful winsync agreement from the top
>     level.
>
>     Unfortunately, when I do this. I do not see any of the accounts
>     from the sub trees populate my ipa server.
>
>
> Ok, so it doesn't work.
>
>
>     Is it possible to have all the subtrees (ous) live under
>     cn=users.If I make this change to AD would IPA then sync all the
>     accounts from the subtrees?
>
>
> Yes.
>
>
>     I cant believe I am the first person with this issue or need.
>
>
> You are certainly not - we have a couple of 389 to address this and 
> similar issues with winsync.
>
> https://fedorahosted.org/389/ticket/460
>
> Unfortunately, this fix has been targeted for F20 (389-ds-base-1.3.2), 
> and we don't have plans to backport to EL6.
>
> Note that winsync is always going to be more or less painful - it is 
> not, was never designed to be, and never will be a full blown 
> meta-directory solution.  For more information:
>
> https://fedorahosted.org/389/query?component=Sync+Service&status=accepted&status=assigned&status=new&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority&report=16 
> <https://fedorahosted.org/389/query?component=Sync+Service&status=accepted&status=assigned&status=new&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority&report=16>
>
> That's why we recommend that the best long term solution is cross 
> domain trust - that removes winsync from the picture.
>
>
>     Thanks again in advance.
>
>     *From:*Rich Megginson [mailto:rmeggins at redhat.com]
>     *Sent:* Monday, March 17, 2014 2:44 PM
>     *To:* Todd Maugh; freeipa-users at redhat.com
>     <mailto:freeipa-users at redhat.com>
>     *Subject:* Re: [Freeipa-users] Has one successfully synched the
>     entirety of their AD to IPA (multiple OUs and or Subtrees)
>
>     On 03/17/2014 03:33 PM, Todd Maugh wrote:
>
>         I'm trying to sync all of my AD to IPA, I don't need to retain
>         any of the original windows directory structure once in IPA.
>
>         I cannot find where to set ipaWinSyncUserFlatten to true (so
>         I'm assuming it's on true by default)
>
>
>     Yes, it is true by default.
>     dn: cn=ipa-winsync,cn=plugins,cn=config
>
>
>
>         I really need to be able to sync more than just the cn=users
>         subtree
>
>
>     There really isn't explicit support for this.  If it doesn't work
>     to set your AD subtree to your root suffix (e.g.
>     dc=domain,dc=com), then it's simply not going to work until 389
>     adds support for that.
>
>
>
>         And I can find no documentation or help on line.
>
>
>     Because there probably isn't any.
>
>
>
>         Has anyone had any success or practice with this?
>
>
>     See above.
>
>
>         Thanks
>
>         -Todd
>
>         Todd Maugh
>
>         Sr System Engineer
>
>         *Boingo Wireless*
>
>         *tmaugh at boingo.com <mailto:tmaugh at boingo.com>*
>
>
>
>
>
>         _______________________________________________
>
>         Freeipa-users mailing list
>
>         Freeipa-users at redhat.com  <mailto:Freeipa-users at redhat.com>
>
>         https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140317/51a1f97c/attachment.htm>

From rmeggins at redhat.com  Mon Mar 17 22:16:39 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Mon, 17 Mar 2014 16:16:39 -0600
Subject: [Freeipa-users] Has one successfully synched the entirety of
 their AD to IPA (multiple OUs and or Subtrees)
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229A311@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229A2A1@EXCHMB1-ELS.BWINC.local>
	<53276C9B.7000909@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229A2CB@EXCHMB1-ELS.BWINC.local>
	<53277125.6020409@redhat.com>
	<6FB698E172A95F49BE009B36D56F53E229A311@EXCHMB1-ELS.BWINC.local>
Message-ID: <53277447.1020208@redhat.com>

On 03/17/2014 04:04 PM, Todd Maugh wrote:
>
> Thanks again Rich is there some good Documentation on setting up the 
> trust?
>

I'm not familiar with trust.  There are other folks in the IPA community 
who are.

> *From:*Rich Megginson [mailto:rmeggins at redhat.com]
> *Sent:* Monday, March 17, 2014 3:03 PM
> *To:* Todd Maugh; freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] Has one successfully synched the 
> entirety of their AD to IPA (multiple OUs and or Subtrees)
>
> On 03/17/2014 03:52 PM, Todd Maugh wrote:
>
>     Thanks Rich,
>
>     I am able to create a successful winsync agreement from the top
>     level.
>
>     Unfortunately, when I do this. I do not see any of the accounts
>     from the sub trees populate my ipa server.
>
>
> Ok, so it doesn't work.
>
>
>     Is it possible to have all the subtrees (ous) live under
>     cn=users.If I make this change to AD would IPA then sync all the
>     accounts from the subtrees?
>
>
> Yes.
>
>
>     I cant believe I am the first person with this issue or need.
>
>
> You are certainly not - we have a couple of 389 to address this and 
> similar issues with winsync.
>
> https://fedorahosted.org/389/ticket/460
>
> Unfortunately, this fix has been targeted for F20 (389-ds-base-1.3.2), 
> and we don't have plans to backport to EL6.
>
> Note that winsync is always going to be more or less painful - it is 
> not, was never designed to be, and never will be a full blown 
> meta-directory solution.  For more information:
>
> https://fedorahosted.org/389/query?component=Sync+Service&status=accepted&status=assigned&status=new&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority&report=16
>
> That's why we recommend that the best long term solution is cross 
> domain trust - that removes winsync from the picture.
>
>
>     Thanks again in advance.
>
>     *From:*Rich Megginson [mailto:rmeggins at redhat.com]
>     *Sent:* Monday, March 17, 2014 2:44 PM
>     *To:* Todd Maugh; freeipa-users at redhat.com
>     <mailto:freeipa-users at redhat.com>
>     *Subject:* Re: [Freeipa-users] Has one successfully synched the
>     entirety of their AD to IPA (multiple OUs and or Subtrees)
>
>     On 03/17/2014 03:33 PM, Todd Maugh wrote:
>
>         I'm trying to sync all of my AD to IPA, I don't need to retain
>         any of the original windows directory structure once in IPA.
>
>         I cannot find where to set ipaWinSyncUserFlatten to true (so
>         I'm assuming it's on true by default)
>
>
>     Yes, it is true by default.
>     dn: cn=ipa-winsync,cn=plugins,cn=config
>
>
>
>         I really need to be able to sync more than just the cn=users
>         subtree
>
>
>     There really isn't explicit support for this.  If it doesn't work
>     to set your AD subtree to your root suffix (e.g.
>     dc=domain,dc=com), then it's simply not going to work until 389
>     adds support for that.
>
>
>
>         And I can find no documentation or help on line.
>
>
>     Because there probably isn't any.
>
>
>
>         Has anyone had any success or practice with this?
>
>
>     See above.
>
>
>         Thanks
>
>         -Todd
>
>         Todd Maugh
>
>         Sr System Engineer
>
>         *Boingo Wireless*
>
>         *tmaugh at boingo.com <mailto:tmaugh at boingo.com>*
>
>
>
>
>
>         _______________________________________________
>
>         Freeipa-users mailing list
>
>         Freeipa-users at redhat.com  <mailto:Freeipa-users at redhat.com>
>
>         https://www.redhat.com/mailman/listinfo/freeipa-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140317/c9c93242/attachment.htm>

From freeipa-users at dstipp.mail.coolhack.net  Tue Mar 18 14:26:35 2014
From: freeipa-users at dstipp.mail.coolhack.net (David)
Date: Tue, 18 Mar 2014 10:26:35 -0400
Subject: [Freeipa-users] IPA DNS response issue
Message-ID: <20140318142635.GH23332@coolhack.net>


Hi all - 

We have an installation of FreeIPA (through CentOS 6.5) that's exhibiting some
odd behavior with respect to serving DNS.  Periodically (interval at random)
named running on a replica will stop serving requests from the LDAP server but
continue to respond with recursive requests.  This type of failure causes us
problems, as you could imagine.  (It doesn't fail cleanly so it won't request
from another server.)  We've adjusted the amount of connections each named
makes to 389, but it doesn't seem to make a difference.  We're not seeing
anything in the logs so troubleshooting this is becoming a bit of a
(high-visibility) puzzle to us.

I do happen to have a core file that I grabbed last night before sending a
SIGKILL to named and restarting.  (A SIGTERM has no effect.)

Hopefully there's an easy answer here that we can get rolled into the
environment quickly.  FreeIPA has treated us extraordinarily well so far!

David



About our configuration:

OS: CentOS 6.5, x86_64

Packages:
bind-9.8.2-0.23.rc1.el6_5.1.x86_64
bind-dyndb-ldap-2.3-5.el6.x86_64
ipa-server-3.0.0-37.el6.x86_64


Configuration:

bind-dyndb-ldap is used in conjunction with IPA 3.0.0-37.

The version of bind is 9.8.2-0.23.rc1

Our dynamic-db section of named.conf is as follows:

----
dynamic-db "ipa" {
           library "ldap.so";
           arg "uri ldapi://%2fvar%2frun%2fslapd-XXX-XXX.socket";
           arg "connections 10";
           arg "base cn=dns, dc=XXX,dc=XXX";
           arg "fake_mname XXX.ipa.hosted.zone.";
           arg "auth_method sasl";
           arg "sasl_mech GSSAPI";
           arg "sasl_user DNS/XXX.ipa.hosted.zone";
           arg "zone_refresh 0";
           arg "psearch yes";
           arg "serial_autoincrement yes";
           arg "verbose_checks yes";
};
----

We do not have any text based or DLZ zones configured.

We do not have any global forwarders configured.

We do not have any settings in the global configuration object in LDAP.

----
$ ldapsearch -Y GSSAPI -b 'cn=dns,dc=XXX,dc=XXX' '(objectClass=idnsConfigObject)'
SASL/GSSAPI authentication started

...

# dns, XXX.XXX
dn: cn=dns,dc=XXX,dc=XXX
objectClass: idnsConfigObject
objectClass: nsContainer
objectClass: top
cn: dns

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1
----



From robert.roche at xerox.com  Tue Mar 18 14:19:56 2014
From: robert.roche at xerox.com (Rob)
Date: Tue, 18 Mar 2014 14:19:56 +0000 (UTC)
Subject: [Freeipa-users] AIX kerberos client to IPA
References: <loom.20140312T224425-846@post.gmane.org>
	<53242289.9090703@nixtra.com>
Message-ID: <loom.20140318T151719-804@post.gmane.org>

Sigbjorn Lie <sigbjorn at ...> writes:

> 
> 
>     On 12/03/14 22:52, Rob wrote:
> 
>     
>       
> Hi,
> 
> I have configured an AIX 6.1 server to connect to a RHEL 6.5 IPA server. 
The 
> AIX server is configured to use netgroups and all that works for existing 
the 
> users.
> 
> The problem is when a users password expires or when a new user is 
created. 
> They cannot change their password
> 
> WARNING: Your password has expired.
> You must change your password now and login again!
> Changing password for "testuser"
> testuser's Old password:
> testuser's New password:
> Connection to localhost closed.
> 
> The problem seems to be related to not getting a kerberos ticket as kinit 
can 
> be used to change the password.
> 
> Logging is enabled but no logs ever get updated
> 
> [logging]
>         kdc = FILE:/var/krb5/log/krb5kdc.log
>         admin_server = FILE:/var/krb5/log/kadmin.log
>         kadmin_local = FILE:/var/krb5/log/kadmin_local.log
>         default = FILE:/var/krb5/log/krb5lib.log
> 
> Anybody ever come across this? Or know how to get logging working?
> 
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
> 
>     
>     
> 
> I am not familiar with AIX. Just quick tip for what we had to do on 
Solaris to make password changes work - as the issue sounded somewhat 
familiar... :)
> 
> We have to set "kpasswd_protocol = SET_CHANGE" to krb5.conf when used with 
any "non-Solaris KDC". 
> 
> Perhaps you have a similar setting for AIX?
> 
> 
> 
> 
>   
> 
> <div>
>     <div class="moz-cite-prefix">On 12/03/14 22:52, Rob wrote:<br>
> </div>
>     <blockquote cite="mid:loom.20140312T224425-846 at ..." type="cite">
> 
> Hi,
> 
> I have configured an AIX 6.1 server to connect to a RHEL 6.5 IPA server. 
The 
> AIX server is configured to use netgroups and all that works for existing 
the 
> users.
> 
> The problem is when a users password expires or when a new user is 
created. 
> They cannot change their password
> 
> WARNING: Your password has expired.
> You must change your password now and login again!
> Changing password for "testuser"
> testuser's Old password:
> testuser's New password:
> Connection to localhost closed.
> 
> The problem seems to be related to not getting a kerberos ticket as kinit 
can 
> be used to change the password.
> 
> Logging is enabled but no logs ever get updated
> 
> [logging]
>         kdc = <a class="moz-txt-link-freetext" 
href="FILE:/var/krb5/log/krb5kdc.log">FILE:/var/krb5/log/krb5kdc.log</a>
>         admin_server = <a class="moz-txt-link-freetext" 
href="FILE:/var/krb5/log/kadmin.log">FILE:/var/krb5/log/kadmin.log</a>
>         kadmin_local = <a class="moz-txt-link-freetext" 
href="FILE:/var/krb5/log/kadmin_local.log">FILE:/var/krb5/log/kadmin_local.l
og</a>
>         default = <a class="moz-txt-link-freetext" 
href="FILE:/var/krb5/log/krb5lib.log">FILE:/var/krb5/log/krb5lib.log</a>
> 
> Anybody ever come across this? Or know how to get logging working?
> 
> _______________________________________________
> Freeipa-users mailing list
> <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-
users at ...">Freeipa-users at ...</a>
> <a class="moz-txt-link-freetext" 
href="https://www.redhat.com/mailman/listinfo/freeipa-
users">https://www.redhat.com/mailman/listinfo/freeipa-users</a>
> 
>     </blockquote>
> 
> I am not familiar with AIX. Just quick tip for what we had to do on 
Solaris to make password changes work - as the issue sounded somewhat 
familiar... :)
> 
> We have to set "kpasswd_protocol = SET_CHANGE" to krb5.conf when used with 
any "non-Solaris KDC". 
> 
> Perhaps you have a similar setting for AIX?
> 
>   </div>
> 

Thanks, I tried that option but it didn't seem to make any difference. I've 
a tech call open with IBM and redhat so I'm hoping between us we can figure 
out what the problem is.
I'll post here with any solution that I might get.






From ac at appx.it  Tue Mar 18 15:30:21 2014
From: ac at appx.it (Alfredo Colangelo)
Date: Tue, 18 Mar 2014 16:30:21 +0100
Subject: [Freeipa-users] slow response when adding users to heavily
	populated groups
Message-ID: <etPan.5328668d.74b0dc51.39c1@Mav.local>

Hi guys,
I have a problem when adding users to groups containing many members, I do this with the command:

/usr/bin/ipa group-add-member group --users=user

In this case I have a very slow response - it could take 1 minute or more to complete the command - and it slows down as more members are added to the group.
I guess it'a a problem with ldap indexes, but how to speed it up?

Thanks in advance
-- Al




From genadipost at gmail.com  Tue Mar 18 22:14:39 2014
From: genadipost at gmail.com (Genadi Postrilko)
Date: Wed, 19 Mar 2014 00:14:39 +0200
Subject: [Freeipa-users] Understanding role of the certificate in client -
	server communication.
Message-ID: <CAPP+0vLBMLAe05sfN7V=Z-NJ1iDkZFYX7wQQvoiZXnuzaUgTEg@mail.gmail.com>

Hello all.
I'm trying to understand the use of the certificates in the communication
between an IPA client and server.
The documentation describes the retrieval of CA certificate while client
setup:
"Retrieve the CA certificate for the IdM CA"

And retrieval of SSL server certificate:
"Enable certmonger, retrieve an SSL server certificate, and install the
certificate in /etc/pki/nssdb"

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/setting-up-clients.html#what-happens-clients

>From my understanding the authentication in IPA environment is kerberos
based, therefore the client and server share a "secret" that allows the
user to authenticate himself to the server and vice versa.
Where comes the need for certificate? Some of the IPA server services are
not kerberized?

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140319/5dc14be8/attachment.htm>

From rcritten at redhat.com  Tue Mar 18 22:24:26 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Tue, 18 Mar 2014 18:24:26 -0400
Subject: [Freeipa-users] Understanding role of the certificate in client
 - server communication.
In-Reply-To: <CAPP+0vLBMLAe05sfN7V=Z-NJ1iDkZFYX7wQQvoiZXnuzaUgTEg@mail.gmail.com>
References: <CAPP+0vLBMLAe05sfN7V=Z-NJ1iDkZFYX7wQQvoiZXnuzaUgTEg@mail.gmail.com>
Message-ID: <5328C79A.6070004@redhat.com>

Genadi Postrilko wrote:
> Hello all.
> I'm trying to understand the use of the certificates in the
> communication between an IPA client and server.
> The documentation describes the retrieval of CA certificate while client
> setup:
> "Retrieve the CA certificate for the IdM CA"
>
> And retrieval of SSL server certificate:
> "Enable certmonger, retrieve an SSL server certificate, and install the
> certificate in |/etc/pki/nssdb"|
>
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/setting-up-clients.html#what-happens-clients
>
>  From my understanding the authentication in IPA environment is kerberos
> based, therefore the client and server share a "secret" that allows the
> user to authenticate himself to the server and vice versa.
> Where comes the need for certificate? Some of the IPA server services
> are not kerberized?

Kerberos over HTTP requires SSL which is why the CA is retrieved and 
installed.

We don't currently use the machine certificate. This was for 
future-proofing.

rob



From genadipost at gmail.com  Wed Mar 19 08:35:16 2014
From: genadipost at gmail.com (Genadi Postrilko)
Date: Wed, 19 Mar 2014 10:35:16 +0200
Subject: [Freeipa-users] Understanding role of the certificate in client
 - server communication.
In-Reply-To: <5328C79A.6070004@redhat.com>
References: <CAPP+0vLBMLAe05sfN7V=Z-NJ1iDkZFYX7wQQvoiZXnuzaUgTEg@mail.gmail.com>
	<5328C79A.6070004@redhat.com>
Message-ID: <CAPP+0vLmvo8_q6ajBRGgWpVd0v3fb1M9E2uMjXAk8nu+RT-qag@mail.gmail.com>

Thank you for the answer.
Sory if i lack the knowledge, but why SSL is needed when using kerberos?
Kerberos is based on 3th party that is trusted, why there is a need for
public key encryption?
On Mar 19, 2014 12:24 AM, "Rob Crittenden" <rcritten at redhat.com> wrote:

> Genadi Postrilko wrote:
>
>> Hello all.
>> I'm trying to understand the use of the certificates in the
>> communication between an IPA client and server.
>> The documentation describes the retrieval of CA certificate while client
>> setup:
>> "Retrieve the CA certificate for the IdM CA"
>>
>> And retrieval of SSL server certificate:
>> "Enable certmonger, retrieve an SSL server certificate, and install the
>> certificate in |/etc/pki/nssdb"|
>>
>> https://access.redhat.com/site/documentation/en-US/Red_
>> Hat_Enterprise_Linux/6/html/Identity_Management_Guide/
>> setting-up-clients.html#what-happens-clients
>>
>>  From my understanding the authentication in IPA environment is kerberos
>> based, therefore the client and server share a "secret" that allows the
>> user to authenticate himself to the server and vice versa.
>> Where comes the need for certificate? Some of the IPA server services
>> are not kerberized?
>>
>
> Kerberos over HTTP requires SSL which is why the CA is retrieved and
> installed.
>
> We don't currently use the machine certificate. This was for
> future-proofing.
>
> rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140319/64a70faf/attachment.htm>

From abokovoy at redhat.com  Wed Mar 19 08:56:46 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Wed, 19 Mar 2014 10:56:46 +0200
Subject: [Freeipa-users] Understanding role of the certificate in client
 - server communication.
In-Reply-To: <CAPP+0vLmvo8_q6ajBRGgWpVd0v3fb1M9E2uMjXAk8nu+RT-qag@mail.gmail.com>
References: <CAPP+0vLBMLAe05sfN7V=Z-NJ1iDkZFYX7wQQvoiZXnuzaUgTEg@mail.gmail.com>
	<5328C79A.6070004@redhat.com>
	<CAPP+0vLmvo8_q6ajBRGgWpVd0v3fb1M9E2uMjXAk8nu+RT-qag@mail.gmail.com>
Message-ID: <20140319085646.GA18421@redhat.com>

On Wed, 19 Mar 2014, Genadi Postrilko wrote:
>Thank you for the answer.
>Sory if i lack the knowledge, but why SSL is needed when using kerberos?
>Kerberos is based on 3th party that is trusted, why there is a need for
>public key encryption?
Using Kerberos only, without asking for integrity and confidentiality
services,  without channel bindings to the outer encryption, is prone to
MITM even with valid TLS channels.

Use of certificates allows to perform mutual authentication at the SSL
level and later perform channel bindings of the tunnelled Kerberos
communication.

Note that Kerberos over HTTP is weak without transport level security.
HTTP authentication per se is independent of the transport.

For more details you can look at Joe Orton's talk at ApacheCon'2008:
http://www.apachecon.com/eu2008/program/materials/kerb-sso-http.pdf
-- 
/ Alexander Bokovoy



From fvzwieten at vxcompany.com  Wed Mar 19 09:38:51 2014
From: fvzwieten at vxcompany.com (Fred van Zwieten)
Date: Wed, 19 Mar 2014 10:38:51 +0100
Subject: [Freeipa-users] passwordless login into IPA clients possible from
	non IPA client?
Message-ID: <CALVifsZsOORfZKouxYjU3kRm81Qj2Ja8o7LmxUh7yWBTZqA4DA@mail.gmail.com>

Hi,

Subject says it all actually. I have a laptop with Fedora20. I work as a
contractor on different assignments. Some of them have an IPA domain set
up. Their RHEL6 servers are all IPA clients. I would like to ssh into these
servers passwordless using ssh-agent and such. Is this possible? If so, how
would I set this up?

BTW passwordless login already works when ssh-ing from an IPA client into
another IPA client.

Fred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140319/56290a6d/attachment.htm>

From andrew.holway at gmail.com  Wed Mar 19 12:20:35 2014
From: andrew.holway at gmail.com (Andrew Holway)
Date: Wed, 19 Mar 2014 12:20:35 +0000
Subject: [Freeipa-users] passwordless login into IPA clients possible
 from non IPA client?
In-Reply-To: <CALVifsZsOORfZKouxYjU3kRm81Qj2Ja8o7LmxUh7yWBTZqA4DA@mail.gmail.com>
References: <CALVifsZsOORfZKouxYjU3kRm81Qj2Ja8o7LmxUh7yWBTZqA4DA@mail.gmail.com>
Message-ID: <CAEiui-t=nXmoqMJPPvfzsSx4Q3rNRjvNr4gYMv--v3udOah6JA@mail.gmail.com>

Hi Fred,

You can add your public keys to the users profile via the GUI of CLI.
Take contents of the .ssh/id_rsa.pub from your Fedora20 Laptop and
insert it in the GUI.

User -> ACCOUNT SETTINGS -> SSH public keys -> add

http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/user-keys.html

Thanks,

Andrew

On 19 March 2014 09:38, Fred van Zwieten <fvzwieten at vxcompany.com> wrote:
> Hi,
>
> Subject says it all actually. I have a laptop with Fedora20. I work as a
> contractor on different assignments. Some of them have an IPA domain set up.
> Their RHEL6 servers are all IPA clients. I would like to ssh into these
> servers passwordless using ssh-agent and such. Is this possible? If so, how
> would I set this up?
>
> BTW passwordless login already works when ssh-ing from an IPA client into
> another IPA client.
>
> Fred
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users



From simo at redhat.com  Wed Mar 19 12:50:44 2014
From: simo at redhat.com (Simo Sorce)
Date: Wed, 19 Mar 2014 08:50:44 -0400
Subject: [Freeipa-users] Understanding role of the certificate in client
 - server communication.
In-Reply-To: <20140319085646.GA18421@redhat.com>
References: <CAPP+0vLBMLAe05sfN7V=Z-NJ1iDkZFYX7wQQvoiZXnuzaUgTEg@mail.gmail.com>
	<5328C79A.6070004@redhat.com>
	<CAPP+0vLmvo8_q6ajBRGgWpVd0v3fb1M9E2uMjXAk8nu+RT-qag@mail.gmail.com>
	<20140319085646.GA18421@redhat.com>
Message-ID: <1395233444.26633.6.camel@willson.li.ssimo.org>

On Wed, 2014-03-19 at 10:56 +0200, Alexander Bokovoy wrote:
> On Wed, 19 Mar 2014, Genadi Postrilko wrote:
> >Thank you for the answer.
> >Sory if i lack the knowledge, but why SSL is needed when using kerberos?
> >Kerberos is based on 3th party that is trusted, why there is a need for
> >public key encryption?
> Using Kerberos only, without asking for integrity and confidentiality
> services,  without channel bindings to the outer encryption, is prone to
> MITM even with valid TLS channels.
> 
> Use of certificates allows to perform mutual authentication at the SSL
> level and later perform channel bindings of the tunnelled Kerberos
> communication.
> 
> Note that Kerberos over HTTP is weak without transport level security.
> HTTP authentication per se is independent of the transport.
> 
> For more details you can look at Joe Orton's talk at ApacheCon'2008:
> http://www.apachecon.com/eu2008/program/materials/kerb-sso-http.pdf

Note also that Negotiate does not actually use channel binding to the
outer TLS channel in all implementation I know of :/

Simo.

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



From pspacek at redhat.com  Wed Mar 19 12:57:24 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Wed, 19 Mar 2014 13:57:24 +0100
Subject: [Freeipa-users] IPA DNS response issue
In-Reply-To: <20140318142635.GH23332@coolhack.net>
References: <20140318142635.GH23332@coolhack.net>
Message-ID: <53299434.9010409@redhat.com>

On 18.3.2014 15:26, David wrote:
>
> Hi all -
> We have an installation of FreeIPA (through CentOS 6.5) that's exhibiting some
> odd behavior with respect to serving DNS.  Periodically (interval at random)
> named running on a replica will stop serving requests from the LDAP server but
> continue to respond with recursive requests.  This type of failure causes us
> problems, as you could imagine.  (It doesn't fail cleanly so it won't request
> from another server.)  We've adjusted the amount of connections each named
> makes to 389, but it doesn't seem to make a difference.  We're not seeing
> anything in the logs so troubleshooting this is becoming a bit of a
> (high-visibility) puzzle to us.
>
> I do happen to have a core file that I grabbed last night before sending a
> SIGKILL to named and restarting.  (A SIGTERM has no effect.)
>
> Hopefully there's an easy answer here that we can get rolled into the
> environment quickly.  FreeIPA has treated us extraordinarily well so far!
>
> David
>
>
>
> About our configuration:
>
> OS: CentOS 6.5, x86_64
>
> Packages:
> bind-9.8.2-0.23.rc1.el6_5.1.x86_64
> bind-dyndb-ldap-2.3-5.el6.x86_64
> ipa-server-3.0.0-37.el6.x86_64
>
>
> Configuration:
>
> bind-dyndb-ldap is used in conjunction with IPA 3.0.0-37.
>
> The version of bind is 9.8.2-0.23.rc1
>
> Our dynamic-db section of named.conf is as follows:
>
> ----
> dynamic-db "ipa" {
>            library "ldap.so";
>            arg "uri ldapi://%2fvar%2frun%2fslapd-XXX-XXX.socket";
>            arg "connections 10";
>            arg "base cn=dns, dc=XXX,dc=XXX";
>            arg "fake_mname XXX.ipa.hosted.zone.";
>            arg "auth_method sasl";
>            arg "sasl_mech GSSAPI";
>            arg "sasl_user DNS/XXX.ipa.hosted.zone";
>            arg "zone_refresh 0";
>            arg "psearch yes";
>            arg "serial_autoincrement yes";
>            arg "verbose_checks yes";
> };
> ----
>
> We do not have any text based or DLZ zones configured.
>
> We do not have any global forwarders configured.
>
> We do not have any settings in the global configuration object in LDAP.
>
> ----
> $ ldapsearch -Y GSSAPI -b 'cn=dns,dc=XXX,dc=XXX' '(objectClass=idnsConfigObject)'
> SASL/GSSAPI authentication started
>
> ...
>
> # dns, XXX.XXX
> dn: cn=dns,dc=XXX,dc=XXX
> objectClass: idnsConfigObject
> objectClass: nsContainer
> objectClass: top
> cn: dns
>
> # search result
> search: 4
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
> ----

Note that David (I guess :-) added logs to the ticket
https://fedorahosted.org/bind-dyndb-ldap/ticket/131
and I'm looking into it.

-- 
Petr^2 Spacek



From freeipa-users at dstipp.mail.coolhack.net  Wed Mar 19 14:12:27 2014
From: freeipa-users at dstipp.mail.coolhack.net (David)
Date: Wed, 19 Mar 2014 10:12:27 -0400
Subject: [Freeipa-users] IPA DNS response issue
In-Reply-To: <53299434.9010409@redhat.com>
References: <20140318142635.GH23332@coolhack.net> <53299434.9010409@redhat.com>
Message-ID: <20140319141227.GI23332@coolhack.net>

On Wed, Mar 19, 2014 at 01:57:24PM +0100, Petr Spacek wrote:
>On 18.3.2014 15:26, David wrote:
>>We have an installation of FreeIPA (through CentOS 6.5) that's exhibiting some
>>odd behavior with respect to serving DNS.  Periodically (interval at random)
>>named running on a replica will stop serving requests from the LDAP server but
>>continue to respond with recursive requests.  This type of failure causes us
>>problems, as you could imagine.  (It doesn't fail cleanly so it won't request
>>from another server.)  We've adjusted the amount of connections each named
>>makes to 389, but it doesn't seem to make a difference.  We're not seeing
>>anything in the logs so troubleshooting this is becoming a bit of a
>>(high-visibility) puzzle to us.
>>
>>I do happen to have a core file that I grabbed last night before sending a
>>SIGKILL to named and restarting.  (A SIGTERM has no effect.)
>>
>>Hopefully there's an easy answer here that we can get rolled into the
>>environment quickly.  FreeIPA has treated us extraordinarily well so far!

<snip>

>Note that David (I guess :-) added logs to the ticket
>https://fedorahosted.org/bind-dyndb-ldap/ticket/131
>and I'm looking into it.

Actually, that's not me!  I don't have anywhere near as much logging...
At least I'm not alone...

Our failures also seem to happen around log rotation time.

The Kerberos ticket expiring is interesting.  I'll poke around on my
installation and see what I see on this side.

If you need any other information, please let me know.

David



From sakodak at gmail.com  Wed Mar 19 17:10:05 2014
From: sakodak at gmail.com (KodaK)
Date: Wed, 19 Mar 2014 12:10:05 -0500
Subject: [Freeipa-users] passwordless login into IPA clients possible
 from non IPA client?
In-Reply-To: <CAEiui-t=nXmoqMJPPvfzsSx4Q3rNRjvNr4gYMv--v3udOah6JA@mail.gmail.com>
References: <CALVifsZsOORfZKouxYjU3kRm81Qj2Ja8o7LmxUh7yWBTZqA4DA@mail.gmail.com>
	<CAEiui-t=nXmoqMJPPvfzsSx4Q3rNRjvNr4gYMv--v3udOah6JA@mail.gmail.com>
Message-ID: <CAA9J0ZHT-EBQ2v12Pp5uixTriJr41gMU72dBdhOCB9zwJm1pBw@mail.gmail.com>

Andrew's suggestion works fine, but you can also set up a simple krb5.conf
on the source hosts and then issue a kinit.  It doesn't have to be a "full"
IPA client for that to work.

You can also do this from a Windows box by using the MIT Kerberos for
Windows package:  http://web.mit.edu/Kerberos/dist/  (you can also do ssh
keys from windows with putty.)


On Wed, Mar 19, 2014 at 7:20 AM, Andrew Holway <andrew.holway at gmail.com>wrote:

> Hi Fred,
>
> You can add your public keys to the users profile via the GUI of CLI.
> Take contents of the .ssh/id_rsa.pub from your Fedora20 Laptop and
> insert it in the GUI.
>
> User -> ACCOUNT SETTINGS -> SSH public keys -> add
>
>
> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/user-keys.html
>
> Thanks,
>
> Andrew
>
> On 19 March 2014 09:38, Fred van Zwieten <fvzwieten at vxcompany.com> wrote:
> > Hi,
> >
> > Subject says it all actually. I have a laptop with Fedora20. I work as a
> > contractor on different assignments. Some of them have an IPA domain set
> up.
> > Their RHEL6 servers are all IPA clients. I would like to ssh into these
> > servers passwordless using ssh-agent and such. Is this possible? If so,
> how
> > would I set this up?
> >
> > BTW passwordless login already works when ssh-ing from an IPA client into
> > another IPA client.
> >
> > Fred
> >
> > _______________________________________________
> > Freeipa-users mailing list
> > Freeipa-users at redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>



-- 
The government is going to read our mail anyway, might as well make it
tough for them.  GPG Public key ID:  B6A1A7C6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140319/435a1b40/attachment.htm>

From shreerajkarulkar at yahoo.com  Wed Mar 19 21:37:54 2014
From: shreerajkarulkar at yahoo.com (Shree)
Date: Wed, 19 Mar 2014 14:37:54 -0700 (PDT)
Subject: [Freeipa-users] ipa-client-install fails on replica because
	of	kinit cannot contact any KDC
In-Reply-To: <1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com>
References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<52FBFBDA.8030104@redhat.com>	<1392247122.45221.YahooMailNeo@web160102.mail.bf1.yah!	!	oo.com>	<52FCD9AD.5000502@redhat.com>	<1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com>	<52F!	E5E83.70904@redhat.com>	<1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<52FE7119.1070601@redhat.com>	<1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<5303B22A.9070709@redhat.com>	<1!	392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com>	!	<53051B35.2050409@redhat.com>	<1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com!	>	<53051F62.40405@redhat.com>	<1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com!	>	<53052E64.3050903@redhat.com>	<1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c!	!
	om>
	<53061B18.40001@redhat.com>	<1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<53066CD0.5080501@redhat.!
	! com> <1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com>
Message-ID: <1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo.com>

Hello
I was able to successfully move all my clients to the replica except on the process I had to upgrade the client to "ipa-client-3.0.0-37.el6.x86_64" and some times run a --uninstall 

. Bit it works for the most part. Have been struggling with one last host with errors like below. I have tested the port connectivity using telnet and netcat commands but the install thinks these ports are blocked? 

?


kerberos authentication failed
kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting initial credentials

Please make sure the following ports are opened in the firewall settings:
???? TCP: 80, 88, 389
???? UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly after enrollment:
???? TCP: 464
???? UDP: 464, 123 (if NTP enabled)
Installation failed. Rolling back changes.
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted
Restoring client configuration files
Client uninstall complete.
[root at www /]#

In the /var/log/ipaclient-install.log I also see things like below. I get Autodiscovery failures but I am manually entering things and they have been working.

2014-03-19T21:13:47Z DEBUG Found: cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
2014-03-19T21:13:47Z DEBUG Discovery result: Success; server=ldap2.mydomain.com, domain=mydomain.com, kdc=ldap.mydomain.com, basedn=dc=mydomain,dc=com
2014-03-19T21:13:47Z DEBUG Validated servers: ldap2.mydomain.com
2014-03-19T21:13:47Z WARNING The failure to use DNS to find your IPA server indicates that your resolv.conf file is not properly configured.
2014-03-19T21:13:47Z INFO Autodiscovery of servers for failover cannot work with this configuration.
2014-03-19T21:13:47Z INFO If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure.




Shreeraj 
---------------------------------------------------------------------------------------- 

Change is the only Constant !



On Thursday, February 20, 2014 9:01 PM, Shree <shreerajkarulkar at yahoo.com> wrote:
 
Dmitri, Rob, Lucas et al. Thank you for all your help and patience and pointing me to the right direction. I was able to fix? most of my issues. My setup is a little complex where I am trying to have a master and the replica in different networks and are in sync + each of them is serving a different set of hosts.


?
Shreeraj 
---------------------------------------------------------------------------------------- 

Change is the only Constant !



On Thursday, February 20, 2014 2:20 PM, Dmitri Pal <dpal at redhat.com> wrote:
 
On 02/20/2014 02:58 PM, Shree wrote: 
Can you help me figure out, below is some info on the existing working configuration one one of the clients
>1)Sudo version 1.7.4p5
>
>2)[root at test500 ~]# sssd --version
>1.9.2
>
>3)These are the uncommented lines in /etc/sssd/sssd.conf
>[sssd]
>config_file_version = 2
>services = nss, pam
>domains = mydomain.com
>[domain/mydomain.com]
>cache_credentials = True
>krb5_store_password_if_offline = True
>ipa_domain = mydomain.com
>id_provider = ipa
>auth_provider = ipa
>access_provider = ipa
>ipa_hostname = dns.mydomain.com
>chpass_provider = ipa
>ipa_server = ldap.mydomain.com
>ldap_netgroup_search_base = cn=ng,cn=compat,dc=mydomain,dc=com
>ldap_tls_cacert = /etc/ipa/ca.crt
>
>=======================================
>4)And these are the options in /etc/nsswitch.conf
>sudoers:??? files ldap
>passwd:???? files sss
>shadow:???? files sss
>group:????? files sss
>
>
>Shreeraj 
>---------------------------------------------------------------------------------------- 
>
>Change is the only Constant !
>
>
>
>On Thursday, February 20, 2014 7:20 AM, Dmitri Pal <dpal at redhat.com> wrote:
> 
>On 02/19/2014 06:52 PM, Shree wrote: 
>Rob
>>You were right. After upgrading the
                                client to the
                                ipa-client-3.0.0-37.el6.x86_64 version I
                                started seeing a warning during the
                                client install that went something like 
>>=================
>>Autodiscovery of servers for failover
                                cannot work with this configuration.
>>If you proceed with the installation,
                                services will be configured to always
                                access the discovered server for all
                                operations and will not fail over to
                                other servers in case of failure.
>>Proceed with fixed values and no DNS
                                discovery? [no]: yes
>>=================
>>
>>I continued by saying yes because in my case the master and the replica are in different VLANs and failover is not possible for me. I have tried in two hosts successfully and am hoping that does the trick.
>>
>>
>>However I see one issue immediately that my sudo access does not seem to work now on the newly added clients! Do you know what might be happening?
>>
>>?
Are you using SSSD and SUDO integration?
>What version of sudo and sssd?
>See if this would help: http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf 
>
>
>
>Shreeraj 
>>---------------------------------------------------------------------------------------- 
>>
>>Change is the only Constant !
>>
>>
>>
>>On Wednesday, February 19, 2014 2:21 PM, Rob Crittenden <rcritten at redhat.com> wrote:
>> 
>>Shree wrote:
>>> root at test500 ~]# rpm -q ipa-client
>>>
                                          ipa-client-2.2.0-16.el6.x86_64
>>> [root at test500 ~]#
>>
>>You'll definitely want to
                                          update to 2.2.0-17, that fixes
                                          CVE-2012-5484
>>
>>Unfortunately our logging
                                          around discovery was rather
                                          horrible in 2.2.x 
>>so it is difficult to know
                                          exactly what is going on.
>>
>>I believe the problem is that
                                          it is still doing DNS
                                          discovery even 
>>though you've passed in a
                                          server name so it is setting
                                          up Kerberos to 
>>look up the KDC which it finds
                                          but can't talk to.
>>
>>This should be fixed in the
                                          3.0 packages so updating to
                                          those is the 
>>preferred solution.
>>
>>For 2.x you can try the
                                          --force option which should
                                          make it skip some 
>>discovery.
>>
>>rob
>>
>>>
>>>
>>> Shreeraj
>>>
----------------------------------------------------------------------------------------
>>>
>>>
>>> Change is the only
                                          Constant !
>>>
>>>
>>> On Wednesday, February
                                          19, 2014 1:17 PM, Rob
                                          Crittenden
>>> <rcritten at redhat.com> wrote:
>>> Shree wrote:
>>>? > Here are a couple
                                          of things
>>>? >
>>>? > [skarulkar at ldap2 <mailto:skarulkar at ldap2> ~]$ rpm -q ipa-client
>>>? >
                                          ipa-client-3.0.0-26.el6_4.4.x86_64
>>>
>>> What is the version on
                                          the client that is failing to
                                          enroll?
>>>
>>> rob
>>>
>>>? >
>>>? > and my
                                          /etc/krb5.conf looks like
                                          ..........
>>>? >
                                          =======================================
>>>? > includedir
                                          /var/lib/sss/pubconf/krb5.include.d/
>>>? >
>>>? > [logging]
>>>? >? default = FILE:/var/log/krb5libs.log
>>>? >? kdc = FILE:/var/log/krb5kdc.log
>>>? >? admin_server = FILE:/var/log/kadmind.log
>>>? >
>>>? > [libdefaults]
>>>? >? default_realm =
                                          MYDOMAIN.COM
>>>? >? dns_lookup_realm =
                                          false
>>>? >? dns_lookup_kdc =
                                          true
>>>? >? rdns = false
>>>? >? ticket_lifetime =
                                          24h
>>>? >? forwardable = yes
>>>? >
>>>? > [realms]
>>>? >? MYDOMAIN.COM = {
>>>? >? ? kdc =
                                          ldap2.mydomain.com:88
>>>? >? ? master_kdc =
                                          ldap2.mydomain.com:88
>>>? >? ? admin_server =
                                          ldap2.mydomain.com:749
>>>? >? ? default_domain =
                                          mydomain.com
>>>? >? ? pkinit_anchors = FILE:/etc/ipa/ca.crt
>>>? > default_domain =
                                          mydomain.com
>>>? >? ? pkinit_anchors = FILE:/etc/ipa/ca.crt
>>>? > }
>>>? >
>>>? > [domain_realm]
>>>? >? .mydomain.com =
                                          MYDOMAIN.COM
>>>? >? mydomain.com =
                                          MYDOMAIN.COM
>>>? >
>>>? > [dbmodules]
>>>? >? ? MYDOMAIN.COM = {
>>>? >? ? ? db_library =
                                          ipadb.so
>>>? >? ? }
>>>? >
>>>? >
                                          =======================================
>>>? >
>>>? >
>>>? > Shreeraj
>>>? >
>>>
----------------------------------------------------------------------------------------
>>>? >
>>>? >
>>>? > Change is the only
                                          Constant !
>>>? >
>>>? >
>>>? > On Wednesday,
                                          February 19, 2014 12:59 PM,
                                          Rob Crittenden
>>>? > <rcritten at redhat.com <mailto:rcritten at redhat.com>> wrote:
>>>? > Shree wrote:
>>>? >? > 1) I have got
                                          a step furthur. My replica is
                                          not running CA Service. To
>>>? >? > achieve this
                                          I had to remove the existing
                                          cert with this command
>>>? >? >
>>>? >? > pkiremove
                                          -pki_instance_root=/var/lib
                                          -pki_instance_name=pki-ca
                                          -force
>>>? >? >
>>>? >? > Now the
                                          replica looks like this
>>>? >? >
>>>? >? > skarulkar at ldap2 <mailto:skarulkar at ldap2> <mailto:skarulkar at ldap2
>>> <mailto:skarulkar at ldap2>> tmp]$ sudo ipactl status
>>>? >? > [sudo]
                                          password for skarulkar:
>>>? >? > Directory
                                          Service: RUNNING
>>>? >? > KDC Service:
                                          RUNNING
>>>? >? > KPASSWD
                                          Service: RUNNING
>>>? >? > MEMCACHE
                                          Service: RUNNING
>>>? >? > HTTP Service:
                                          RUNNING
>>>? >? > CA Service:
                                          RUNNING
>>>? >? > [skarulkar at ldap2 <mailto:skarulkar at ldap2> <mailto:skarulkar at ldap2 
>>
>>> <mailto:skarulkar at ldap2>> tmp]$
>>>
>>>? >
>>>? > The tracking
                                            failed with:
>>>? >
>>>? >
                                            2014-02-18T20:20:43Z DEBUG
                                            stdout=Error initializing
                                            Kerberos library:
>>>? > Improper format
                                            of Kerberos configuration
                                            file.
>>>? >
>>>? > It looks like it
                                            failed on this for most if
                                            not all the tracking. What
>>>? > does
                                            /etc/krb5.conf look like?
>>>? >
>>>? >? >
>>>? >? > 2) I am
                                            still not able to add client
                                            using ipa-client-install
>>> using the
>>>? >? > replica.
>>>? >
>>>? > The temporary
                                            krb5.conf that is used
                                            during enrollment has
>>>? >
                                            dns_lookup_kdc=True so it is
                                            probably trying to contact
                                            the other KDC
>>>? > and failing.
>>>? >
>>>? > What is the
                                            output of:
>>>? >
>>>? > $ rpm -q
                                            ipa-client
>>>? >
>>>? >
>>>? > rob
>>>? >
>>>? >
>>>? >
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>_______________________________________________
Freeipa-users mailing list Freeipa-users at 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 at redhat.com
>https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
It seems like you do not use SSSD integration so turning the debug on sudo and seeing what it is doing is the next step.


-- 
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 at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140319/1971858e/attachment.htm>

From mkosek at redhat.com  Thu Mar 20 07:51:35 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Thu, 20 Mar 2014 08:51:35 +0100
Subject: [Freeipa-users] ipa-client-install fails on replica because of
 kinit cannot contact any KDC
In-Reply-To: <1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo.com>
References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com>	<52F!	E5E83.70904@redhat.com>	<1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<52FE7119.1070601@redhat.com>	<1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<5303B22A.9070709@redhat.com>	<1!	392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com>	!	<53051B35.2050409@redhat.com>	<1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com!	>	<53051F62.40405@redhat.com>	<1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com!	>	<53052E64.3050903@redhat.com>	<1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c!	!	om>	<53061B18.40001@redhat.com>	<1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<53066CD0.5080501@redhat.!	!
	com> <1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com>
	<1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo! .com>
Message-ID: <532A9E07.6040604@redhat.com>

On 03/19/2014 10:37 PM, Shree wrote:
> Hello
> I was able to successfully move all my clients to the replica except on the process I had to upgrade the client to "ipa-client-3.0.0-37.el6.x86_64" and some times run a --uninstall 
> 
> . Bit it works for the most part. Have been struggling with one last host with errors like below. I have tested the port connectivity using telnet and netcat commands but the install thinks these ports are blocked? 
> 
>  
> 
> 
> kerberos authentication failed
> kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting initial credentials
> 
> Please make sure the following ports are opened in the firewall settings:
>      TCP: 80, 88, 389
>      UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
> Also note that following ports are necessary for ipa-client working properly after enrollment:
>      TCP: 464
>      UDP: 464, 123 (if NTP enabled)
> Installation failed. Rolling back changes.
> Disabling client Kerberos and LDAP configurations
> Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted
> Restoring client configuration files
> Client uninstall complete.
> [root at www /]#
> 
> In the /var/log/ipaclient-install.log I also see things like below. I get Autodiscovery failures but I am manually entering things and they have been working.
> 
> 2014-03-19T21:13:47Z DEBUG Found: cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
> 2014-03-19T21:13:47Z DEBUG Discovery result: Success; server=ldap2.mydomain.com, domain=mydomain.com, kdc=ldap.mydomain.com, basedn=dc=mydomain,dc=com
> 2014-03-19T21:13:47Z DEBUG Validated servers: ldap2.mydomain.com
> 2014-03-19T21:13:47Z WARNING The failure to use DNS to find your IPA server indicates that your resolv.conf file is not properly configured.
> 2014-03-19T21:13:47Z INFO Autodiscovery of servers for failover cannot work with this configuration.
> 2014-03-19T21:13:47Z INFO If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure.

Ok. I would guess you have some DNS issue. But it is hard to tell without the
entire ipaclient-install.log of the failed installation.

Martin



From Shaun.Mcadams at wellpoint.com  Thu Mar 20 15:38:51 2014
From: Shaun.Mcadams at wellpoint.com (Mcadams, Shaun)
Date: Thu, 20 Mar 2014 15:38:51 +0000
Subject: [Freeipa-users] Export User fields from IPA
Message-ID: <6696EC4DD514434D824E62988F5DB1C00335070C@CO1PRD2802MB002.056d.mgd.msft.net>

Is there a function to export/create report of these fields from the IPA?  I'm not finding anything in the guide.  Thanks.

These are some of the fields we know will need in a list of all accounts:

Userlogin (userid/username)
Job Title
Firstname
Lastname
Fullname
Email Address
Telephone Number
Org. Unit
User Groups
Account Enabled/Disabled
Date Created
Password Expiration
Last pw change
Last login/authentication date/time
Lockout Status


Shaun McAdams
National Government Services
Health IT : CPI-Predictive Modeling
(o) - 317.595.4905 / x2004905
(c) - 317.430.9845



CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information or otherwise be protected by law. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140320/dfa433be/attachment.htm>

From barrykfl at gmail.com  Thu Mar 20 16:06:55 2014
From: barrykfl at gmail.com (barrykfl at gmail.com)
Date: Fri, 21 Mar 2014 00:06:55 +0800
Subject: [Freeipa-users] Export User fields from IPA
In-Reply-To: <6696EC4DD514434D824E62988F5DB1C00335070C@CO1PRD2802MB002.056d.mgd.msft.net>
References: <6696EC4DD514434D824E62988F5DB1C00335070C@CO1PRD2802MB002.056d.mgd.msft.net>
Message-ID: <CAELz9dtTUH8jfFZ6LeQbmex9r9i+N-bqsJX2H3W1hS313ZFaAw@mail.gmail.com>

No export all func, ..but .it can export one account per time ..so i use a
while loop to do it with a txt file.


Is there a function to export/create report of these fields from the IPA?
I'm not finding anything in the guide.  Thanks.



These are some of the fields we know will need in a list of all accounts:



Userlogin (userid/username)

Job Title

Firstname

Lastname

Fullname

Email Address

Telephone Number

Org. Unit

User Groups

Account Enabled/Disabled

Date Created

Password Expiration

Last pw change

Last login/authentication date/time


2014-03-20 23:38 GMT+08:00 Mcadams, Shaun <Shaun.Mcadams at wellpoint.com>:

>  Is there a function to export/create report of these fields from the
> IPA?  I'm not finding anything in the guide.  Thanks.
>
>
>
> These are some of the fields we know will need in a list of all accounts:
>
>
>
> Userlogin (userid/username)
>
> Job Title
>
> Firstname
>
> Lastname
>
> Fullname
>
> Email Address
>
> Telephone Number
>
> Org. Unit
>
> User Groups
>
> Account Enabled/Disabled
>
> Date Created
>
> Password Expiration
>
> Last pw change
>
> Last login/authentication date/time
>
> Lockout Status
>
>
>
>
>
> Shaun McAdams
>
> National Government Services
>
> Health IT : CPI-Predictive Modeling
>
> (o) - 317.595.4905 <317.595.4905%20>/ x2004905
>
> (c) - 317.430.9845
>
>
>
>  *CONFIDENTIALITY NOTICE:* This e-mail message, including any
> attachments, is
> for the sole use of the intended recipient(s) and may contain confidential
> and privileged information or otherwise be protected by law. Any
> unauthorized review, use, disclosure or distribution is prohibited. If you
> are not the intended recipient, please contact the sender by reply e-mail
> and destroy all copies of the original message.
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140321/9b1839e2/attachment.htm>

From rmeggins at redhat.com  Thu Mar 20 17:05:07 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 20 Mar 2014 11:05:07 -0600
Subject: [Freeipa-users] Does ipa dns enforce RRSet TTLs?
Message-ID: <532B1FC3.9050106@redhat.com>

http://tools.ietf.org/html/rfc2181#section-5

Specifically, this:
"Consequently the use of differing TTLs in an RRSet is hereby 
deprecated, the
TTLs of all RRs in an RRSet must be the same."

The answer is:

IPA is even more strict, one DNS *name* can have only one TTL for all 
RRsets.

This limitation is enforced by LDAP structure we use. All DNS records 
for single DNS name are stored in one LDAP object and DNS TTL is 
represented as one attribute.

The follow up question is:

But dnsrecord_add/mod has a dnsttl attribute.  What happens if I do a 
dnsrecord_mod {"dnsttl": adifferentvalue}?  Does it change the ttl for 
_all_ records?



From pspacek at redhat.com  Thu Mar 20 17:19:08 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Thu, 20 Mar 2014 18:19:08 +0100
Subject: [Freeipa-users] Does ipa dns enforce RRSet TTLs?
In-Reply-To: <532B1FC3.9050106@redhat.com>
References: <532B1FC3.9050106@redhat.com>
Message-ID: <532B230C.2050706@redhat.com>

On 20.3.2014 18:05, Rich Megginson wrote:
> http://tools.ietf.org/html/rfc2181#section-5
>
> Specifically, this:
> "Consequently the use of differing TTLs in an RRSet is hereby deprecated, the
> TTLs of all RRs in an RRSet must be the same."
>
> The answer is:
>
> IPA is even more strict, one DNS *name* can have only one TTL for all RRsets.
>
> This limitation is enforced by LDAP structure we use. All DNS records for
> single DNS name are stored in one LDAP object and DNS TTL is represented as
> one attribute.
>
> The follow up question is:
>
> But dnsrecord_add/mod has a dnsttl attribute.  What happens if I do a
> dnsrecord_mod {"dnsttl": adifferentvalue}?  Does it change the ttl for _all_
> records?

Yes it does, it should always affect the whole DNS name.

IMHO the right behavior for "import scripts" is to compute min(TTL in IPA, TTL 
of the new record) and use this value when adding a record.

Default TTL is now 86400 seconds. There is a plan to implement per-zone 
default TTL.

Let me know if you have some problems because of this, we can try to find some 
solution.

-- 
Petr^2 Spacek



From rcritten at redhat.com  Thu Mar 20 21:37:46 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Thu, 20 Mar 2014 17:37:46 -0400
Subject: [Freeipa-users] Export User fields from IPA
In-Reply-To: <CAELz9dtTUH8jfFZ6LeQbmex9r9i+N-bqsJX2H3W1hS313ZFaAw@mail.gmail.com>
References: <6696EC4DD514434D824E62988F5DB1C00335070C@CO1PRD2802MB002.056d.mgd.msft.net>
	<CAELz9dtTUH8jfFZ6LeQbmex9r9i+N-bqsJX2H3W1hS313ZFaAw@mail.gmail.com>
Message-ID: <532B5FAA.4060107@redhat.com>

barrykfl at gmail.com wrote:
> No export all func, ..but .it can export one account per time ..so i use
> a while loop to do it with a txt file.
>
>
> Is there a function to export/create report of these fields from the
> IPA?  I?m not finding anything in the guide.  Thanks.____

It depends on how many users you have. We have search limits to prevent 
enumeration.

There are a few options:

$ ipa user-find

This will return an unsorted list of all users, up the search limit. The 
default limit on the command-line is 100. You can set that higher, up to 
the 2000 limit in 389-ds. That can be changed with an ldapmodify.

Or you can use ldapsearch to pull the users:

$ ldapsearch -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=com

This requires some knowledge of IPA to translate the LDAP attribute 
names into something more understandable, but certainly doable.

rob

>
> __ __
>
> These are some of the fields we know will need in a list of all
> accounts:____
>
> __ __
>
> Userlogin (userid/username)____
>
> Job Title____
>
> Firstname____
>
> Lastname____
>
> Fullname____
>
> Email Address____
>
> Telephone Number____
>
> Org. Unit____
>
> User Groups____
>
> Account Enabled/Disabled____
>
> Date Created____
>
> Password Expiration____
>
> Last pw change____
>
> Last login/authentication date/time____
>
>
>
> 2014-03-20 23:38 GMT+08:00 Mcadams, Shaun <Shaun.Mcadams at wellpoint.com
> <mailto:Shaun.Mcadams at wellpoint.com>>:
>
>     Is there a function to export/create report of these fields from the
>     IPA?  I?m not finding anything in the guide.  Thanks.____
>
>     __ __
>
>     These are some of the fields we know will need in a list of all
>     accounts:____
>
>     __ __
>
>     Userlogin (userid/username)____
>
>     Job Title____
>
>     Firstname____
>
>     Lastname____
>
>     Fullname____
>
>     Email Address____
>
>     Telephone Number____
>
>     Org. Unit____
>
>     User Groups____
>
>     Account Enabled/Disabled____
>
>     Date Created____
>
>     Password Expiration____
>
>     Last pw change____
>
>     Last login/authentication date/time____
>
>     Lockout Status____
>
>     __ __
>
>     __ __
>
>     Shaun McAdams____
>
>     National Government Services____
>
>     Health IT : CPI-Predictive Modeling ____
>
>     (o) ? 317.595.4905 <tel:317.595.4905%20>/ x2004905____
>
>     (c) ? 317.430.9845 <tel:317.430.9845>____
>
>     __ __
>
>
>     *CONFIDENTIALITY NOTICE:*This e-mail message, including any
>     attachments, is
>     for the sole use of the intended recipient(s) and may contain
>     confidential
>     and privileged information or otherwise be protected by law. Any
>     unauthorized review, use, disclosure or distribution is prohibited.
>     If you
>     are not the intended recipient, please contact the sender by reply
>     e-mail
>     and destroy all copies of the original message.____
>
>     _______________________________________________
>     Freeipa-users mailing list
>     Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
>     https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>



From tmaugh at boingo.com  Thu Mar 20 22:46:27 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 20 Mar 2014 22:46:27 +0000
Subject: [Freeipa-users] Client enrollment failing
Message-ID: <6FB698E172A95F49BE009B36D56F53E229C4E7@EXCHMB1-ELS.BWINC.local>

Hello,

So I'm on some red hat clients and I have seen this a few times when attempting to enroll them as clients.

Enrolled in IPA realm OPS.BOINGO.COM
Failed to obtain host TGT.
Installation failed. Rolling back changes.
IPA client is not configured on this system.


as any one seen this or know how to troubleshoot it?

thanks in advance you guys are the best!

-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140320/d08d2cf5/attachment.htm>

From dpal at redhat.com  Thu Mar 20 23:58:00 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Thu, 20 Mar 2014 19:58:00 -0400 (EDT)
Subject: [Freeipa-users] Client enrollment failing
In-Reply-To: <6FB698E172A95F49BE009B36D56F53E229C4E7@EXCHMB1-ELS.BWINC.local>
References: <6FB698E172A95F49BE009B36D56F53E229C4E7@EXCHMB1-ELS.BWINC.local>
Message-ID: <1729284718.4484995.1395359880555.JavaMail.zimbra@redhat.com>

http://www.freeipa.org/page/Troubleshooting

----- Original Message -----
From: "Todd Maugh" <tmaugh at boingo.com>
To: freeipa-users at redhat.com
Sent: Thursday, March 20, 2014 6:46:27 PM
Subject: [Freeipa-users] Client enrollment failing

Hello, 

So I'm on some red hat clients and I have seen this a few times when attempting to enroll them as clients. 

Enrolled in IPA realm OPS.BOINGO.COM 
Failed to obtain host TGT. 
Installation failed. Rolling back changes. 
IPA client is not configured on this system. 


as any one seen this or know how to troubleshoot it? 

thanks in advance you guys are the best! 

-Todd 

_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



From kelvin.edmison at alcatel-lucent.com  Fri Mar 21 03:00:01 2014
From: kelvin.edmison at alcatel-lucent.com (EDMISON, Kelvin (Kelvin))
Date: Fri, 21 Mar 2014 03:00:01 +0000
Subject: [Freeipa-users] Client enrollment failing
Message-ID: <CF5122DD.19A70%kelvin.edmison@alcatel-lucent.com>

I had this exact set of messages appear earlier this week.

In my case, the reverse DNS for the host did not match the hostname for
the client.  
I had to fix the reverse DNS and clear out the client's entry on the IPA
server.  Then I could successfully enrol the host.

Regards,
  Kelvin



----- Original Message -----
From:  Todd Maugh <tmaugh at boingo.com>
Date:  Thursday, March 20, 2014 at 6:46 PM
To:  freeipa-users <freeipa-users at redhat.com>
Subject:  [Freeipa-users] Client enrollment failing


Hello,

So I'm on some red hat clients and I have seen this a few times when
attempting to enroll them as clients.

Enrolled in IPA realm OPS.BOINGO.COM
Failed to obtain host TGT.
Installation failed. Rolling back changes.
IPA client is not configured on this system.


as any one seen this or know how to troubleshoot it?

thanks in advance you guys are the best!

-Todd




From arthur at deus.pro  Fri Mar 21 03:15:36 2014
From: arthur at deus.pro (Arthur Faizullin)
Date: Fri, 21 Mar 2014 09:15:36 +0600
Subject: [Freeipa-users] About Windows client
In-Reply-To: <53052ED3.3030906@redhat.com>
References: <53052ED3.3030906@redhat.com>
Message-ID: <532BAED8.1090705@deus.pro>

HI!
I've got some thoughts on 4-th point: there is a http://pgina.org/ pgina
project, may be them are able to do such thing.

20.02.2014 04:23, Dmitri Pal ?????:
> Hello,
>
> I want to summarize our position regarding joining Windows systems
> into IPA.
>
> 1) If you already have AD we recommend using this system with AD and
> using trusts between AD and IPA.
> 2) If you do not have AD then use Samba 4 instead of it. It would be
> great when Samba 4 grows capability to establish trusts. Right now it
> can't but there is an effort going on. If you are interested - please
> contribute.
> 3) If neither of the two options work for you you can configure
> Windows system to work directly with IPA as described on the wiki. It
> is an option of last resort because IPA does not provide the services
> windows client expects. If this is good enough for you, fine by us.
> 4) Build a native Windows client (cred provider) for IPA using latest
> Kerberos. IMO this would be really useful if someone does that because
> we will not build this ourselves. With the native OTP support in IPA
> it becomes a real business opportunity to provide a native 2FA inside
> enterprise across multiple platforms. But please do it open source way
> otherwise we would not recommend you ;-)
>
>



From arthur at deus.pro  Fri Mar 21 03:32:13 2014
From: arthur at deus.pro (Arthur Faizullin)
Date: Fri, 21 Mar 2014 09:32:13 +0600
Subject: [Freeipa-users] SSSD Failover does not work
In-Reply-To: <20140225123333.GA4242@hendrix.brq.redhat.com>
References: <mailman.5756.1389969970.18909.freeipa-users@redhat.com>	<530C6233.5000100@kajot.cz>
	<20140225123333.GA4242@hendrix.brq.redhat.com>
Message-ID: <532BB2BD.6090009@deus.pro>

Will it be represented in documentation&wiki? :)

25.02.2014 18:33, Jakub Hrozek ?????:
> On Tue, Feb 25, 2014 at 10:28:19AM +0100, Stanislav Zidek wrote:
>>> Date: Fri, 17 Jan 2014 09:46:08 -0500
>>> From: Dmitri Pal <dpal at redhat.com>
>>> To: freeipa-users at redhat.com
>>> Subject: Re: [Freeipa-users] SSSD Failover does not work
>>> Message-ID: <52D94230.6080108 at redhat.com>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> You would need to up the debug_level to 6 on SSSD, restart it, then
>>> simulate the situation and provide sanitized logs and sssd configuration
>>> file.
>> Hi and sorry for late reply, I've been ill and then lots of work waited
>> for me ;)
>>
>> I tried to further debug the issue and I was able to make it work by
>> adding the second ipa server also to directives ldap_uri and krb5_server
>> (it was probably my mistake to put it only to ipa_server) - of course in
>> /etc/sssd/sssd.conf
>>
>> Here is my working /etc/sssd/sssd.conf in case anyone finds it useful
>> (or someone has a comment - feel free to tell me how to make things better):
>>
>> [domain/kajot.cz]
>>
>> cache_credentials = True
>> krb5_store_password_if_offline = True
>> ipa_domain = kajot.cz
>> id_provider = ipa
>> auth_provider = ipa
>> access_provider = ipa
>> ldap_tls_cacert = /etc/ipa/ca.crt
>> ipa_hostname = <<<SERVER NAME>>>
>> chpass_provider = ipa
>> ipa_server = id1.kajot.cz, id2.kajot.cz
>>
>> # For the SUDO integration
>> sudo_provider = ldap
>> ldap_uri = ldap://id1.kajot.cz, ldap://id2.kajot.cz
>> ldap_sudo_search_base = ou=sudoers,dc=kajot,dc=cz
>> ldap_sasl_mech = GSSAPI
>> ldap_sasl_authid = host/redmine.kajot.cz
>> ldap_sasl_realm = KAJOT.CZ
>> krb5_server = id1.kajot.cz, id2.kajot.cz
>>
>>
>> ldap_sudo_smart_refresh_interval = 120
>> ldap_sudo_full_refresh_interval = 300
>>
>> [sssd]
>> services = nss, pam, ssh, sudo
>> config_file_version = 2
>>
>> domains = kajot.cz
>>
>> [nss]
>>
>> [pam]
>>
>> [sudo]
>>
>> [autofs]
>>
>> [ssh]
>>
>> [pac]
>>
>>
>> P.S. I hope it gets posted to the right place, Thunderbird and digest
>> mode is probably not very good combination.. If it goes wrong, sorry in
>> advance.
>>
>> S.
>>
> Ah, I didn't realize you were mixing several provider types. It's the
> right thing to do for sudo intergration with RHEL-6, unfortunately.
>
> In 6.6 there will be (and there already is in 7.0 and upstream 1.9.6 and
> later) a native sudo_provider=ipa so you'll be able to streamline your
> configuration even more.
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users



From lslebodn at redhat.com  Fri Mar 21 07:04:23 2014
From: lslebodn at redhat.com (Lukas Slebodnik)
Date: Fri, 21 Mar 2014 08:04:23 +0100
Subject: [Freeipa-users] SSSD Failover does not work
In-Reply-To: <532BB2BD.6090009@deus.pro>
References: <mailman.5756.1389969970.18909.freeipa-users@redhat.com>
	<530C6233.5000100@kajot.cz>
	<20140225123333.GA4242@hendrix.brq.redhat.com>
	<532BB2BD.6090009@deus.pro>
Message-ID: <20140321070423.GA4399@mail.corp.redhat.com>

On (21/03/14 09:32), Arthur Faizullin wrote:
>Will it be represented in documentation&wiki? :)
>
It is written in manual pages:
    man sssd-sudo
        -> CONFIGURING SUDO TO COOPERATE WITH SSSD
        -> CONFIGURING SSSD TO FETCH SUDO RULES

Any contribution is welcomed.
If you want to upgrade documentation or wiki you can do it.
http://www.freeipa.org/page/Contribute#How_Can_I_Help.3F

LS

>25.02.2014 18:33, Jakub Hrozek ?????:
>> On Tue, Feb 25, 2014 at 10:28:19AM +0100, Stanislav Zidek wrote:
>>>> Date: Fri, 17 Jan 2014 09:46:08 -0500
>>>> From: Dmitri Pal <dpal at redhat.com>
>>>> To: freeipa-users at redhat.com
>>>> Subject: Re: [Freeipa-users] SSSD Failover does not work
>>>> Message-ID: <52D94230.6080108 at redhat.com>
>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>>
>>>> You would need to up the debug_level to 6 on SSSD, restart it, then
>>>> simulate the situation and provide sanitized logs and sssd configuration
>>>> file.
>>> Hi and sorry for late reply, I've been ill and then lots of work waited
>>> for me ;)
>>>
>>> I tried to further debug the issue and I was able to make it work by
>>> adding the second ipa server also to directives ldap_uri and krb5_server
>>> (it was probably my mistake to put it only to ipa_server) - of course in
>>> /etc/sssd/sssd.conf
>>>
>>> Here is my working /etc/sssd/sssd.conf in case anyone finds it useful
>>> (or someone has a comment - feel free to tell me how to make things better):
>>>
>>> [domain/kajot.cz]
>>>
>>> cache_credentials = True
>>> krb5_store_password_if_offline = True
>>> ipa_domain = kajot.cz
>>> id_provider = ipa
>>> auth_provider = ipa
>>> access_provider = ipa
>>> ldap_tls_cacert = /etc/ipa/ca.crt
>>> ipa_hostname = <<<SERVER NAME>>>
>>> chpass_provider = ipa
>>> ipa_server = id1.kajot.cz, id2.kajot.cz
>>>
>>> # For the SUDO integration
>>> sudo_provider = ldap
>>> ldap_uri = ldap://id1.kajot.cz, ldap://id2.kajot.cz
>>> ldap_sudo_search_base = ou=sudoers,dc=kajot,dc=cz
>>> ldap_sasl_mech = GSSAPI
>>> ldap_sasl_authid = host/redmine.kajot.cz
>>> ldap_sasl_realm = KAJOT.CZ
>>> krb5_server = id1.kajot.cz, id2.kajot.cz
>>>
>>>
>>> ldap_sudo_smart_refresh_interval = 120
>>> ldap_sudo_full_refresh_interval = 300
>>>
>>> [sssd]
>>> services = nss, pam, ssh, sudo
>>> config_file_version = 2
>>>
>>> domains = kajot.cz
>>>
>>> [nss]
>>>
>>> [pam]
>>>
>>> [sudo]
>>>
>>> [autofs]
>>>
>>> [ssh]
>>>
>>> [pac]
>>>
>>>
>>> P.S. I hope it gets posted to the right place, Thunderbird and digest
>>> mode is probably not very good combination.. If it goes wrong, sorry in
>>> advance.
>>>
>>> S.
>>>
>> Ah, I didn't realize you were mixing several provider types. It's the
>> right thing to do for sudo intergration with RHEL-6, unfortunately.
>>
>> In 6.6 there will be (and there already is in 7.0 and upstream 1.9.6 and
>> later) a native sudo_provider=ipa so you'll be able to streamline your
>> configuration even more.
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>_______________________________________________
>Freeipa-users mailing list
>Freeipa-users at redhat.com
>https://www.redhat.com/mailman/listinfo/freeipa-users



From dpal at redhat.com  Fri Mar 21 15:20:48 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 21 Mar 2014 11:20:48 -0400
Subject: [Freeipa-users] About Windows client
In-Reply-To: <532BAED8.1090705@deus.pro>
References: <53052ED3.3030906@redhat.com> <532BAED8.1090705@deus.pro>
Message-ID: <532C58D0.9050806@redhat.com>

On 03/20/2014 11:15 PM, Arthur Faizullin wrote:
> HI!
> I've got some thoughts on 4-th point: there is a http://pgina.org/ pgina
> project, may be them are able to do such thing.

Yes pgina is one of the options.
Someone would have to take it and integrate with MIT Kerberos for 
Windows if it is not already doing so.
But I suspect that it would be more a project in itself that would 
leverage code from MIT and may be pgina to integrate different parts.
The biggest part figuring out the domain affiliation. I mean the use 
cases like this:
a) The system is domainless but user authentictaes with user name and 
password against IPA
b) The system is domainless but user authentictaes with user name and 
OTP against IPA
c) The system is in an AD domain trusted by IdM domain but user 
authenticates with user name and password against IPA because he is in 
IdM domain.
d) The system is in an AD domain trusted by IdM domain but user 
authenticates with user name and password against IPA because he is in 
IdM domain.

More to research. We can help with guidance if someone wants to run with it.

Thanks
Dmitri

>
> 20.02.2014 04:23, Dmitri Pal ?????:
>> Hello,
>>
>> I want to summarize our position regarding joining Windows systems
>> into IPA.
>>
>> 1) If you already have AD we recommend using this system with AD and
>> using trusts between AD and IPA.
>> 2) If you do not have AD then use Samba 4 instead of it. It would be
>> great when Samba 4 grows capability to establish trusts. Right now it
>> can't but there is an effort going on. If you are interested - please
>> contribute.
>> 3) If neither of the two options work for you you can configure
>> Windows system to work directly with IPA as described on the wiki. It
>> is an option of last resort because IPA does not provide the services
>> windows client expects. If this is good enough for you, fine by us.
>> 4) Build a native Windows client (cred provider) for IPA using latest
>> Kerberos. IMO this would be really useful if someone does that because
>> we will not build this ourselves. With the native OTP support in IPA
>> it becomes a real business opportunity to provide a native 2FA inside
>> enterprise across multiple platforms. But please do it open source way
>> otherwise we would not recommend you ;-)
>>
>>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/





From dpal at redhat.com  Fri Mar 21 15:22:14 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 21 Mar 2014 11:22:14 -0400
Subject: [Freeipa-users] slow response when adding users to heavily
 populated groups
In-Reply-To: <etPan.5328668d.74b0dc51.39c1@Mav.local>
References: <etPan.5328668d.74b0dc51.39c1@Mav.local>
Message-ID: <532C5926.3000603@redhat.com>

On 03/18/2014 11:30 AM, Alfredo Colangelo wrote:
> Hi guys,
> I have a problem when adding users to groups containing many members, I do this with the command:
>
> /usr/bin/ipa group-add-member group --users=user
>
> In this case I have a very slow response - it could take 1 minute or more to complete the command - and it slows down as more members are added to the group.
> I guess it'a a problem with ldap indexes, but how to speed it up?


There have been a problem like this in the past. What version of 389 
DS/IPA do you have?
>
> Thanks in advance
> -- Al
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/





From erinn.looneytriggs at gmail.com  Fri Mar 21 19:11:16 2014
From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs)
Date: Fri, 21 Mar 2014 13:11:16 -0600
Subject: [Freeipa-users] OTP in RHEL 7
Message-ID: <532C8ED4.2030101@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hopefully I am not overlooking something. However, it appears that
with RHEL 7 IPA includes the OTP auth piece. However, I can't seem to
find any documentation on how to use it.

I can deconstruct from the Fedora test day, but before I head down
that road I wanted to see if I had missed something...

Thanks,
- -Erinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJTLI7PAAoJEFg7BmJL2iPOPHYH/13pTzpdH6BayItnWyYuG5UJ
qjGoGGYk4xiTFRKTQfnwt3XyF2+65EeNIRpKUFhtvkjwh+AWk5BUhv/LwM50BZr9
f+QWklDBWliG+GGRny5HY3c6fOBIOqOOx0omWlGm/kw3IAA530Ue/3KJs4SwmdNp
pUhS9LezXnmutthrgeMPoq5YJ4tCRZ8aEf3EZfDpg0f4yM2lCQ5JD1FA5JA2V96Y
XxxQWsIdOXe2EKTE0/9PHpFv1LBUUpCucxtZv88nkTXA+xsvUSRNgds9KKDcbVQS
ceLEAKRs0mNmsI8QJ0N5BLNYxK4ZQRSp2eXsMXYOdBow80rmHW+IiE+oxVm+p5U=
=KYm5
-----END PGP SIGNATURE-----



From abokovoy at redhat.com  Fri Mar 21 20:54:04 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Fri, 21 Mar 2014 22:54:04 +0200
Subject: [Freeipa-users] OTP in RHEL 7
In-Reply-To: <532C8ED4.2030101@gmail.com>
References: <532C8ED4.2030101@gmail.com>
Message-ID: <20140321205404.GB21211@redhat.com>

On Fri, 21 Mar 2014, Erinn Looney-Triggs wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hopefully I am not overlooking something. However, it appears that
>with RHEL 7 IPA includes the OTP auth piece. However, I can't seem to
>find any documentation on how to use it.
>
>I can deconstruct from the Fedora test day, but before I head down
>that road I wanted to see if I had missed something...
OTP feature will be supported in FreeIPA 4.0 which is slated for Fedora 21.

We have number of key interdependencies with SSSD and Kerberos
libraries, where few important changes where needed to be done to make
sure all parts of the client puzzle are working properly.

Server side work is not finished yet, there are several patches still in
review and some of token types need more work. It also need some of
newer 389-ds packages that only made to Fedora 20 early March.

In short, it is work in progress yet.

-- 
/ Alexander Bokovoy



From erinn.looneytriggs at gmail.com  Fri Mar 21 21:33:22 2014
From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs)
Date: Fri, 21 Mar 2014 15:33:22 -0600
Subject: [Freeipa-users] OTP in RHEL 7
In-Reply-To: <20140321205404.GB21211@redhat.com>
References: <532C8ED4.2030101@gmail.com> <20140321205404.GB21211@redhat.com>
Message-ID: <532CB022.7040801@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/21/2014 02:54 PM, Alexander Bokovoy wrote:
> On Fri, 21 Mar 2014, Erinn Looney-Triggs wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Hopefully I am not overlooking something. However, it appears
>> that with RHEL 7 IPA includes the OTP auth piece. However, I
>> can't seem to find any documentation on how to use it.
>> 
>> I can deconstruct from the Fedora test day, but before I head
>> down that road I wanted to see if I had missed something...
> OTP feature will be supported in FreeIPA 4.0 which is slated for
> Fedora 21.
> 
> We have number of key interdependencies with SSSD and Kerberos 
> libraries, where few important changes where needed to be done to
> make sure all parts of the client puzzle are working properly.
> 
> Server side work is not finished yet, there are several patches
> still in review and some of token types need more work. It also
> need some of newer 389-ds packages that only made to Fedora 20
> early March.
> 
> In short, it is work in progress yet.
> 

Thanks for the update I appreciate it.

Keep up the great work,

- -Erinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJTLLAdAAoJEFg7BmJL2iPOqQUIAIU6CFo+thrQjJ+fHe2E4qS7
AvBkiVDsU2VVyWGpeVwrX3PWON/PPkGW4Jkq41oMyB+oIzvLczWqO1CWNpgoROIY
Bfnwr/hZtUST2nzkjwE4Tge4NlGrCIS1CiAK+HTLvoGn07MilnEbWCb9TunH690/
TwF7TJ2GpWXi5oqT7v9epgEeEzX4dl0svLj6M3bDhUL7/mvF7LIJKyXriXkij5mO
jD89rnJi74syQNbganb+U1e4mcdta8IGB7V6y1uCaCGykyMmRnNfhywXDO7q7tsp
ntBvYNyMhKLF4r934X4YO9hD08C9hrwGs8GTGZiuB5B4YfTXIDefHw7N1fB6ZE8=
=jc18
-----END PGP SIGNATURE-----



From shreerajkarulkar at yahoo.com  Fri Mar 21 23:44:51 2014
From: shreerajkarulkar at yahoo.com (Shree)
Date: Fri, 21 Mar 2014 16:44:51 -0700 (PDT)
Subject: [Freeipa-users] ipa-client-install fails on replica because of
	kinit cannot contact any KDC
In-Reply-To: <532A9E07.6040604@redhat.com>
References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<1392400546.80716.YahooMailNeo@web160104.mail.bf1.yahoo.com>	<52F!	E5E83.70904@redhat.com>	<1392405290.42448.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<52FE7119.1070601@redhat.com>	<1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<5303B22A.9070709@redhat.com>	<1!	392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com>	!	<53051B35.2050409@redhat.com>	<1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com!	>	<53051F62.40405@redhat.com>	<1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com!	>	<53052E64.3050903@redhat.com>	<1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c!	!	om>	<53061B18.40001@redhat.com>	<1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<53066CD0.5080501@redhat.!	!
	com> <1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com>
	<1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo!
	! .com> <532A9E07.6040604@redhat.com>
Message-ID: <1395445491.29606.YahooMailNeo@web160105.mail.bf1.yahoo.com>

Hi
Attaching the install log. It complains about unable to reach certain ports, however my tests by using telnet were successful. Also to refresh your memory the client should be reaching for the replica lda2.mydomain.com and not ldap.mydomain.com which it does for the most part but I found a couple of instances of ldap.mydomain.com in the log. Let me know what you find. I can't believe I migrated over 40 servers and only this one refuses to install ipa-client.



?
Shreeraj 
---------------------------------------------------------------------------------------- 

Change is the only Constant !



On Thursday, March 20, 2014 4:29 AM, Martin Kosek <mkosek at redhat.com> wrote:
 
On 03/19/2014 10:37 PM, Shree wrote:

> Hello
> I was able to successfully move all my clients to the replica except on the process I had to upgrade the client to "ipa-client-3.0.0-37.el6.x86_64" and some times run a --uninstall 
> 
> . Bit it works for the most part. Have been struggling with one last host with errors like below. I have tested the port connectivity using telnet and netcat commands but the install thinks these ports are blocked? 
> 
>? 
> 
> 
> kerberos authentication failed
> kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting initial credentials
> 
> Please make sure the following ports are opened in the firewall settings:
>? ? ? TCP: 80, 88, 389
>? ? ? UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
> Also note that following ports are necessary for ipa-client working properly after enrollment:
>? ? ? TCP: 464
>? ? ? UDP: 464, 123 (if NTP enabled)
> Installation failed. Rolling back changes.
> Disabling client Kerberos and LDAP configurations
> Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted
> Restoring client configuration files
> Client uninstall complete.
> [root at www /]#
> 
> In the /var/log/ipaclient-install.log I also see things like below. I get Autodiscovery failures but I am manually entering things and they have been working.
> 
> 2014-03-19T21:13:47Z DEBUG Found: cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
> 2014-03-19T21:13:47Z DEBUG Discovery result: Success; server=ldap2.mydomain.com, domain=mydomain.com, kdc=ldap.mydomain.com, basedn=dc=mydomain,dc=com
> 2014-03-19T21:13:47Z DEBUG Validated servers: ldap2.mydomain.com
> 2014-03-19T21:13:47Z WARNING The failure to use DNS to find your IPA server indicates that your resolv.conf file is not properly configured.
> 2014-03-19T21:13:47Z INFO Autodiscovery of servers for failover cannot work with this configuration.
> 2014-03-19T21:13:47Z INFO If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure.

Ok. I would guess you have some DNS issue. But it is hard to tell without the
entire ipaclient-install.log of the failed installation.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140321/cd29dbf1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipaclient-install.log
Type: application/octet-stream
Size: 15087 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140321/cd29dbf1/attachment.obj>

From arthur at deus.pro  Sat Mar 22 17:18:26 2014
From: arthur at deus.pro (Arthur)
Date: Sat, 22 Mar 2014 23:18:26 +0600
Subject: [Freeipa-users] About Windows client
In-Reply-To: <532C58D0.9050806@redhat.com>
References: <53052ED3.3030906@redhat.com> <532BAED8.1090705@deus.pro>
	<532C58D0.9050806@redhat.com>
Message-ID: <532DC5E2.40106@deus.pro>

Dmitri Pal wrote:
> On 03/20/2014 11:15 PM, Arthur Faizullin wrote:
>> HI!
>> I've got some thoughts on 4-th point: there is a http://pgina.org/ pgina
>> project, may be them are able to do such thing.
>
> Yes pgina is one of the options.
> Someone would have to take it and integrate with MIT Kerberos for 
> Windows if it is not already doing so.
> But I suspect that it would be more a project in itself that would 
> leverage code from MIT and may be pgina to integrate different parts.
> The biggest part figuring out the domain affiliation. I mean the use 
> cases like this:
> a) The system is domainless but user authentictaes with user name and 
> password against IPA
> b) The system is domainless but user authentictaes with user name and 
> OTP against IPA
> c) The system is in an AD domain trusted by IdM domain but user 
> authenticates with user name and password against IPA because he is in 
> IdM domain.
> d) The system is in an AD domain trusted by IdM domain but user 
> authenticates with user name and password against IPA because he is in 
> IdM domain.
>
> More to research. We can help with guidance if someone wants to run 
> with it.
>
> Thanks
> Dmitri
>
>>
>> 20.02.2014 04:23, Dmitri Pal ?????:
>>> Hello,
>>>
>>> I want to summarize our position regarding joining Windows systems
>>> into IPA.
>>>
>>> 1) If you already have AD we recommend using this system with AD and
>>> using trusts between AD and IPA.
>>> 2) If you do not have AD then use Samba 4 instead of it. It would be
>>> great when Samba 4 grows capability to establish trusts. Right now it
>>> can't but there is an effort going on. If you are interested - please
>>> contribute.
>>> 3) If neither of the two options work for you you can configure
>>> Windows system to work directly with IPA as described on the wiki. It
>>> is an option of last resort because IPA does not provide the services
>>> windows client expects. If this is good enough for you, fine by us.
>>> 4) Build a native Windows client (cred provider) for IPA using latest
>>> Kerberos. IMO this would be really useful if someone does that because
>>> we will not build this ourselves. With the native OTP support in IPA
>>> it becomes a real business opportunity to provide a native 2FA inside
>>> enterprise across multiple platforms. But please do it open source way
>>> otherwise we would not recommend you ;-)
>>>
>>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
My friend agreed to try. He is C# programmer. But the problem that has 
low knowledge about kerberos, GSSAPI, and I could not told him what is 
wrong with current pgina's ldap plugin.
He does not want to subscribe to freeipa mail-lists, so may be I shall 
give him your (Dmitri) e-mail?
He speaks russian :)



From dpal at redhat.com  Sat Mar 22 21:12:48 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sat, 22 Mar 2014 17:12:48 -0400
Subject: [Freeipa-users] ipa-client-install fails on replica because of
 kinit cannot contact any KDC
In-Reply-To: <1395445491.29606.YahooMailNeo@web160105.mail.bf1.yahoo.com>
References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<52FE7119.1070601@redhat.com>	<1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<5303B22A.9070709@redhat.com>	<1!	392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com>	!	<53051B35.2050409@redhat.com>	<1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com!	>	<53051F62.40405@redhat.com>	<1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com!	>	<53052E64.3050903@redhat.com>	<1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c!	!	om>	<53061B18.40001@redhat.com>	<1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<53066CD0.5080501@redhat.!	!
	com> <1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com>
	<1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo! !
	.com> <532A9E07.6040604@redhat.com>
	<1395445491.29606.YahooMailNeo@web160105.mail.bf1.yahoo.com>
Message-ID: <532DFCD0.8060907@redhat.com>

On 03/21/2014 07:44 PM, Shree wrote:
> Hi
> Attaching the install log. It complains about unable to reach certain 
> ports, however my tests by using telnet were successful. Also to 
> refresh your memory the client should be reaching for the replica 
> lda2.mydomain.com and not ldap.mydomain.com which it does for the most 
> part but I found a couple of instances of ldap.mydomain.com in the 
> log. Let me know what you find. I can't believe I migrated over 40 
> servers and only this one refuses to install ipa-client.
>

If it is getting to the wrong server then it is either looking at the 
wrong DNS server (see resolve.conf) which is telling it to use the wrong 
IPA server (may be from some old try/POC) or it has some explicit 
entries entered in /etc/hosts.


>
> Shreeraj
> ---------------------------------------------------------------------------------------- 
>
>
> Change is the only Constant !
>
>
> On Thursday, March 20, 2014 4:29 AM, Martin Kosek <mkosek at redhat.com> 
> wrote:
> On 03/19/2014 10:37 PM, Shree wrote:
>
> > Hello
> > I was able to successfully move all my clients to the replica except 
> on the process I had to upgrade the client to 
> "ipa-client-3.0.0-37.el6.x86_64" and some times run a --uninstall
> >
> > . Bit it works for the most part. Have been struggling with one last 
> host with errors like below. I have tested the port connectivity using 
> telnet and netcat commands but the install thinks these ports are 
> blocked?
> >
> >
> >
> >
> > kerberos authentication failed
> > kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting 
> initial credentials
> >
> > Please make sure the following ports are opened in the firewall 
> settings:
> >      TCP: 80, 88, 389
> >      UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
> > Also note that following ports are necessary for ipa-client working 
> properly after enrollment:
> >      TCP: 464
> >      UDP: 464, 123 (if NTP enabled)
> > Installation failed. Rolling back changes.
> > Disabling client Kerberos and LDAP configurations
> > Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to 
> /etc/sssd/sssd.conf.deleted
> > Restoring client configuration files
> > Client uninstall complete.
> > [root at www <mailto:root at www> /]#
> >
> > In the /var/log/ipaclient-install.log I also see things like below. 
> I get Autodiscovery failures but I am manually entering things and 
> they have been working.
> >
> > 2014-03-19T21:13:47Z DEBUG Found: 
> cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
> > 2014-03-19T21:13:47Z DEBUG Discovery result: Success; 
> server=ldap2.mydomain.com, domain=mydomain.com, kdc=ldap.mydomain.com, 
> basedn=dc=mydomain,dc=com
> > 2014-03-19T21:13:47Z DEBUG Validated servers: ldap2.mydomain.com
> > 2014-03-19T21:13:47Z WARNING The failure to use DNS to find your IPA 
> server indicates that your resolv.conf file is not properly configured.
> > 2014-03-19T21:13:47Z INFO Autodiscovery of servers for failover 
> cannot work with this configuration.
> > 2014-03-19T21:13:47Z INFO If you proceed with the installation, 
> services will be configured to always access the discovered server for 
> all operations and will not fail over to other servers in case of failure.
>
>
> Ok. I would guess you have some DNS issue. But it is hard to tell 
> without the
> entire ipaclient-install.log of the failed installation.
>
> Martin
>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140322/aa13ce33/attachment.htm>

From dpal at redhat.com  Sat Mar 22 21:17:25 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sat, 22 Mar 2014 17:17:25 -0400
Subject: [Freeipa-users] About Windows client
In-Reply-To: <532DC5E2.40106@deus.pro>
References: <53052ED3.3030906@redhat.com> <532BAED8.1090705@deus.pro>
	<532C58D0.9050806@redhat.com> <532DC5E2.40106@deus.pro>
Message-ID: <532DFDE5.30308@redhat.com>

On 03/22/2014 01:18 PM, Arthur wrote:
> Dmitri Pal wrote:
>> On 03/20/2014 11:15 PM, Arthur Faizullin wrote:
>>> HI!
>>> I've got some thoughts on 4-th point: there is a http://pgina.org/ 
>>> pgina
>>> project, may be them are able to do such thing.
>>
>> Yes pgina is one of the options.
>> Someone would have to take it and integrate with MIT Kerberos for 
>> Windows if it is not already doing so.
>> But I suspect that it would be more a project in itself that would 
>> leverage code from MIT and may be pgina to integrate different parts.
>> The biggest part figuring out the domain affiliation. I mean the use 
>> cases like this:
>> a) The system is domainless but user authentictaes with user name and 
>> password against IPA
>> b) The system is domainless but user authentictaes with user name and 
>> OTP against IPA
>> c) The system is in an AD domain trusted by IdM domain but user 
>> authenticates with user name and password against IPA because he is 
>> in IdM domain.
>> d) The system is in an AD domain trusted by IdM domain but user 
>> authenticates with user name and password against IPA because he is 
>> in IdM domain.
>>
>> More to research. We can help with guidance if someone wants to run 
>> with it.
>>
>> Thanks
>> Dmitri
>>
>>>
>>> 20.02.2014 04:23, Dmitri Pal ?????:
>>>> Hello,
>>>>
>>>> I want to summarize our position regarding joining Windows systems
>>>> into IPA.
>>>>
>>>> 1) If you already have AD we recommend using this system with AD and
>>>> using trusts between AD and IPA.
>>>> 2) If you do not have AD then use Samba 4 instead of it. It would be
>>>> great when Samba 4 grows capability to establish trusts. Right now it
>>>> can't but there is an effort going on. If you are interested - please
>>>> contribute.
>>>> 3) If neither of the two options work for you you can configure
>>>> Windows system to work directly with IPA as described on the wiki. It
>>>> is an option of last resort because IPA does not provide the services
>>>> windows client expects. If this is good enough for you, fine by us.
>>>> 4) Build a native Windows client (cred provider) for IPA using latest
>>>> Kerberos. IMO this would be really useful if someone does that because
>>>> we will not build this ourselves. With the native OTP support in IPA
>>>> it becomes a real business opportunity to provide a native 2FA inside
>>>> enterprise across multiple platforms. But please do it open source way
>>>> otherwise we would not recommend you ;-)
>>>>
>>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
> My friend agreed to try. He is C# programmer. But the problem that has 
> low knowledge about kerberos, GSSAPI, and I could not told him what is 
> wrong with current pgina's ldap plugin.
> He does not want to subscribe to freeipa mail-lists, so may be I shall 
> give him your (Dmitri) e-mail?
> He speaks russian :)


List is really the way to develop open source software collaboratively. 
This is what we are doing here.
We can agree that the communication about the topic will be prefixed in 
such a way that he can create a filter so that he would get only mails 
that match the filter.
Would that work?

I am not sure that I would be able to provide all the support. We are a 
community here and we have different roles and angles. Working with just 
one person would not fly, sorry.

>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/





From mail at willsheldon.com  Sat Mar 22 21:47:11 2014
From: mail at willsheldon.com (Will Sheldon)
Date: Sat, 22 Mar 2014 14:47:11 -0700
Subject: [Freeipa-users] About Windows client
In-Reply-To: <532DFDE5.30308@redhat.com>
References: <53052ED3.3030906@redhat.com> <532BAED8.1090705@deus.pro>
	<532C58D0.9050806@redhat.com> <532DC5E2.40106@deus.pro>
	<532DFDE5.30308@redhat.com>
Message-ID: <9FF6A479E0BA458DA414CBAD739CFD8A@willsheldon.com>


I?d be curious to see how well a solution that combines pGina using RADIUS against some middleware like the Gluu server (www.gluu.org)  backed by IPA would work.

It strikes me that getting domain federation between IPA and Gluu would tick a lot of boxes as it seems to offer a host of authentication and accounting interfaces including oAuth, SAML, OpenID and of course RADIUS.  


Kind regards,

Will Sheldon
+1.778-689-1244


On Saturday, March 22, 2014 at 2:17 PM, Dmitri Pal wrote:

> On 03/22/2014 01:18 PM, Arthur wrote:
> > Dmitri Pal wrote:
> > > On 03/20/2014 11:15 PM, Arthur Faizullin wrote:
> > > > HI!
> > > > I've got some thoughts on 4-th point: there is a http://pgina.org/  
> > > > pgina
> > > > project, may be them are able to do such thing.
> > > >  
> > >  
> > >  
> > > Yes pgina is one of the options.
> > > Someone would have to take it and integrate with MIT Kerberos for  
> > > Windows if it is not already doing so.
> > > But I suspect that it would be more a project in itself that would  
> > > leverage code from MIT and may be pgina to integrate different parts.
> > > The biggest part figuring out the domain affiliation. I mean the use  
> > > cases like this:
> > > a) The system is domainless but user authentictaes with user name and  
> > > password against IPA
> > > b) The system is domainless but user authentictaes with user name and  
> > > OTP against IPA
> > > c) The system is in an AD domain trusted by IdM domain but user  
> > > authenticates with user name and password against IPA because he is  
> > > in IdM domain.
> > > d) The system is in an AD domain trusted by IdM domain but user  
> > > authenticates with user name and password against IPA because he is  
> > > in IdM domain.
> > >  
> > > More to research. We can help with guidance if someone wants to run  
> > > with it.
> > >  
> > > Thanks
> > > Dmitri
> > >  
> > > >  
> > > > 20.02.2014 04:23, Dmitri Pal ?????:
> > > > > Hello,
> > > > >  
> > > > > I want to summarize our position regarding joining Windows systems
> > > > > into IPA.
> > > > >  
> > > > > 1) If you already have AD we recommend using this system with AD and
> > > > > using trusts between AD and IPA.
> > > > > 2) If you do not have AD then use Samba 4 instead of it. It would be
> > > > > great when Samba 4 grows capability to establish trusts. Right now it
> > > > > can't but there is an effort going on. If you are interested - please
> > > > > contribute.
> > > > > 3) If neither of the two options work for you you can configure
> > > > > Windows system to work directly with IPA as described on the wiki. It
> > > > > is an option of last resort because IPA does not provide the services
> > > > > windows client expects. If this is good enough for you, fine by us.
> > > > > 4) Build a native Windows client (cred provider) for IPA using latest
> > > > > Kerberos. IMO this would be really useful if someone does that because
> > > > > we will not build this ourselves. With the native OTP support in IPA
> > > > > it becomes a real business opportunity to provide a native 2FA inside
> > > > > enterprise across multiple platforms. But please do it open source way
> > > > > otherwise we would not recommend you ;-)
> > > > >  
> > > >  
> > > > _______________________________________________
> > > > Freeipa-users mailing list
> > > > Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com)
> > > > https://www.redhat.com/mailman/listinfo/freeipa-users
> > > >  
> > >  
> > >  
> >  
> > My friend agreed to try. He is C# programmer. But the problem that has  
> > low knowledge about kerberos, GSSAPI, and I could not told him what is  
> > wrong with current pgina's ldap plugin.
> > He does not want to subscribe to freeipa mail-lists, so may be I shall  
> > give him your (Dmitri) e-mail?
> > He speaks russian :)
> >  
>  
>  
>  
> List is really the way to develop open source software collaboratively.  
> This is what we are doing here.
> We can agree that the communication about the topic will be prefixed in  
> such a way that he can create a filter so that he would get only mails  
> that match the filter.
> Would that work?
>  
> I am not sure that I would be able to provide all the support. We are a  
> community here and we have different roles and angles. Working with just  
> one person would not fly, sorry.
>  
> >  
> > _______________________________________________
> > Freeipa-users mailing list
> > Freeipa-users at redhat.com (mailto:Freeipa-users at 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/ (http://www.redhat.com/carveoutcosts/)
>  
>  
>  
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com)
> https://www.redhat.com/mailman/listinfo/freeipa-users
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140322/11f224d0/attachment.htm>

From dpal at redhat.com  Sat Mar 22 23:55:24 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sat, 22 Mar 2014 19:55:24 -0400
Subject: [Freeipa-users] About Windows client
In-Reply-To: <9FF6A479E0BA458DA414CBAD739CFD8A@willsheldon.com>
References: <53052ED3.3030906@redhat.com> <532BAED8.1090705@deus.pro>
	<532C58D0.9050806@redhat.com> <532DC5E2.40106@deus.pro>
	<532DFDE5.30308@redhat.com>
	<9FF6A479E0BA458DA414CBAD739CFD8A@willsheldon.com>
Message-ID: <532E22EC.1020107@redhat.com>

On 03/22/2014 05:47 PM, Will Sheldon wrote:
>
> I?d be curious to see how well a solution that combines pGina using 
> RADIUS against some middleware like the Gluu server (www.gluu.org) 
>  backed by IPA would work.

This is not an interesting scenario. This would would probably work 
right now but the machine would still not know who the user is because 
it will not know user SID so he would be foreign and no Windows policies 
would apply to him. I suspect such user would have no or very limited 
read only access to Windows resources because all Windows ACLs are based 
on knowing the user SIDs and SIDs of the groups the user is a member of.
The value of native IdM integration would be to get user SID and SIDs of 
the groups from IdM and then get the right kerberos ticket(s) for 
Windows resources using cross realm kerberos trusts and put these 
tickets into the right place so that windows system can use them 
automatically when user navigates to the corresponding resource. 
Something like this.

>
> It strikes me that getting domain federation between IPA and Gluu 
> would tick a lot of boxes as it seems to offer a host of 
> authentication and accounting interfaces including oAuth, SAML, OpenID 
> and of course RADIUS.
>
>
> Kind regards,
>
> Will Sheldon
> +1.778-689-1244
>
> On Saturday, March 22, 2014 at 2:17 PM, Dmitri Pal wrote:
>
>> On 03/22/2014 01:18 PM, Arthur wrote:
>>> Dmitri Pal wrote:
>>>> On 03/20/2014 11:15 PM, Arthur Faizullin wrote:
>>>>> HI!
>>>>> I've got some thoughts on 4-th point: there is a http://pgina.org/
>>>>> pgina
>>>>> project, may be them are able to do such thing.
>>>>
>>>> Yes pgina is one of the options.
>>>> Someone would have to take it and integrate with MIT Kerberos for
>>>> Windows if it is not already doing so.
>>>> But I suspect that it would be more a project in itself that would
>>>> leverage code from MIT and may be pgina to integrate different parts.
>>>> The biggest part figuring out the domain affiliation. I mean the use
>>>> cases like this:
>>>> a) The system is domainless but user authentictaes with user name and
>>>> password against IPA
>>>> b) The system is domainless but user authentictaes with user name and
>>>> OTP against IPA
>>>> c) The system is in an AD domain trusted by IdM domain but user
>>>> authenticates with user name and password against IPA because he is
>>>> in IdM domain.
>>>> d) The system is in an AD domain trusted by IdM domain but user
>>>> authenticates with user name and password against IPA because he is
>>>> in IdM domain.
>>>>
>>>> More to research. We can help with guidance if someone wants to run
>>>> with it.
>>>>
>>>> Thanks
>>>> Dmitri
>>>>
>>>>>
>>>>> 20.02.2014 04:23, Dmitri Pal ?????:
>>>>>> Hello,
>>>>>>
>>>>>> I want to summarize our position regarding joining Windows systems
>>>>>> into IPA.
>>>>>>
>>>>>> 1) If you already have AD we recommend using this system with AD and
>>>>>> using trusts between AD and IPA.
>>>>>> 2) If you do not have AD then use Samba 4 instead of it. It would be
>>>>>> great when Samba 4 grows capability to establish trusts. Right now it
>>>>>> can't but there is an effort going on. If you are interested - please
>>>>>> contribute.
>>>>>> 3) If neither of the two options work for you you can configure
>>>>>> Windows system to work directly with IPA as described on the wiki. It
>>>>>> is an option of last resort because IPA does not provide the services
>>>>>> windows client expects. If this is good enough for you, fine by us.
>>>>>> 4) Build a native Windows client (cred provider) for IPA using latest
>>>>>> Kerberos. IMO this would be really useful if someone does that 
>>>>>> because
>>>>>> we will not build this ourselves. With the native OTP support in IPA
>>>>>> it becomes a real business opportunity to provide a native 2FA inside
>>>>>> enterprise across multiple platforms. But please do it open 
>>>>>> source way
>>>>>> otherwise we would not recommend you ;-)
>>>>> _______________________________________________
>>>>> Freeipa-users mailing list
>>>>> Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> My friend agreed to try. He is C# programmer. But the problem that has
>>> low knowledge about kerberos, GSSAPI, and I could not told him what is
>>> wrong with current pgina's ldap plugin.
>>> He does not want to subscribe to freeipa mail-lists, so may be I shall
>>> give him your (Dmitri) e-mail?
>>> He speaks russian :)
>>
>>
>> List is really the way to develop open source software collaboratively.
>> This is what we are doing here.
>> We can agree that the communication about the topic will be prefixed in
>> such a way that he can create a filter so that he would get only mails
>> that match the filter.
>> Would that work?
>>
>> I am not sure that I would be able to provide all the support. We are a
>> community here and we have different roles and angles. Working with just
>> one person would not fly, sorry.
>>
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com <mailto:Freeipa-users at 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/ <http://www.redhat.com/carveoutcosts/>
>>
>>
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com <mailto:Freeipa-users at 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/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140322/64a57613/attachment.htm>

From john.obaterspok at gmail.com  Sun Mar 23 08:01:40 2014
From: john.obaterspok at gmail.com (John Obaterspok)
Date: Sun, 23 Mar 2014 09:01:40 +0100
Subject: [Freeipa-users] kerberized vsftpd login problem
Message-ID: <CAOscVd+vPYNQZ8PU1ckB9eBSGxJftmU8v5uMPfgUBP1ybi_AMA@mail.gmail.com>

Hello,

How do I get vsftpd login to work with an existing ticket?
I've added ftp as an identity service (ftp/ipaserver.my.lan at MY.LAN)

Is there anything else I need to do to allow ftp login to vsftpd?

-- john
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140323/a6f0d882/attachment.htm>

From john.obaterspok at gmail.com  Sun Mar 23 08:21:20 2014
From: john.obaterspok at gmail.com (John Obaterspok)
Date: Sun, 23 Mar 2014 09:21:20 +0100
Subject: [Freeipa-users] Win7 machine occasionally not able to lookup ipa
	hosts
Message-ID: <CAOscVd+jfUP3Ye=8QeyTo7ZLLKFPnObKZmvuTYL-1HtkOYr=kQ@mail.gmail.com>

Hello,

A couple of times each day the win 7 machine is not able to lookup hosts on
the ipa domain. A ipconfig /renew always allows ipa hosts to be resolvable
again.

Any ideas why this happens?

-- john
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140323/1d7567bd/attachment.htm>

From mail at willsheldon.com  Sun Mar 23 17:52:11 2014
From: mail at willsheldon.com (Will Sheldon)
Date: Sun, 23 Mar 2014 10:52:11 -0700
Subject: [Freeipa-users] Win7 machine occasionally not able to lookup
 ipa hosts
In-Reply-To: <CAOscVd+jfUP3Ye=8QeyTo7ZLLKFPnObKZmvuTYL-1HtkOYr=kQ@mail.gmail.com>
References: <CAOscVd+jfUP3Ye=8QeyTo7ZLLKFPnObKZmvuTYL-1HtkOYr=kQ@mail.gmail.com>
Message-ID: <4F1A553C69F348149FFDE23E589E57B5@willsheldon.com>


What is the difference in the output of "ipconfig /all? before and after the "ipconfig /renew??


Kind regards,

Will Sheldon


On Sunday, March 23, 2014 at 1:21 AM, John Obaterspok wrote:

> Hello,
>  
> A couple of times each day the win 7 machine is not able to lookup hosts on the ipa domain. A ipconfig /renew always allows ipa hosts to be resolvable again.
>  
> Any ideas why this happens?
>  
> -- john  
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com)
> https://www.redhat.com/mailman/listinfo/freeipa-users
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140323/05a72087/attachment.htm>

From john.obaterspok at gmail.com  Sun Mar 23 21:34:07 2014
From: john.obaterspok at gmail.com (John Obaterspok)
Date: Sun, 23 Mar 2014 22:34:07 +0100
Subject: [Freeipa-users] Win7 machine occasionally not able to lookup
	ipa hosts
In-Reply-To: <4F1A553C69F348149FFDE23E589E57B5@willsheldon.com>
References: <CAOscVd+jfUP3Ye=8QeyTo7ZLLKFPnObKZmvuTYL-1HtkOYr=kQ@mail.gmail.com>
	<4F1A553C69F348149FFDE23E589E57B5@willsheldon.com>
Message-ID: <CAOscVdL1gxS0_DUnPRzZyRM0hODULtVx-U-=pQmoT_Z=zGAwQg@mail.gmail.com>

Hello,

I just experience this again.ipa server not pingable by name but by ip. Did
a ipconfig /all > file, then ipconfig /renew. Then only lines that differ
is the lease expire:

-   Lease expires. . . . . . . . . . . : 2014-03-24 20:04:28
+  Lease expires. . . . . . . . . . . : 2014-03-24 22:28:09

Any other suggestions?

-- john


2014-03-23 18:52 GMT+01:00 Will Sheldon <mail at willsheldon.com>:

>
>  What is the difference in the output of "ipconfig /all" before and after
> the "ipconfig /renew"?
>
>
> Kind regards,
>
> Will Sheldon
>
> On Sunday, March 23, 2014 at 1:21 AM, John Obaterspok wrote:
>
> Hello,
>
> A couple of times each day the win 7 machine is not able to lookup hosts
> on the ipa domain. A ipconfig /renew always allows ipa hosts to be
> resolvable again.
>
> Any ideas why this happens?
>
> -- john
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140323/029fa1a3/attachment.htm>

From bnordgren at fs.fed.us  Sun Mar 23 22:59:29 2014
From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS)
Date: Sun, 23 Mar 2014 22:59:29 +0000
Subject: [Freeipa-users] About Windows client
In-Reply-To: <532E22EC.1020107@redhat.com>
References: <53052ED3.3030906@redhat.com> <532BAED8.1090705@deus.pro>
	<532C58D0.9050806@redhat.com> <532DC5E2.40106@deus.pro>
	<532DFDE5.30308@redhat.com>
	<9FF6A479E0BA458DA414CBAD739CFD8A@willsheldon.com>
	<532E22EC.1020107@redhat.com>
Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3C39@001FSN2MPN1-045.001f.mgd2.msft.net>

I?m not, in general, in favor of solutions which promiscuously sling Kerberos passwords around the net. ? pGina + Kerberos authenticating directly off of IPA would be the way to go, I think.

Presumably Dimitri?s statement about the user being ?foreign? and having limited access to windows services would apply equally well to a user with a SID from a foreign domain in a large Kerberos federation. This, and the uncertainty concerning what type of directory service the foreign KDC is paired with, is probably responsible for keeping Kerberos-based federations small.

That being said, the collaboration use case (not to mention ?home networks?) is what makes ?foreign? logins interesting. There?s hardly anything in common between two collaboration projects, so it?s hard to define far-reaching policies (i.e., you?re not missing out on much). Most all authorization decisions are delegated out to some project member responsible for the server/asset. Constructing authorization sets having members defined by text based principals makes a certain amount of sense. Hence the LDAP ?member?  attribute in RFC4519.

What would really be cool is the ?inverse? of gluu or openam. Kerberos preauthentication data which allows the KDC to authenticate off of an OpenID Connect, SAML, or LDAP authentication source, caching the provided password and provisioning a Kerberos principal. Future AS exchanges would start out as ?normal? Kerberos. Sort of like migration mode does now. If the KDC could then signal IPA that a new principal was provisioned, IPA could allocate and harmonize an SID and a UID for the principal in the domain.


Poof. Console logins for Windows (pGina) and Linux (sssd) using IPA backed by your google account.  That just eliminated 98% of the external accounts you would have had to create and manage.

Food for thought.

Bryce

From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal
Sent: Saturday, March 22, 2014 5:55 PM
To: Will Sheldon
Cc: freeipa-users at redhat.com
Subject: Re: [Freeipa-users] About Windows client

On 03/22/2014 05:47 PM, Will Sheldon wrote:

I?d be curious to see how well a solution that combines pGina using RADIUS against some middleware like the Gluu server (www.gluu.org<http://www.gluu.org>)  backed by IPA would work.

This is not an interesting scenario. This would would probably work right now but the machine would still not know who the user is because it will not know user SID so he would be foreign and no Windows policies would apply to him. I suspect such user would have no or very limited read only access to Windows resources because all Windows ACLs are based on knowing the user SIDs and SIDs of the groups the user is a member of.
The value of native IdM integration would be to get user SID and SIDs of the groups from IdM and then get the right kerberos ticket(s) for Windows resources using cross realm kerberos trusts and put these tickets into the right place so that windows system can use them automatically when user navigates to the corresponding resource. Something like this.



It strikes me that getting domain federation between IPA and Gluu would tick a lot of boxes as it seems to offer a host of authentication and accounting interfaces including oAuth, SAML, OpenID and of course RADIUS.


Kind regards,

Will Sheldon
+1.778-689-1244


On Saturday, March 22, 2014 at 2:17 PM, Dmitri Pal wrote:
On 03/22/2014 01:18 PM, Arthur wrote:
Dmitri Pal wrote:
On 03/20/2014 11:15 PM, Arthur Faizullin wrote:
HI!
I've got some thoughts on 4-th point: there is a http://pgina.org/
pgina
project, may be them are able to do such thing.

Yes pgina is one of the options.
Someone would have to take it and integrate with MIT Kerberos for
Windows if it is not already doing so.
But I suspect that it would be more a project in itself that would
leverage code from MIT and may be pgina to integrate different parts.
The biggest part figuring out the domain affiliation. I mean the use
cases like this:
a) The system is domainless but user authentictaes with user name and
password against IPA
b) The system is domainless but user authentictaes with user name and
OTP against IPA
c) The system is in an AD domain trusted by IdM domain but user
authenticates with user name and password against IPA because he is
in IdM domain.
d) The system is in an AD domain trusted by IdM domain but user
authenticates with user name and password against IPA because he is
in IdM domain.

More to research. We can help with guidance if someone wants to run
with it.

Thanks
Dmitri


20.02.2014 04:23, Dmitri Pal ?????:
Hello,

I want to summarize our position regarding joining Windows systems
into IPA.

1) If you already have AD we recommend using this system with AD and
using trusts between AD and IPA.
2) If you do not have AD then use Samba 4 instead of it. It would be
great when Samba 4 grows capability to establish trusts. Right now it
can't but there is an effort going on. If you are interested - please
contribute.
3) If neither of the two options work for you you can configure
Windows system to work directly with IPA as described on the wiki. It
is an option of last resort because IPA does not provide the services
windows client expects. If this is good enough for you, fine by us.
4) Build a native Windows client (cred provider) for IPA using latest
Kerberos. IMO this would be really useful if someone does that because
we will not build this ourselves. With the native OTP support in IPA
it becomes a real business opportunity to provide a native 2FA inside
enterprise across multiple platforms. But please do it open source way
otherwise we would not recommend you ;-)
_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users
My friend agreed to try. He is C# programmer. But the problem that has
low knowledge about kerberos, GSSAPI, and I could not told him what is
wrong with current pgina's ldap plugin.
He does not want to subscribe to freeipa mail-lists, so may be I shall
give him your (Dmitri) e-mail?
He speaks russian :)


List is really the way to develop open source software collaboratively.
This is what we are doing here.
We can agree that the communication about the topic will be prefixed in
such a way that he can create a filter so that he would get only mails
that match the filter.
Would that work?

I am not sure that I would be able to provide all the support. We are a
community here and we have different roles and angles. Working with just
one person would not fly, sorry.


_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at 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/<http://www.redhat.com/carveoutcosts/>



_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at 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/<http://www.redhat.com/carveoutcosts/>








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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140323/3e362d61/attachment.htm>

From dpal at redhat.com  Sun Mar 23 23:45:57 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sun, 23 Mar 2014 19:45:57 -0400
Subject: [Freeipa-users] kerberized vsftpd login problem
In-Reply-To: <CAOscVd+vPYNQZ8PU1ckB9eBSGxJftmU8v5uMPfgUBP1ybi_AMA@mail.gmail.com>
References: <CAOscVd+vPYNQZ8PU1ckB9eBSGxJftmU8v5uMPfgUBP1ybi_AMA@mail.gmail.com>
Message-ID: <532F7235.6070407@redhat.com>

On 03/23/2014 04:01 AM, John Obaterspok wrote:
> Hello,
>
> How do I get vsftpd login to work with an existing ticket?
> I've added ftp as an identity service (ftp/ipaserver.my.lan at MY.LAN)
>
> Is there anything else I need to do to allow ftp login to vsftpd?

What ftp client and server are you using?
Do you know whether they are actually supporting Kerberos?
May be consider other tools like scp instead?


>
>
> -- john
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140323/5410a69b/attachment.htm>

From dpal at redhat.com  Mon Mar 24 00:05:25 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sun, 23 Mar 2014 20:05:25 -0400
Subject: [Freeipa-users] About Windows client
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3C39@001FSN2MPN1-045.001f.mgd2.msft.net>
References: <53052ED3.3030906@redhat.com> <532BAED8.1090705@deus.pro>
	<532C58D0.9050806@redhat.com> <532DC5E2.40106@deus.pro>
	<532DFDE5.30308@redhat.com>
	<9FF6A479E0BA458DA414CBAD739CFD8A@willsheldon.com>
	<532E22EC.1020107@redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6A3C39@001FSN2MPN1-045.001f.mgd2.msft.net>
Message-ID: <532F76C5.2090105@redhat.com>

On 03/23/2014 06:59 PM, Nordgren, Bryce L -FS wrote:
>
> I?m not, in general, in favor of solutions which promiscuously sling 
> Kerberos passwords around the net. JpGina + Kerberos authenticating 
> directly off of IPA would be the way to go, I think.
>
> Presumably Dimitri?s statement about the user being ?foreign? and 
> having limited access to windows services would apply equally well to 
> a user with a SID from a foreign domain in a large Kerberos 
> federation. This, and the uncertainty concerning what type of 
> directory service the foreign KDC is paired with, is probably 
> responsible for keeping Kerberos-based federations small.
>

If you have a SID you can tell Windows what t odo with it and how to 
resolve it to name. If you do not have one you can't do anything if you 
accessing elements of the Windows infra.

> That being said, the collaboration use case (not to mention ?home 
> networks?) is what makes ?foreign? logins interesting. There?s hardly 
> anything in common between two collaboration projects, so it?s hard to 
> define far-reaching policies (i.e., you?re not missing out on much). 
> Most all authorization decisions are delegated out to some project 
> member responsible for the server/asset. Constructing authorization 
> sets having members defined by text based principals makes a certain 
> amount of sense. Hence the LDAP ?member?  attribute in RFC4519.
>

Collaboration can be in different ways. It all depends on the use case. 
It can be OpenID, SAML, Kerberos, etc. There are different technologies 
and they suit better different use cases.

> What would really be cool is the ?inverse? of gluu or openam. Kerberos 
> preauthentication data which allows the KDC to authenticate off of an 
> OpenID Connect, SAML, or LDAP authentication source, caching the 
> provided password and provisioning a Kerberos principal. Future AS 
> exchanges would start out as ?normal? Kerberos. Sort of like migration 
> mode does now. If the KDC could then signal IPA that a new principal 
> was provisioned, IPA could allocate and harmonize an SID and a UID for 
> the principal in the domain.
>

It is already to some extend possible. It is called "constrained 
delegation". The problem is that the gateway that would do such protocol 
conversion would be able to impersonate any user in the Kerberos realm. 
This is not the best but since it is being asked we are looking into it.
There is a project called Ipsilon 
https://git.fedorahosted.org/git/ipsilon that is building the way of 
federating different applications via SAML but in future it might be 
extended to the workflows you are talking about here though I am not 
sure I met these use cases in practice. Can you please share under what 
circumstances such "inversion" would actually be needed?

> Poof. Console logins for Windows (pGina) and Linux (sssd) using IPA 
> backed by your google account.  That just eliminated 98% of the 
> external accounts you would have had to create and manage.
>

Your Google account does not use Kerberos that means that your password 
goes over the wire. The whole point of Kerberos that password does not 
go the wire.
That being said modern Kerberos server and client support OTP 
preauthentication method. This method can be used (abused) to proxy to 
any RADIUS server including the one provided by Google. So if you use 
Google 2FA then it becomes more interesting. You can extually try it now 
with the latest upstream bits. It is not 100% complete but good enough 
to give it a try.
We are also working with MIT to make sure that one can use IPA with 
Kerberos password + HOTP/TOTP token. Then instead of sending the 
authentication to the external entity (RADIUS server) the token code 
would be processed by IPA, but to make is more secure and not send the 
password over the wire together with OTP, KDC and client need to support 
authentication sets. It is a feature that we will be looking to have in 
a 1.14 Kerberos release.

> Food for thought.
>
> Bryce
>
> *From:*freeipa-users-bounces at redhat.com 
> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal
> *Sent:* Saturday, March 22, 2014 5:55 PM
> *To:* Will Sheldon
> *Cc:* freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] About Windows client
>
> On 03/22/2014 05:47 PM, Will Sheldon wrote:
>
> I?d be curious to see how well a solution that combines pGina using 
> RADIUS against some middleware like the Gluu server (www.gluu.org 
> <http://www.gluu.org>)  backed by IPA would work.
>
>
> This is not an interesting scenario. This would would probably work 
> right now but the machine would still not know who the user is because 
> it will not know user SID so he would be foreign and no Windows 
> policies would apply to him. I suspect such user would have no or very 
> limited read only access to Windows resources because all Windows ACLs 
> are based on knowing the user SIDs and SIDs of the groups the user is 
> a member of.
> The value of native IdM integration would be to get user SID and SIDs 
> of the groups from IdM and then get the right kerberos ticket(s) for 
> Windows resources using cross realm kerberos trusts and put these 
> tickets into the right place so that windows system can use them 
> automatically when user navigates to the corresponding resource. 
> Something like this.
>
>
> It strikes me that getting domain federation between IPA and Gluu 
> would tick a lot of boxes as it seems to offer a host of 
> authentication and accounting interfaces including oAuth, SAML, OpenID 
> and of course RADIUS.
>
>
> Kind regards,
>
> Will Sheldon
> +1.778-689-1244
>
> On Saturday, March 22, 2014 at 2:17 PM, Dmitri Pal wrote:
>
>     On 03/22/2014 01:18 PM, Arthur wrote:
>
>         Dmitri Pal wrote:
>
>             On 03/20/2014 11:15 PM, Arthur Faizullin wrote:
>
>                 HI!
>
>                 I've got some thoughts on 4-th point: there is a
>                 http://pgina.org/
>
>                 pgina
>
>                 project, may be them are able to do such thing.
>
>             Yes pgina is one of the options.
>
>             Someone would have to take it and integrate with MIT
>             Kerberos for
>
>             Windows if it is not already doing so.
>
>             But I suspect that it would be more a project in itself
>             that would
>
>             leverage code from MIT and may be pgina to integrate
>             different parts.
>
>             The biggest part figuring out the domain affiliation. I
>             mean the use
>
>             cases like this:
>
>             a) The system is domainless but user authentictaes with
>             user name and
>
>             password against IPA
>
>             b) The system is domainless but user authentictaes with
>             user name and
>
>             OTP against IPA
>
>             c) The system is in an AD domain trusted by IdM domain but
>             user
>
>             authenticates with user name and password against IPA
>             because he is
>
>             in IdM domain.
>
>             d) The system is in an AD domain trusted by IdM domain but
>             user
>
>             authenticates with user name and password against IPA
>             because he is
>
>             in IdM domain.
>
>             More to research. We can help with guidance if someone
>             wants to run
>
>             with it.
>
>             Thanks
>
>             Dmitri
>
>                 20.02.2014 04:23, Dmitri Pal ?????:
>
>                     Hello,
>
>                     I want to summarize our position regarding joining
>                     Windows systems
>
>                     into IPA.
>
>                     1) If you already have AD we recommend using this
>                     system with AD and
>
>                     using trusts between AD and IPA.
>
>                     2) If you do not have AD then use Samba 4 instead
>                     of it. It would be
>
>                     great when Samba 4 grows capability to establish
>                     trusts. Right now it
>
>                     can't but there is an effort going on. If you are
>                     interested - please
>
>                     contribute.
>
>                     3) If neither of the two options work for you you
>                     can configure
>
>                     Windows system to work directly with IPA as
>                     described on the wiki. It
>
>                     is an option of last resort because IPA does not
>                     provide the services
>
>                     windows client expects. If this is good enough for
>                     you, fine by us.
>
>                     4) Build a native Windows client (cred provider)
>                     for IPA using latest
>
>                     Kerberos. IMO this would be really useful if
>                     someone does that because
>
>                     we will not build this ourselves. With the native
>                     OTP support in IPA
>
>                     it becomes a real business opportunity to provide
>                     a native 2FA inside
>
>                     enterprise across multiple platforms. But please
>                     do it open source way
>
>                     otherwise we would not recommend you ;-)
>
>                 _______________________________________________
>
>                 Freeipa-users mailing list
>
>                 Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
>
>                 https://www.redhat.com/mailman/listinfo/freeipa-users
>
>         My friend agreed to try. He is C# programmer. But the problem
>         that has
>
>         low knowledge about kerberos, GSSAPI, and I could not told him
>         what is
>
>         wrong with current pgina's ldap plugin.
>
>         He does not want to subscribe to freeipa mail-lists, so may be
>         I shall
>
>         give him your (Dmitri) e-mail?
>
>         He speaks russian :)
>
>     List is really the way to develop open source software
>     collaboratively.
>
>     This is what we are doing here.
>
>     We can agree that the communication about the topic will be
>     prefixed in
>
>     such a way that he can create a filter so that he would get only
>     mails
>
>     that match the filter.
>
>     Would that work?
>
>     I am not sure that I would be able to provide all the support. We
>     are a
>
>     community here and we have different roles and angles. Working
>     with just
>
>     one person would not fly, sorry.
>
>         _______________________________________________
>
>         Freeipa-users mailing list
>
>         Freeipa-users at redhat.com <mailto:Freeipa-users at 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/ <http://www.redhat.com/carveoutcosts/>
>
>     _______________________________________________
>
>     Freeipa-users mailing list
>
>     Freeipa-users at redhat.com <mailto:Freeipa-users at 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/  <http://www.redhat.com/carveoutcosts/>
>   
>   
>
>
>
>
> 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. 


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140323/dec205d9/attachment.htm>

From Dave.Jones at spilgames.com  Mon Mar 24 09:27:07 2014
From: Dave.Jones at spilgames.com (Dave Jones)
Date: Mon, 24 Mar 2014 09:27:07 +0000
Subject: [Freeipa-users] AD-IPA winsync performance issues
Message-ID: <CF55B8FD.1D41%Dave.Jones@spilgames.com>

Hi,

Installed the ?standard? RHEL6 ipa-server-3.0 packages, tried to set up winsync replication from an Active Directory server which resides in the same network segment as the IPA server.

The IPA server is running in a VM, configured with a single processor, 2G memory.

We?re trying to do a one-way sync from the AD server to the IPA server.   The replication runs but is very slow, syncing only a couple of AD userids to the IPA server per hour.

Has anyone else encountered similar winsync replication performance problems?  Tips or suggestions would be very welcome!

Cheers, Dave


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140324/bd375340/attachment.htm>

From sabinranjit at lftechnology.com  Mon Mar 24 11:17:17 2014
From: sabinranjit at lftechnology.com (Sabin Ranjit)
Date: Mon, 24 Mar 2014 17:02:17 +0545
Subject: [Freeipa-users] error while setting up installing freeipa-client in
 ubuntu 12.04 lts
Message-ID: <5330143D.40806@lftechnology.com>

hi,
since days im trying to install the freeipa-client in ubuntu 12.04. I 
followed the following mail too: 
http://www.redhat.com/archives/freeipa-users/2013-June/msg00091.html

but it didnt work. i followed the following steps:

apt-get build-dep python-lxml
apt-get install python-software-properties
apt-get install software-properties-common

apt-add-repository ppa:freeipa/ppa

apt-add-repository ppa:sssd/updates

apt-get -y install openssh-server freeipa-client sssd

but when i run the ipa-client-install i the error:

" There was a problem importing one of the required Python modules. The
error was:

     /usr/lib/i386-linux-gnu/libgssapi.so.3: symbol 
krb5_ntlm_init_get_challange, version HEIMDAL_KRB5_2.0 not defined in 
file libkrb5.so.26 with link time reference "

how to fix this issue? please provide me proper solution/direction. 
thanks in advance

regards,
sabin

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com



From arthur at deus.pro  Mon Mar 24 13:11:38 2014
From: arthur at deus.pro (Arthur Faizullin)
Date: Mon, 24 Mar 2014 19:11:38 +0600
Subject: [Freeipa-users] sssd off after authconfig update
In-Reply-To: <52BFCBB1.5030302@deus.pro>
References: <52BBC5C0.2060007@deus.pro> <20131226061924.GA9242@fluxcoil.net>
	<52BFCBB1.5030302@deus.pro>
Message-ID: <53302F0A.2050404@deus.pro>

OK! everything work right!
29.12.2013 13:13, Arthur ?????:
> Ok. I'll try to check that. I am away right now.
> 26.12.2013 10:19, Christian Horn ?????:
>> Hi,
>>
>> On Thu, Dec 26, 2013 at 11:59:28AM +0600, Arthur Faizullin wrote:
>>> As I mentioned earlier in my previous topic, when I do:
>>> # authconfig ??--enablemkhomedir ??update
>>> that somehow makes sssd off (disables autostart), so I should do:
>>> # chkconfig sssd on
>>> os: EL6 (CentOS)
>>> ipa version: 3.0 (from repository)
>>> That is not a big problem, but anyway that is not right.
>>> If it is normal way, then it is not mentioned in documentation.
>> Well, when calling authconfig you do not provide any new data
>> (IPA servers or such) which could be used by sssd.  Is the following
>> leaving sssd enabled?
>>
>> # authconfig --enablemkhomedir --enablesssd --update
>>
>>
>> Christian
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users



From rmeggins at redhat.com  Mon Mar 24 15:10:20 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Mon, 24 Mar 2014 09:10:20 -0600
Subject: [Freeipa-users] AD-IPA winsync performance issues
In-Reply-To: <CF55B8FD.1D41%Dave.Jones@spilgames.com>
References: <CF55B8FD.1D41%Dave.Jones@spilgames.com>
Message-ID: <53304ADC.7050803@redhat.com>

On 03/24/2014 03:27 AM, Dave Jones wrote:
> Hi,
>
> Installed the 'standard' RHEL6 ipa-server-3.0 packages, tried to set 
> up winsync replication from an Active Directory server which resides 
> in the same network segment as the IPA server.
>
> The IPA server is running in a VM, configured with a single processor, 
> 2G memory.
>
> We're trying to do a one-way sync from the AD server to the IPA 
> server.   The replication runs but is very slow, syncing only a couple 
> of AD userids to the IPA server per hour.
>
> Has anyone else encountered similar winsync replication performance 
> problems?  Tips or suggestions would be very welcome!

First step is to take a look at the dirsrv errors log - 
/var/log/dirsrv/slapd-YOUR-DOMAIN/errors - to see if there are any 
problems there.

If nothing, next step is to reproduce the problem using the Replication 
logging level - http://port389.org/wiki/FAQ#Troubleshooting - this will 
make it run even more slowly, but will provide a great deal of detailed 
information.

>
> Cheers, Dave
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140324/62e5fbd0/attachment.htm>

From stijn.deweirdt at ugent.be  Mon Mar 24 17:15:01 2014
From: stijn.deweirdt at ugent.be (Stijn De Weirdt)
Date: Mon, 24 Mar 2014 18:15:01 +0100
Subject: [Freeipa-users] change min and max lifetime of random password
Message-ID: <53306815.8070006@ugent.be>

hi all,

i'm trying to limit the minimum and maximum lifetime of passwords (in 
particular the random password when a host is added; but i guess this 
more general).

(i'm using ipa 3.0 from el6 and also looking at 3.3 from rhel7 beta, but 
the relevant code seems the same or at least very similar)

i'm currently adding the host first via the api and then setting the 
random password with host_mod like

api.Command.host_add(u''+host)
api.Command.host_mod(u''+host,random=True)

(for some reason, this is what is needed on 3.0; anyway, that's not my 
issue)

is there a way that i can change it easily somehow afterwards (preferred 
way) or can i create and use a custom pwpolicy class that sets my 
preferred defaults (min 1 minute, max 20 minutes); or do i monkeypatch 
the whole class (assuming that pwpolicy_add is called on the user side, 
not on the server side).

all tips are welcome.

many thanks,

stijn



From dpal at redhat.com  Mon Mar 24 17:28:36 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 24 Mar 2014 13:28:36 -0400
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <53306815.8070006@ugent.be>
References: <53306815.8070006@ugent.be>
Message-ID: <53306B44.60608@redhat.com>

On 03/24/2014 01:15 PM, Stijn De Weirdt wrote:
> hi all,
>
> i'm trying to limit the minimum and maximum lifetime of passwords (in 
> particular the random password when a host is added; but i guess this 
> more general).
>
> (i'm using ipa 3.0 from el6 and also looking at 3.3 from rhel7 beta, 
> but the relevant code seems the same or at least very similar)
>
> i'm currently adding the host first via the api and then setting the 
> random password with host_mod like
>
> api.Command.host_add(u''+host)
> api.Command.host_mod(u''+host,random=True)
>
> (for some reason, this is what is needed on 3.0; anyway, that's not my 
> issue)
>
> is there a way that i can change it easily somehow afterwards 
> (preferred way) or can i create and use a custom pwpolicy class that 
> sets my preferred defaults (min 1 minute, max 20 minutes); or do i 
> monkeypatch the whole class (assuming that pwpolicy_add is called on 
> the user side, not on the server side).
>
> all tips are welcome.


The whole idea of the host passwords is to be added as a part of the 
provisioning workflow so it should be seconds anyways.
We created a "smart proxy" for Foreman (provisioning system) to drive 
host creation. It just landed upstream (first version) last week.
Any chance you can use or reuse some of the code from it in your 
provisioning workflows?

Also can you explain why the expiration time is needed? I can understand 
it being needed if the password is created ahead of time and then not 
used for a period of time but here it is really one flow. You can't 
predict how much it would be 2 sec or 10 seconds but is it really 
important to put a cap on it?

If this is desired the right feature would be to add couple attributes 
to the host entry: creation time and validity interval and set them when 
the password is created. But it is more than a quick fix. You a welcome 
to file and RFE and putt all the details in the ticket.




>
> many thanks,
>
> stijn
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/





From shreerajkarulkar at yahoo.com  Mon Mar 24 18:20:01 2014
From: shreerajkarulkar at yahoo.com (Shree)
Date: Mon, 24 Mar 2014 11:20:01 -0700 (PDT)
Subject: [Freeipa-users] ipa-client-install fails on replica because of
	kinit cannot contact any KDC
In-Reply-To: <532DFCD0.8060907@redhat.com>
References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<52FE7119.1070601@redhat.com>	<1392748186.17597.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<5303B22A.9070709@redhat.com>	<1!	392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com>	!	<53051B35.2050409@redhat.com>	<1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com!	>	<53051F62.40405@redhat.com>	<1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com!	>	<53052E64.3050903@redhat.com>	<1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c!	!	om>	<53061B18.40001@redhat.com>	<1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<53066CD0.5080501@redhat.!	!
	com> <1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com>
	<1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo! !
	.com> <532A9E07.6040604@redhat.com>
	<1395445491.29606.YahooMailNeo@web160105.mail.bf1.yahoo.com>
	<532DFCD0.8060907@redhat.com>
Message-ID: <1395685201.97247.YahooMailNeo@web160104.mail.bf1.yahoo.com>

If you look at the attached logs, you can see it is going to the correct dns server. dig information is also correct. There is something else going on I can figure out what?


?
Shreeraj 
---------------------------------------------------------------------------------------- 

Change is the only Constant !



On Saturday, March 22, 2014 2:12 PM, Dmitri Pal <dpal at redhat.com> wrote:
 
On 03/21/2014 07:44 PM, Shree wrote: 
Hi
>Attaching the install log. It complains about unable to reach
        certain ports, however my tests by using telnet were successful.
        Also to refresh your memory the client should be reaching for
        the replica lda2.mydomain.com and not ldap.mydomain.com which it
        does for the most part but I found a couple of instances of
        ldap.mydomain.com in the log. Let me know what you find. I can't
        believe I migrated over 40 servers and only this one refuses to
        install ipa-client.
>
>
If it is getting to the wrong server then it is either looking at
    the wrong DNS server (see resolve.conf) which is telling it to use
    the wrong IPA server (may be from some old try/POC) or it has some
    explicit entries entered in /etc/hosts.




>
>?
>Shreeraj 
>---------------------------------------------------------------------------------------- 
>
>Change is the only Constant !
>
>
>
>On Thursday, March 20, 2014 4:29 AM, Martin Kosek <mkosek at redhat.com> wrote:
> 
>On 03/19/2014 10:37 PM, Shree wrote: 
>
>> Hello
>> I was able to successfully move all my clients to
                  the replica except on the process I had to upgrade the
                  client to "ipa-client-3.0.0-37.el6.x86_64" and some
                  times run a --uninstall 
>> 
>> . Bit it works for the most part. Have been
                  struggling with one last host with errors like below.
                  I have tested the port connectivity using telnet and
                  netcat commands but the install thinks these ports are
                  blocked? 
>> 
>>? 
>> 
>> 
>> kerberos authentication failed
>> kinit: Cannot contact any KDC for realm
                  'MYDOMAIN.COM' while getting initial credentials
>> 
>> Please make sure the following ports are opened
                  in the firewall settings:
>>? ? ? TCP: 80, 88, 389
>>? ? ? UDP: 88 (at least one of TCP/UDP ports 88
                  has to be open)
>> Also note that following ports are necessary for
                  ipa-client working properly after enrollment:
>>? ? ? TCP: 464
>>? ? ? UDP: 464, 123 (if NTP enabled)
>> Installation failed. Rolling back changes.
>> Disabling client Kerberos and LDAP configurations
>> Redundant SSSD configuration file
                  /etc/sssd/sssd.conf was moved to
                  /etc/sssd/sssd.conf.deleted
>> Restoring client configuration files
>> Client uninstall complete.
>> [root at www /]#
>> 
>> In the /var/log/ipaclient-install.log I also see
                  things like below. I get Autodiscovery failures but I
                  am manually entering things and they have been
                  working.
>> 
>> 2014-03-19T21:13:47Z DEBUG Found:
                  cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
>> 2014-03-19T21:13:47Z DEBUG Discovery result:
                  Success; server=ldap2.mydomain.com,
                  domain=mydomain.com, kdc=ldap.mydomain.com,
                  basedn=dc=mydomain,dc=com
>> 2014-03-19T21:13:47Z DEBUG Validated servers:
                  ldap2.mydomain.com
>> 2014-03-19T21:13:47Z WARNING The failure to use
                  DNS to find your IPA server indicates that your
                  resolv.conf file is not properly configured.
>> 2014-03-19T21:13:47Z INFO Autodiscovery of
                  servers for failover cannot work with this
                  configuration.
>> 2014-03-19T21:13:47Z INFO If you proceed with the
                  installation, services will be configured to always
                  access the discovered server for all operations and
                  will not fail over to other servers in case of
                  failure.
>
>Ok. I would guess you have some DNS issue. But it is
                hard to tell without the
>entire ipaclient-install.log of the failed installation.
>
>Martin 
>
>
>
>


-- 
Thank you,
Dmitri Pal Sr. Engineering Manager for IdM portfolio
Red Hat Inc. -------------------------------
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140324/eca56337/attachment.htm>

From rcritten at redhat.com  Mon Mar 24 19:06:05 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 24 Mar 2014 15:06:05 -0400
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <53306815.8070006@ugent.be>
References: <53306815.8070006@ugent.be>
Message-ID: <5330821D.6030705@redhat.com>

Stijn De Weirdt wrote:
> hi all,
>
> i'm trying to limit the minimum and maximum lifetime of passwords (in
> particular the random password when a host is added; but i guess this
> more general).
>
> (i'm using ipa 3.0 from el6 and also looking at 3.3 from rhel7 beta, but
> the relevant code seems the same or at least very similar)
>
> i'm currently adding the host first via the api and then setting the
> random password with host_mod like
>
> api.Command.host_add(u''+host)
> api.Command.host_mod(u''+host,random=True)
>
> (for some reason, this is what is needed on 3.0; anyway, that's not my
> issue)
>
> is there a way that i can change it easily somehow afterwards (preferred
> way) or can i create and use a custom pwpolicy class that sets my
> preferred defaults (min 1 minute, max 20 minutes); or do i monkeypatch
> the whole class (assuming that pwpolicy_add is called on the user side,
> not on the server side).
>
> all tips are welcome.

You can only specify password policy for User Groups, not host groups, 
so there is no way to do this currently. It also isn't that 
fine-grained. The minimum lifetime is 1 hour, the minimum of the maximum 
lifetime is 1 day.

I don't see why support for Host Groups (and therefore Hosts) can't be 
added. I'm not 100% sure about the tuning for min/max lifetime but it 
should be possible. AFAIR we convert the values from seconds to hours 
and days.

Can you file a ticket at https://fedorahosted.org/freeipa/newticket ?

rob



From stijn.deweirdt at ugent.be  Mon Mar 24 19:44:05 2014
From: stijn.deweirdt at ugent.be (Stijn De Weirdt)
Date: Mon, 24 Mar 2014 20:44:05 +0100
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <53306B44.60608@redhat.com>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
Message-ID: <53308B05.1040009@ugent.be>

hi dmitri,

> The whole idea of the host passwords is to be added as a part of the
> provisioning workflow so it should be seconds anyways.
> We created a "smart proxy" for Foreman (provisioning system) to drive
> host creation. It just landed upstream (first version) last week.
> Any chance you can use or reuse some of the code from it in your
> provisioning workflows?
i'll have a closer looks at the code, but the goal is the same.

>
> Also can you explain why the expiration time is needed? I can understand
> it being needed if the password is created ahead of time and then not
> used for a period of time but here it is really one flow. You can't
> predict how much it would be 2 sec or 10 seconds but is it really
> important to put a cap on it?
yes. we mark hosts for (re)installation and if this does not get 
completed within certain time, something must have gone wrong.
in the meanwhile, we want this security window closed (the OTP password 
would be in a kickstart file, which can't be protected that easily, 
because it still has to work as a kickstart file). 1 day max is way too 
much in this context.

>
> If this is desired the right feature would be to add couple attributes
> to the host entry: creation time and validity interval and set them when
> the password is created. But it is more than a quick fix. You a welcome
> to file and RFE and putt all the details in the ticket.
ok, will do.


stijn
>
>
>
>
>>
>> many thanks,
>>
>> stijn
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>



From stijn.deweirdt at ugent.be  Mon Mar 24 19:46:54 2014
From: stijn.deweirdt at ugent.be (Stijn De Weirdt)
Date: Mon, 24 Mar 2014 20:46:54 +0100
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <5330821D.6030705@redhat.com>
References: <53306815.8070006@ugent.be> <5330821D.6030705@redhat.com>
Message-ID: <53308BAE.4070508@ugent.be>

hi rob,

> You can only specify password policy for User Groups, not host groups,
> so there is no way to do this currently. It also isn't that
> fine-grained. The minimum lifetime is 1 hour, the minimum of the maximum
> lifetime is 1 day.
>
> I don't see why support for Host Groups (and therefore Hosts) can't be
> added. I'm not 100% sure about the tuning for min/max lifetime but it
> should be possible. AFAIR we convert the values from seconds to hours
> and days.
the values are converted and appear to get stored in seconds (looking at 
the code, maybe i misunderstand it).
>
> Can you file a ticket at https://fedorahosted.org/freeipa/newticket ?
will do

stijn
>
> rob
>
>



From abokovoy at redhat.com  Mon Mar 24 19:53:26 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Mon, 24 Mar 2014 21:53:26 +0200
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <53308B05.1040009@ugent.be>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
	<53308B05.1040009@ugent.be>
Message-ID: <20140324195326.GA3487@redhat.com>

On Mon, 24 Mar 2014, Stijn De Weirdt wrote:
>hi dmitri,
>
>>The whole idea of the host passwords is to be added as a part of the
>>provisioning workflow so it should be seconds anyways.
>>We created a "smart proxy" for Foreman (provisioning system) to drive
>>host creation. It just landed upstream (first version) last week.
>>Any chance you can use or reuse some of the code from it in your
>>provisioning workflows?
>i'll have a closer looks at the code, but the goal is the same.
>
>>
>>Also can you explain why the expiration time is needed? I can understand
>>it being needed if the password is created ahead of time and then not
>>used for a period of time but here it is really one flow. You can't
>>predict how much it would be 2 sec or 10 seconds but is it really
>>important to put a cap on it?
>yes. we mark hosts for (re)installation and if this does not get 
>completed within certain time, something must have gone wrong.
>in the meanwhile, we want this security window closed (the OTP 
>password would be in a kickstart file, which can't be protected that 
>easily, because it still has to work as a kickstart file). 1 day max 
>is way too much in this context.
Create user account or group of them, apply needed policy, and use these
users to enroll hosts. This would work already.

-- 
/ Alexander Bokovoy



From stijn.deweirdt at ugent.be  Mon Mar 24 19:54:35 2014
From: stijn.deweirdt at ugent.be (Stijn De Weirdt)
Date: Mon, 24 Mar 2014 20:54:35 +0100
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <53308B05.1040009@ugent.be>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
	<53308B05.1040009@ugent.be>
Message-ID: <53308D7B.6000402@ugent.be>

https://fedorahosted.org/freeipa/ticket/4272

On 03/24/2014 08:44 PM, Stijn De Weirdt wrote:
> hi dmitri,
>
>> The whole idea of the host passwords is to be added as a part of the
>> provisioning workflow so it should be seconds anyways.
>> We created a "smart proxy" for Foreman (provisioning system) to drive
>> host creation. It just landed upstream (first version) last week.
>> Any chance you can use or reuse some of the code from it in your
>> provisioning workflows?
> i'll have a closer looks at the code, but the goal is the same.
>
>>
>> Also can you explain why the expiration time is needed? I can understand
>> it being needed if the password is created ahead of time and then not
>> used for a period of time but here it is really one flow. You can't
>> predict how much it would be 2 sec or 10 seconds but is it really
>> important to put a cap on it?
> yes. we mark hosts for (re)installation and if this does not get
> completed within certain time, something must have gone wrong.
> in the meanwhile, we want this security window closed (the OTP password
> would be in a kickstart file, which can't be protected that easily,
> because it still has to work as a kickstart file). 1 day max is way too
> much in this context.
>
>>
>> If this is desired the right feature would be to add couple attributes
>> to the host entry: creation time and validity interval and set them when
>> the password is created. But it is more than a quick fix. You a welcome
>> to file and RFE and putt all the details in the ticket.
> ok, will do.
>
>
> stijn
>>
>>
>>
>>
>>>
>>> many thanks,
>>>
>>> stijn
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>



From rcritten at redhat.com  Mon Mar 24 19:56:20 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 24 Mar 2014 15:56:20 -0400
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <20140324195326.GA3487@redhat.com>
References: <53306815.8070006@ugent.be>
	<53306B44.60608@redhat.com>	<53308B05.1040009@ugent.be>
	<20140324195326.GA3487@redhat.com>
Message-ID: <53308DE4.80609@redhat.com>

Alexander Bokovoy wrote:
> On Mon, 24 Mar 2014, Stijn De Weirdt wrote:
>> hi dmitri,
>>
>>> The whole idea of the host passwords is to be added as a part of the
>>> provisioning workflow so it should be seconds anyways.
>>> We created a "smart proxy" for Foreman (provisioning system) to drive
>>> host creation. It just landed upstream (first version) last week.
>>> Any chance you can use or reuse some of the code from it in your
>>> provisioning workflows?
>> i'll have a closer looks at the code, but the goal is the same.
>>
>>>
>>> Also can you explain why the expiration time is needed? I can understand
>>> it being needed if the password is created ahead of time and then not
>>> used for a period of time but here it is really one flow. You can't
>>> predict how much it would be 2 sec or 10 seconds but is it really
>>> important to put a cap on it?
>> yes. we mark hosts for (re)installation and if this does not get
>> completed within certain time, something must have gone wrong.
>> in the meanwhile, we want this security window closed (the OTP
>> password would be in a kickstart file, which can't be protected that
>> easily, because it still has to work as a kickstart file). 1 day max
>> is way too much in this context.
> Create user account or group of them, apply needed policy, and use these
> users to enroll hosts. This would work already.
>

No, because then you have to either ship keytabs around during 
provisioning or hardcode that user's password in the kickstart and they 
are already nervous about doing that for the OTP.

rob



From stijn.deweirdt at ugent.be  Mon Mar 24 19:56:39 2014
From: stijn.deweirdt at ugent.be (Stijn De Weirdt)
Date: Mon, 24 Mar 2014 20:56:39 +0100
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <20140324195326.GA3487@redhat.com>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
	<53308B05.1040009@ugent.be> <20140324195326.GA3487@redhat.com>
Message-ID: <53308DF7.50007@ugent.be>

hmmm, seems like overkill to me.
this should ideally be a user per host, and the user should be disabled 
as soon as the host is installed/has the host keytab.

i can continue testing with the 1 day maximum for now. i'll track 
progress/discuusion via the ticket.

stijn

On 03/24/2014 08:53 PM, Alexander Bokovoy wrote:
> On Mon, 24 Mar 2014, Stijn De Weirdt wrote:
>> hi dmitri,
>>
>>> The whole idea of the host passwords is to be added as a part of the
>>> provisioning workflow so it should be seconds anyways.
>>> We created a "smart proxy" for Foreman (provisioning system) to drive
>>> host creation. It just landed upstream (first version) last week.
>>> Any chance you can use or reuse some of the code from it in your
>>> provisioning workflows?
>> i'll have a closer looks at the code, but the goal is the same.
>>
>>>
>>> Also can you explain why the expiration time is needed? I can understand
>>> it being needed if the password is created ahead of time and then not
>>> used for a period of time but here it is really one flow. You can't
>>> predict how much it would be 2 sec or 10 seconds but is it really
>>> important to put a cap on it?
>> yes. we mark hosts for (re)installation and if this does not get
>> completed within certain time, something must have gone wrong.
>> in the meanwhile, we want this security window closed (the OTP
>> password would be in a kickstart file, which can't be protected that
>> easily, because it still has to work as a kickstart file). 1 day max
>> is way too much in this context.
> Create user account or group of them, apply needed policy, and use these
> users to enroll hosts. This would work already.
>



From abokovoy at redhat.com  Mon Mar 24 20:47:22 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Mon, 24 Mar 2014 22:47:22 +0200
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <53308DE4.80609@redhat.com>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
	<53308B05.1040009@ugent.be> <20140324195326.GA3487@redhat.com>
	<53308DE4.80609@redhat.com>
Message-ID: <20140324204722.GB3487@redhat.com>

On Mon, 24 Mar 2014, Rob Crittenden wrote:
>Alexander Bokovoy wrote:
>>On Mon, 24 Mar 2014, Stijn De Weirdt wrote:
>>>hi dmitri,
>>>
>>>>The whole idea of the host passwords is to be added as a part of the
>>>>provisioning workflow so it should be seconds anyways.
>>>>We created a "smart proxy" for Foreman (provisioning system) to drive
>>>>host creation. It just landed upstream (first version) last week.
>>>>Any chance you can use or reuse some of the code from it in your
>>>>provisioning workflows?
>>>i'll have a closer looks at the code, but the goal is the same.
>>>
>>>>
>>>>Also can you explain why the expiration time is needed? I can understand
>>>>it being needed if the password is created ahead of time and then not
>>>>used for a period of time but here it is really one flow. You can't
>>>>predict how much it would be 2 sec or 10 seconds but is it really
>>>>important to put a cap on it?
>>>yes. we mark hosts for (re)installation and if this does not get
>>>completed within certain time, something must have gone wrong.
>>>in the meanwhile, we want this security window closed (the OTP
>>>password would be in a kickstart file, which can't be protected that
>>>easily, because it still has to work as a kickstart file). 1 day max
>>>is way too much in this context.
>>Create user account or group of them, apply needed policy, and use these
>>users to enroll hosts. This would work already.
>>
>
>No, because then you have to either ship keytabs around during 
>provisioning or hardcode that user's password in the kickstart and 
>they are already nervous about doing that for the OTP.
This topic raises regularly on IRC. My suggestion was to create these
one time passwords based on some function of time and host parameters
you can control centrally, for example, IP address. 

For example, using Python expression:

>>> from time import gmtime
>>> addr = "192.168.0.1"
>>> time = lambda t : list(t[:4]) + [(t[4] / 15) * 15]
>>> pw = lambda t, a: ''.join(a.split('.') + map(lambda x: '{:02d}'.format(x), t))
>>> pw(time(gmtime()), addr)
'19216801201403242030'

i.e. a password is an IP address octets concatenated with date and time
rounded down to 15 minutes.

Then ship the function to calculate the OTP as part of kickstart file.
Only a password generated when running install within 15 minutes window of
setting OTP on the server will work if IP address is the same as defined
on the server.

No real password is in the kickstart file, OTP will turn itself off
automatically on enrollment and time has to be within the window of
opportunity.

-- 
/ Alexander Bokovoy



From tjaalton at ubuntu.com  Mon Mar 24 21:31:11 2014
From: tjaalton at ubuntu.com (Timo Aaltonen)
Date: Mon, 24 Mar 2014 23:31:11 +0200
Subject: [Freeipa-users] error while setting up installing
 freeipa-client in ubuntu 12.04 lts
In-Reply-To: <5330143D.40806@lftechnology.com>
References: <5330143D.40806@lftechnology.com>
Message-ID: <5330A41F.1050208@ubuntu.com>

On 24.03.2014 13:17, Sabin Ranjit wrote:
> hi,
> since days im trying to install the freeipa-client in ubuntu 12.04. I
> followed the following mail too:
> http://www.redhat.com/archives/freeipa-users/2013-June/msg00091.html
> 
> but it didnt work. i followed the following steps:
> 
> apt-get build-dep python-lxml
> apt-get install python-software-properties
> apt-get install software-properties-common
> 
> apt-add-repository ppa:freeipa/ppa
> 
> apt-add-repository ppa:sssd/updates
> 
> apt-get -y install openssh-server freeipa-client sssd
> 
> but when i run the ipa-client-install i the error:
> 
> " There was a problem importing one of the required Python modules. The
> error was:
> 
>     /usr/lib/i386-linux-gnu/libgssapi.so.3: symbol
> krb5_ntlm_init_get_challange, version HEIMDAL_KRB5_2.0 not defined in
> file libkrb5.so.26 with link time reference "
> 
> how to fix this issue? please provide me proper solution/direction.
> thanks in advance

get rid of the heimdal bits first, I don't think these work with other
than MIT krb5.


-- 
t



From stijn.deweirdt at ugent.be  Mon Mar 24 21:53:10 2014
From: stijn.deweirdt at ugent.be (Stijn De Weirdt)
Date: Mon, 24 Mar 2014 22:53:10 +0100
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <20140324204722.GB3487@redhat.com>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
	<53308B05.1040009@ugent.be> <20140324195326.GA3487@redhat.com>
	<53308DE4.80609@redhat.com> <20140324204722.GB3487@redhat.com>
Message-ID: <5330A946.7010800@ugent.be>

hi alexander,

>> No, because then you have to either ship keytabs around during
>> provisioning or hardcode that user's password in the kickstart and
>> they are already nervous about doing that for the OTP.
> This topic raises regularly on IRC. My suggestion was to create these
> one time passwords based on some function of time and host parameters
> you can control centrally, for example, IP address.
> For example, using Python expression:
>
>>>> from time import gmtime
>>>> addr = "192.168.0.1"
>>>> time = lambda t : list(t[:4]) + [(t[4] / 15) * 15]
>>>> pw = lambda t, a: ''.join(a.split('.') + map(lambda x:
>>>> '{:02d}'.format(x), t))
>>>> pw(time(gmtime()), addr)
> '19216801201403242030'
>
> i.e. a password is an IP address octets concatenated with date and time
> rounded down to 15 minutes.
>
> Then ship the function to calculate the OTP as part of kickstart file.
> Only a password generated when running install within 15 minutes window of
> setting OTP on the server will work if IP address is the same as defined
> on the server.
>
> No real password is in the kickstart file, OTP will turn itself off
> automatically on enrollment and time has to be within the window of
> opportunity.
>
but the password itself is still valid if the install failed and someone 
else tries to use it.
it's good that you can't guess the password that easily (it's slightly 
better than a fixed string in the kickstart script), might be a good 
candidate if it was coupled with a short enough lifetime. (coupled with 
minimum lifetime as an offset, you might even schedule installations in 
the future).

i don't understand what the ip adds to the password though. the 
ipa-client-install should fail if the ip/hostname doesn't match the data 
in freeipa for that host, right? (the only secret is in the timewindow 
that the admin scheduled, assume that the ipa-client-install enforces 
the ip/hostname)


stijn



From dpal at redhat.com  Mon Mar 24 22:17:42 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 24 Mar 2014 18:17:42 -0400
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <5330A946.7010800@ugent.be>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
	<53308B05.1040009@ugent.be> <20140324195326.GA3487@redhat.com>
	<53308DE4.80609@redhat.com> <20140324204722.GB3487@redhat.com>
	<5330A946.7010800@ugent.be>
Message-ID: <5330AF06.5090506@redhat.com>

On 03/24/2014 05:53 PM, Stijn De Weirdt wrote:
> hi alexander,
>
>>> No, because then you have to either ship keytabs around during
>>> provisioning or hardcode that user's password in the kickstart and
>>> they are already nervous about doing that for the OTP.
>> This topic raises regularly on IRC. My suggestion was to create these
>> one time passwords based on some function of time and host parameters
>> you can control centrally, for example, IP address.
>> For example, using Python expression:
>>
>>>>> from time import gmtime
>>>>> addr = "192.168.0.1"
>>>>> time = lambda t : list(t[:4]) + [(t[4] / 15) * 15]
>>>>> pw = lambda t, a: ''.join(a.split('.') + map(lambda x:
>>>>> '{:02d}'.format(x), t))
>>>>> pw(time(gmtime()), addr)
>> '19216801201403242030'
>>
>> i.e. a password is an IP address octets concatenated with date and time
>> rounded down to 15 minutes.
>>
>> Then ship the function to calculate the OTP as part of kickstart file.
>> Only a password generated when running install within 15 minutes 
>> window of
>> setting OTP on the server will work if IP address is the same as defined
>> on the server.
>>
>> No real password is in the kickstart file, OTP will turn itself off
>> automatically on enrollment and time has to be within the window of
>> opportunity.
>>
> but the password itself is still valid if the install failed and 
> someone else tries to use it.
> it's good that you can't guess the password that easily (it's slightly 
> better than a fixed string in the kickstart script), might be a good 
> candidate if it was coupled with a short enough lifetime. (coupled 
> with minimum lifetime as an offset, you might even schedule 
> installations in the future).
>
> i don't understand what the ip adds to the password though. the 
> ipa-client-install should fail if the ip/hostname doesn't match the 
> data in freeipa for that host, right? (the only secret is in the 
> timewindow that the admin scheduled, assume that the 
> ipa-client-install enforces the ip/hostname)

ipa-client-install does not enforce IP. I do not think we even store IP 
in the host entry. It is stored only in the DNS part, but the IP can be 
updated by the system self registration and that happens only after the 
system enrollment and this IP registration happens using kerberos 
identity of the system.

>
>
> stijn
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/





From siology.io at gmail.com  Tue Mar 25 02:57:09 2014
From: siology.io at gmail.com (siology.io)
Date: Tue, 25 Mar 2014 15:57:09 +1300
Subject: [Freeipa-users] ui timeout
Message-ID: <CAL8of0GHMoNE_ZZ9pomDDgEUCsSr8X8RB7FqMNxT3xpJQRPq2A@mail.gmail.com>

>On 11/27/2013 12:51 AM, Dmitri Pal wrote:
>> On 11/26/2013 05:15 PM, siology.io wrote:>>> for what it's worth, kinit on the command line of the ipa server works>>> just fine, and detects the realm ok.>> >> OK then let us rule out DNS for a moment.>> >> Have you checked the KDC log to see whether the authentication actually>> occurred?>> If kinit works, I suspect it works too but worth checking.>> >> May be there are some problems with memcached after the form based>> authentication to cache the authentication. KDC log would show whether>> the kinit and follow up service ticket request for LDAP access actually>> occurred.>>>This is a good suggestion. Please see if ipa_memcached daemon is running, there>was a glitch in one of the upgrades in the past which did not configure it>correctly.  If it is not, I can advise how to fix it.>Martin

ok. this problem is like a zombie. it just keeps coming !

I *think* i got this working back in november, but i'm not 100% sure
because on discovering the issue is still there now on at least one of
my replicas and then going to turn on debugging mode, i found it was
already on !

To answer your query from back then though; yes memcached is running
and seems to be ok. i tried restarting it (as part of an ipa restart)
and i still see timeouts on login after entering my authentication
details.

Oddly though, going back to the head of this thread i claimed i was
having the issues on my master and replica IPA servers. That isn't the
case now at least - its just on the replica, so i must have fixed
it.... somehow ?! or it disappeared ? Annoying as hell though, either
way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140325/39661c9b/attachment.htm>

From bnordgren at fs.fed.us  Tue Mar 25 04:17:26 2014
From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS)
Date: Tue, 25 Mar 2014 04:17:26 +0000
Subject: [Freeipa-users] External Collaboration Domains
Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net>


>Collaboration can be in different ways. It all depends on the use case. It can be OpenID, SAML, Kerberos, etc. There are different technologies and they suit better different use cases.

>Can you please share under what circumstances such "inversion" would actually be needed?

Console logins in a domain specifically created for collaboration with external entities. Expect that there is a one-way trust from the organization's "internal" domain (providing users) to the collaboration domain (providing services). The collaboration domain would host services and devices necessary for the execution of various projects. Project members are NOT from a small set of closely knit organizations, where it is feasible to establish cross domain trusts. As this is a large organization, many projects are starting, in-progress, and ending at all times. New projects do not necessarily require trusts to the same set of organizations as existing or finishing projects. Services may be web services, shared filesystems, standalone processing machines, and high performance computing assets. The services have service or host principals in the collaboration domain's domain controller. From an IT perspective, this is similar to interacting with customers, except the customers deploy and/or access stuff on your network.

Much of the horsepower in this domain will probably be some variant of Linux. There are instances of high-horsepower Windows and Mac devices/clusters, but they are not common.  Source code control, issue trackers, networked filesystems, datafiles, and metadata development webapps have a presence here. Esoteric scientific equipment may be connected to the network, but will probably not be Kerberized (i.e., Gas Chromatograph Mass Spectrometer). Terminals may be Mac, Windows, Linux, Android or iOS and may belong to guests. This is just in my building in Montana. Nationwide the situation is likely to be more chaotic. The big reason everything is here: it either violates enterprise policy or needs to be accessible by external users (which violates enterprise policy).

System administration responsibilities in this collaboration domain are largely distributed to the system owners and not centralized in the IT organization. There is no or little commonality in purpose, intent, authorization roles, characteristics, or business case for the systems, inter-project. Similarities may exist between multiple resources associated with a common project, or projects with a common theme. Many semi-autonomous fiefdoms ensue, most with a limited lifetime, composed of people none of whom want to manage user accounts, and none of whom want new passwords. Few want to monkey with security at all.

If such a domain were to exclusively contain web services, one wouldn't need  a domain controller at all. Something like gluu or openam would suffice. But I need to share files and support console access in addition to web access. Using the same credentials. Which I don't want to manage.

>Your Google account does not use Kerberos that means that your password goes over the wire. The whole point of Kerberos that password does not go the wire.

Me thinks your flow is reversed. Posit an HTTP version of the AS exchange with the KDC, where users who are not present in the domain controller obtain TGTs for the local domain via their browser. The user doesn't provide a password to the KDC, nor does it provide a signed public key, but they do demonstrate they are recognized by a foreign IdP via a browser workflow defined by (SAML|OpenID Connect|OpenID|other). Conceptually, this is no different than PKINIT, in that the KDC puts its trust in (a presumably configurable) list of identity providers utilizing a varied patchwork of HTTP identity technologies. When the KDC's "external identity" webpage is satisfied that the remote IdP is happy with the user's  identity, it can return a TGT to the browser using a TBD encoding which the browser stores in the local ticket cache. The user in control of the browser session can then ssh into a machine via gssapi, or mount an NFSv4 filesystem, or connect to any of the realm's webservices using gssapi/spnego. Of course, the web services could also allow the native use of the foreign identity technologies.

If the KDC is bundled as part of a larger directory solution like IPA/AD, then some "extra overhead" (SID/UID) needs to be synthesized for use within the domain when the identity is first encountered. This is not more work than offering your realm's services to Kerberos users (from IPA? AD? Kerberos+LDAP? Just Kerberos?) who arrive from a foreign realm (via PKINIT or trust) when you have no way to access this non-kerberos information in the user's home realm. Letting the local domain controller do it guarantees it's harmonized within the realm.

There has to be a standardized method for encoding these foreign user principal names and realms. You want subsequent logins to use the same principal (and same SID/UID). You also want the principal name and realm to be the same no matter how it shows up in your realm (e.g., via direct login or via a trust). This may involve the creation of zero or more new Kerberos nametypes.

This doesn't send passwords over the wire for users defined in the KDC. It also doesn't stop the alien technologies (non-Kerberos) from sending their own passwords over the wire. However, it does drastically reduce the number of accounts you have to create and manage in an external/collaboration domain. Your collaborators are happier because they don't have another password. It also gives you a central point of control over just exactly which foreign IdPs are accepted. The user's identities are exactly as trustworthy as they are in their native web context (no more no less). The many and varied machines in your domain don't need to worry about how to interact with a plethora of identity technologies. They just need to be kerberized and defer all authentication worries to the collaboration domain's KDC.

Maybe this could be done by adding an external login page to IPA's management web interface, which coordinates the necessary actions between the HTTP authentication workflow, LDAP, the DogTag CA, PKINIT to the KDC, and which returns the TGT to the browser (or displays an error). There are many pieces involved, but most are already gathered together. Aside from browser support of this mechanism, this does not seem like an overly invasive solution to any particular component.

In any case, IPA would need to synthesize "extra" data (UID/SID) for this PKINIT/foreign-user connection, as it should be doing now for all non-anonymous PKINIT connections. :) May I ask how IPA handles this case now? Googling shows me that there is PKINIT support, but I can't tell whether this includes setting user attributes...

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.



From arthur at deus.pro  Tue Mar 25 04:19:22 2014
From: arthur at deus.pro (Arthur Faizullin)
Date: Tue, 25 Mar 2014 10:19:22 +0600
Subject: [Freeipa-users] sssd off after authconfig update
In-Reply-To: <53302F0A.2050404@deus.pro>
References: <52BBC5C0.2060007@deus.pro>
	<20131226061924.GA9242@fluxcoil.net>	<52BFCBB1.5030302@deus.pro>
	<53302F0A.2050404@deus.pro>
Message-ID: <533103CA.20702@deus.pro>

FIX! Sssd keeps running after I've done this command, but anyway I have
to do:
# chkconfig sssd on
or it will not start at next boot.

24.03.2014 19:11, Arthur Faizullin ?????:
> OK! everything work right!
> 29.12.2013 13:13, Arthur ?????:
>> Ok. I'll try to check that. I am away right now.
>> 26.12.2013 10:19, Christian Horn ?????:
>>> Hi,
>>>
>>> On Thu, Dec 26, 2013 at 11:59:28AM +0600, Arthur Faizullin wrote:
>>>> As I mentioned earlier in my previous topic, when I do:
>>>> # authconfig ??--enablemkhomedir ??update
>>>> that somehow makes sssd off (disables autostart), so I should do:
>>>> # chkconfig sssd on
>>>> os: EL6 (CentOS)
>>>> ipa version: 3.0 (from repository)
>>>> That is not a big problem, but anyway that is not right.
>>>> If it is normal way, then it is not mentioned in documentation.
>>> Well, when calling authconfig you do not provide any new data
>>> (IPA servers or such) which could be used by sssd.  Is the following
>>> leaving sssd enabled?
>>>
>>> # authconfig --enablemkhomedir --enablesssd --update
>>>
>>>
>>> Christian
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users



From abokovoy at redhat.com  Tue Mar 25 06:32:32 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Tue, 25 Mar 2014 08:32:32 +0200
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <5330A946.7010800@ugent.be>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
	<53308B05.1040009@ugent.be> <20140324195326.GA3487@redhat.com>
	<53308DE4.80609@redhat.com> <20140324204722.GB3487@redhat.com>
	<5330A946.7010800@ugent.be>
Message-ID: <20140325063232.GC3487@redhat.com>

On Mon, 24 Mar 2014, Stijn De Weirdt wrote:
>hi alexander,
>
>>>No, because then you have to either ship keytabs around during
>>>provisioning or hardcode that user's password in the kickstart and
>>>they are already nervous about doing that for the OTP.
>>This topic raises regularly on IRC. My suggestion was to create these
>>one time passwords based on some function of time and host parameters
>>you can control centrally, for example, IP address.
>>For example, using Python expression:
>>
>>>>>from time import gmtime
>>>>>addr = "192.168.0.1"
>>>>>time = lambda t : list(t[:4]) + [(t[4] / 15) * 15]
>>>>>pw = lambda t, a: ''.join(a.split('.') + map(lambda x:
>>>>>'{:02d}'.format(x), t))
>>>>>pw(time(gmtime()), addr)
>>'19216801201403242030'
>>
>>i.e. a password is an IP address octets concatenated with date and time
>>rounded down to 15 minutes.
>>
>>Then ship the function to calculate the OTP as part of kickstart file.
>>Only a password generated when running install within 15 minutes window of
>>setting OTP on the server will work if IP address is the same as defined
>>on the server.
>>
>>No real password is in the kickstart file, OTP will turn itself off
>>automatically on enrollment and time has to be within the window of
>>opportunity.
>>
>but the password itself is still valid if the install failed and 
>someone else tries to use it.
Right. Nobody actually prevents you from running a cron job on the
server side to lock down these passwords if they were not used up in
a fixed amount of time.

>it's good that you can't guess the password that easily (it's 
>slightly better than a fixed string in the kickstart script), might 
>be a good candidate if it was coupled with a short enough lifetime. 
>(coupled with minimum lifetime as an offset, you might even schedule 
>installations in the future).
>i don't understand what the ip adds to the password though. the 
>ipa-client-install should fail if the ip/hostname doesn't match the 
>data in freeipa for that host, right? (the only secret is in the 
>timewindow that the admin scheduled, assume that the 
>ipa-client-install enforces the ip/hostname)
In a typical environment you have central control over those types of
data associated with the spawned machines, like MAC addresses or IP
addresses.

If the password is including bits that are forced to the host by a
central authority, it makes harder to get rogue clients to re-use the
same template for other combinations of MAC/IP address. They would need
to know exact IP or MAC address of the machine they want to impersonate.
You can take other unique parameters into account.

You need to think of what is truly unique to your clients but there
still will be question of trust to the client who attempts to
authenticate. This trust should be verified on multiple levels, a
password to enroll the client is just one of them.
-- 
/ Alexander Bokovoy



From abokovoy at redhat.com  Tue Mar 25 07:12:08 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Tue, 25 Mar 2014 09:12:08 +0200
Subject: [Freeipa-users] External Collaboration Domains
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net>
References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net>
Message-ID: <20140325071208.GD3487@redhat.com>

On Tue, 25 Mar 2014, Nordgren, Bryce L -FS wrote:
>
>>Collaboration can be in different ways. It all depends on the use case. It can be OpenID, SAML, Kerberos, etc. There are different technologies and they suit better different use cases.
>
>>Can you please share under what circumstances such "inversion" would actually be needed?
>
>Console logins in a domain specifically created for collaboration with
>external entities. Expect that there is a one-way trust from the
>organization's "internal" domain (providing users) to the collaboration
>domain (providing services). The collaboration domain would host
>services and devices necessary for the execution of various projects.
>Project members are NOT from a small set of closely knit organizations,
>where it is feasible to establish cross domain trusts. As this is a
>large organization, many projects are starting, in-progress, and ending
>at all times. New projects do not necessarily require trusts to the
>same set of organizations as existing or finishing projects. Services
>may be web services, shared filesystems, standalone processing
>machines, and high performance computing assets. The services have
>service or host principals in the collaboration domain's domain
>controller. From an IT perspective, this is similar to interacting with
>customers, except the customer!  s deploy and/or access stuff on your
>network.
>
>Much of the horsepower in this domain will probably be some variant of
>Linux. There are instances of high-horsepower Windows and Mac
>devices/clusters, but they are not common.  Source code control, issue
>trackers, networked filesystems, datafiles, and metadata development
>webapps have a presence here. Esoteric scientific equipment may be
>connected to the network, but will probably not be Kerberized (i.e.,
>Gas Chromatograph Mass Spectrometer). Terminals may be Mac, Windows,
>Linux, Android or iOS and may belong to guests. This is just in my
>building in Montana. Nationwide the situation is likely to be more
>chaotic. The big reason everything is here: it either violates
>enterprise policy or needs to be accessible by external users (which
>violates enterprise policy).
to sum up above, you'd need POSIX identities for users and groups coming
from nowhere to be created and associated with their external
credentials.

This is not really different from what many web sites do which accept
3rd-party authentication promise but then create own accounts once
you've passed through OAuth2, for example.

So you would have an IPA domain where you would have a portal that
creates users after they successfully authenticated to a third-party you
trust. FreeIPA 4.0 will have support for external RADIUS server
authentication as a token that can be associated with a user. Note that
this user has to be created first but overall this is doable.

However, consequent logins through console would assume you are actually
using your third-party password or two-factor auth directly. This means
no previously issued OAuth2 assurance can be of any help here as you are
not dealing with a browser here that obtained the assurance. May be at
this point it would make sense to actually switch the user to some
generated password or 2FA unique to the collaboration domain?


>If such a domain were to exclusively contain web services, one wouldn't
>need  a domain controller at all. Something like gluu or openam would
>suffice. But I need to share files and support console access in
>addition to web access. Using the same credentials. Which I don't want
>to manage.
For web services exclusively, a scheme with external RADIUS provided
token is OK.

>If the KDC is bundled as part of a larger directory solution like
>IPA/AD, then some "extra overhead" (SID/UID) needs to be synthesized
>for use within the domain when the identity is first encountered. This
>is not more work than offering your realm's services to Kerberos users
>(from IPA? AD? Kerberos+LDAP? Just Kerberos?) who arrive from a foreign
>realm (via PKINIT or trust) when you have no way to access this
>non-kerberos information in the user's home realm. Letting the local
>domain controller do it guarantees it's harmonized within the realm.
See above.

>There has to be a standardized method for encoding these foreign user
>principal names and realms. You want subsequent logins to use the same
>principal (and same SID/UID). You also want the principal name and
>realm to be the same no matter how it shows up in your realm (e.g., via
>direct login or via a trust). This may involve the creation of zero or
>more new Kerberos nametypes.
I don't think you really need to invent something here. Authenticate
over some third-party source at sign-up, ask user to accept terms of
use, create IPA user for the user, associate external token with the IPA
user based on already obtained OAuth2 token user gave you when signed
up. Keep external identity in the IPA user account:

ipa user-add <user> --radius=<radiusproxy-name> \
                     --radius-username=<external-name> \
                     --user-auth-type={password,radius}

then set password that user will be using for non-web services. It would
be usable for web services too, though, but that is a detail.

On consequent logons to the web service use the negotiated OAuth2 token
to authenticate to the RADIUS server that will use it to communicate
with a third-party.


>Maybe this could be done by adding an external login page to IPA's
>management web interface, which coordinates the necessary actions
>between the HTTP authentication workflow, LDAP, the DogTag CA, PKINIT
>to the KDC, and which returns the TGT to the browser (or displays an
>error). There are many pieces involved, but most are already gathered
>together. Aside from browser support of this mechanism, this does not
>seem like an overly invasive solution to any particular component.
What we see is that increasingly people want to hide IPA web UI and
integrate such functionality in their own tools/interfaces. So we can
provide something like that but it would be hardly usable to others due
to difference in the technologies used to build web UIs.

Having an article that shows how to do it with one of possible tools
would be good, yes.

>In any case, IPA would need to synthesize "extra" data (UID/SID) for
>this PKINIT/foreign-user connection, as it should be doing now for all
>non-anonymous PKINIT connections. :) May I ask how IPA handles this
>case now? Googling shows me that there is PKINIT support, but I can't
>tell whether this includes setting user attributes...
See above, read http://www.freeipa.org/page/V3/OTP

-- 
/ Alexander Bokovoy



From stijn.deweirdt at ugent.be  Tue Mar 25 07:29:42 2014
From: stijn.deweirdt at ugent.be (Stijn De Weirdt)
Date: Tue, 25 Mar 2014 08:29:42 +0100
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <20140325063232.GC3487@redhat.com>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
	<53308B05.1040009@ugent.be> <20140324195326.GA3487@redhat.com>
	<53308DE4.80609@redhat.com> <20140324204722.GB3487@redhat.com>
	<5330A946.7010800@ugent.be> <20140325063232.GC3487@redhat.com>
Message-ID: <53313066.4080001@ugent.be>

hi alexander,

>>> No real password is in the kickstart file, OTP will turn itself off
>>> automatically on enrollment and time has to be within the window of
>>> opportunity.
>>>
>> but the password itself is still valid if the install failed and
>> someone else tries to use it.
> Right. Nobody actually prevents you from running a cron job on the
> server side to lock down these passwords if they were not used up in
> a fixed amount of time.
hence my request for password expiration.
ity would be good anyway to have a script that checks all hosts that 
have not enrolled yet how old the issued password is (even after 
expiration). very useful to spot the state of ongoing deployments and to 
spot problems. how can one obtain the creation time of the password? 
fetch the timestamp from LDAP or is there a nice ipa API for it?

>
>> it's good that you can't guess the password that easily (it's slightly
>> better than a fixed string in the kickstart script), might be a good
>> candidate if it was coupled with a short enough lifetime. (coupled
>> with minimum lifetime as an offset, you might even schedule
>> installations in the future).
>> i don't understand what the ip adds to the password though. the
>> ipa-client-install should fail if the ip/hostname doesn't match the
>> data in freeipa for that host, right? (the only secret is in the
>> timewindow that the admin scheduled, assume that the
>> ipa-client-install enforces the ip/hostname)
> In a typical environment you have central control over those types of
> data associated with the spawned machines, like MAC addresses or IP
> addresses.
>
> If the password is including bits that are forced to the host by a
> central authority, it makes harder to get rogue clients to re-use the
> same template for other combinations of MAC/IP address. They would need
> to know exact IP or MAC address of the machine they want to impersonate.
> You can take other unique parameters into account.
>
> You need to think of what is truly unique to your clients but there
> still will be question of trust to the client who attempts to
> authenticate. This trust should be verified on multiple levels, a
> password to enroll the client is just one of them.
as dmitry pointed out in previous mail, i was mistaken that IPA has 
tight coupling by default between hostname and IP (the DNS is optional).

anyway, thanks again for the feedback.

stijn



From abokovoy at redhat.com  Tue Mar 25 07:43:41 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Tue, 25 Mar 2014 09:43:41 +0200
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <53313066.4080001@ugent.be>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
	<53308B05.1040009@ugent.be> <20140324195326.GA3487@redhat.com>
	<53308DE4.80609@redhat.com> <20140324204722.GB3487@redhat.com>
	<5330A946.7010800@ugent.be> <20140325063232.GC3487@redhat.com>
	<53313066.4080001@ugent.be>
Message-ID: <20140325074341.GE3487@redhat.com>

On Tue, 25 Mar 2014, Stijn De Weirdt wrote:
>hi alexander,
>
>>>>No real password is in the kickstart file, OTP will turn itself off
>>>>automatically on enrollment and time has to be within the window of
>>>>opportunity.
>>>>
>>>but the password itself is still valid if the install failed and
>>>someone else tries to use it.
>>Right. Nobody actually prevents you from running a cron job on the
>>server side to lock down these passwords if they were not used up in
>>a fixed amount of time.
>hence my request for password expiration.
>ity would be good anyway to have a script that checks all hosts that 
>have not enrolled yet how old the issued password is (even after 
>expiration). very useful to spot the state of ongoing deployments and 
>to spot problems. how can one obtain the creation time of the 
>password? fetch the timestamp from LDAP or is there a nice ipa API 
>for it?
Since host object is a Kerberos principal, it has krbLastSuccessfulAuth
and krbLastPwdChange attributes.

ipa host-show host.name --all --raw

will give you their values.

# ipa host-show `hostname` --all --raw |grep krbLast
   krbLastPwdChange: 20140213123016Z
   krbLastSuccessfulAuth: 20140325073031Z


-- 
/ Alexander Bokovoy



From mkosek at redhat.com  Tue Mar 25 07:50:20 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Tue, 25 Mar 2014 08:50:20 +0100
Subject: [Freeipa-users] ipa-client-install fails on replica because of
 kinit cannot contact any KDC
In-Reply-To: <1395685201.97247.YahooMailNeo@web160104.mail.bf1.yahoo.com>
References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<5303B22A.9070709@redhat.com>	<1!	392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com>	!	<53051B35.2050409@redhat.com>	<1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com!	>	<53051F62.40405@redhat.com>	<1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com!	>	<53052E64.3050903@redhat.com>	<1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c!	!	om>	<53061B18.40001@redhat.com>	<1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<53066CD0.5080501@redhat.!	!
	com> <1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com>
	<1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo! !
	.com> <532A9E07.6040604@redhat.com>
	<1395445491.29606.YahooMailNeo@web160105.mail.bf1.yahoo.com>
	<532DFCD0.8060907@redhat.com>
	<1395685201.97247.YahooMailNeo@web160104.mail.bf1.yahoo.com>
Message-ID: <5331353C.9030603@redhat.com>

It searching for ldap.mydomain.com because you still have DNS SRV record
_kerberos._udp.mydomain.com. pointing to it. I would start there.

As for the failure, I would check that the generated /etc/krb5.conf is correct:

~~~~~~~~~
includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
  default_realm = MYDOMAIN.COM
  dns_lookup_realm = false
  dns_lookup_kdc = false
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes

[realms]
  MYDOMAIN.COM = {
    kdc = ldap2.mydomain.com:88
    master_kdc = ldap2.mydomain.com:88
    admin_server = ldap2.mydomain.com:749
    default_domain = mydomain.com
    pkinit_anchors = FILE:/etc/ipa/ca.crt
  }

[domain_realm]
  .mydomain.com = MYDOMAIN.COM
  mydomain.com = MYDOMAIN.COM
  .mydomain.com = MYDOMAIN.COM
  mydomain.com = MYDOMAIN.COM
~~~~~~~~

(I assume you did more anonymizing that expected, ipa-client-install does not
generate 2 domain_realm mappings unless client domain is different that server
domain (e.g. client.other.mydomain.com and server.mydomain.com)).

What I would do in your place is to:
1) Backup your current /etc/krb5.conf
2) Replace it with the krb5.conf which was generated during ipa-client-install
(you can find non-anonymized version in ipaclient-install.log)
3) Try to kinit: kinit skarulkar at MYDOMAIN.COM

Then it will be easier to troubleshoot. To get more information what kinit
actually does, try enabling a trace:

# KRB5_TRACE=/dev/stdout kinit skarulkar at MYDOMAIN.COM

You will be then able to see if it really connects to right IP address which
would enable you to debug further.

Martin

On 03/24/2014 07:20 PM, Shree wrote:
> If you look at the attached logs, you can see it is going to the correct dns server. dig information is also correct. There is something else going on I can figure out what?
> 
> 
>  
> Shreeraj 
> ---------------------------------------------------------------------------------------- 
> 
> Change is the only Constant !
> 
> 
> 
> On Saturday, March 22, 2014 2:12 PM, Dmitri Pal <dpal at redhat.com> wrote:
>  
> On 03/21/2014 07:44 PM, Shree wrote: 
> Hi
>> Attaching the install log. It complains about unable to reach
>         certain ports, however my tests by using telnet were successful.
>         Also to refresh your memory the client should be reaching for
>         the replica lda2.mydomain.com and not ldap.mydomain.com which it
>         does for the most part but I found a couple of instances of
>         ldap.mydomain.com in the log. Let me know what you find. I can't
>         believe I migrated over 40 servers and only this one refuses to
>         install ipa-client.
>>
>>
> If it is getting to the wrong server then it is either looking at
>     the wrong DNS server (see resolve.conf) which is telling it to use
>     the wrong IPA server (may be from some old try/POC) or it has some
>     explicit entries entered in /etc/hosts.
> 
> 
> 
> 
>>
>>  
>> Shreeraj 
>> ---------------------------------------------------------------------------------------- 
>>
>> Change is the only Constant !
>>
>>
>>
>> On Thursday, March 20, 2014 4:29 AM, Martin Kosek <mkosek at redhat.com> wrote:
>>
>> On 03/19/2014 10:37 PM, Shree wrote: 
>>
>>> Hello
>>> I was able to successfully move all my clients to
>                   the replica except on the process I had to upgrade the
>                   client to "ipa-client-3.0.0-37.el6.x86_64" and some
>                   times run a --uninstall 
>>>
>>> . Bit it works for the most part. Have been
>                   struggling with one last host with errors like below.
>                   I have tested the port connectivity using telnet and
>                   netcat commands but the install thinks these ports are
>                   blocked? 
>>>
>>>   
>>>
>>>
>>> kerberos authentication failed
>>> kinit: Cannot contact any KDC for realm
>                   'MYDOMAIN.COM' while getting initial credentials
>>>
>>> Please make sure the following ports are opened
>                   in the firewall settings:
>>>       TCP: 80, 88, 389
>>>       UDP: 88 (at least one of TCP/UDP ports 88
>                   has to be open)
>>> Also note that following ports are necessary for
>                   ipa-client working properly after enrollment:
>>>       TCP: 464
>>>       UDP: 464, 123 (if NTP enabled)
>>> Installation failed. Rolling back changes.
>>> Disabling client Kerberos and LDAP configurations
>>> Redundant SSSD configuration file
>                   /etc/sssd/sssd.conf was moved to
>                   /etc/sssd/sssd.conf.deleted
>>> Restoring client configuration files
>>> Client uninstall complete.
>>> [root at www /]#
>>>
>>> In the /var/log/ipaclient-install.log I also see
>                   things like below. I get Autodiscovery failures but I
>                   am manually entering things and they have been
>                   working.
>>>
>>> 2014-03-19T21:13:47Z DEBUG Found:
>                   cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
>>> 2014-03-19T21:13:47Z DEBUG Discovery result:
>                   Success; server=ldap2.mydomain.com,
>                   domain=mydomain.com, kdc=ldap.mydomain.com,
>                   basedn=dc=mydomain,dc=com
>>> 2014-03-19T21:13:47Z DEBUG Validated servers:
>                   ldap2.mydomain.com
>>> 2014-03-19T21:13:47Z WARNING The failure to use
>                   DNS to find your IPA server indicates that your
>                   resolv.conf file is not properly configured.
>>> 2014-03-19T21:13:47Z INFO Autodiscovery of
>                   servers for failover cannot work with this
>                   configuration.
>>> 2014-03-19T21:13:47Z INFO If you proceed with the
>                   installation, services will be configured to always
>                   access the discovered server for all operations and
>                   will not fail over to other servers in case of
>                   failure.
>>
>> Ok. I would guess you have some DNS issue. But it is
>                 hard to tell without the
>> entire ipaclient-install.log of the failed installation.
>>
>> Martin 
>>
>>
>>
>>
> 
> 



From barrykfl at gmail.com  Tue Mar 25 09:27:40 2014
From: barrykfl at gmail.com (barrykfl at gmail.com)
Date: Tue, 25 Mar 2014 17:27:40 +0800
Subject: [Freeipa-users] using 3rd party cert not self sign cert in ipa
Message-ID: <CAELz9dvXNNquYH3Mo3-TyAzs+QOh6KtKgghq129SRWXQFb2bWw@mail.gmail.com>

Dear all:

whe install it already genrate a self sign cert  called mydomain.com . and
run ca service.  now i want to check if it ok to install 3rd party
replcacing ..so

to httpd my ldap it will be https: my co domain (official cert ). and
replcabelow.

/etc/ipa/ca.crt
/usr/share/ipa/html/ca.crt

Is it possible ? or any side effect on the infrsturture if chane the cert,.
http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP

I saw some info on web ...but i now already launch and many users
connected. if i replaced the cert will it make the ldap invalid for
exisiting users.???


Regafs

Barry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140325/eaa530f0/attachment.htm>

From jcholast at redhat.com  Tue Mar 25 10:22:43 2014
From: jcholast at redhat.com (Jan Cholasta)
Date: Tue, 25 Mar 2014 11:22:43 +0100
Subject: [Freeipa-users] using 3rd party cert not self sign cert in ipa
In-Reply-To: <CAELz9dvXNNquYH3Mo3-TyAzs+QOh6KtKgghq129SRWXQFb2bWw@mail.gmail.com>
References: <CAELz9dvXNNquYH3Mo3-TyAzs+QOh6KtKgghq129SRWXQFb2bWw@mail.gmail.com>
Message-ID: <533158F3.1050808@redhat.com>

On 25.3.2014 10:27, barrykfl at gmail.com wrote:
> Dear all:
> whe install it already genrate a self sign cert  called mydomain.com
> <http://mydomain.com> . and run ca service.  now i want to check if it
> ok to install 3rd party replcacing ..so
> to httpd my ldap it will be https: my co domain (official cert ). and
> replcabelow.
> /etc/ipa/ca.crt
> /usr/share/ipa/html/ca.crt

You don't have to touch these files if you only want to install your own 
certificates for HTTP and LDAP.

> Is it possible ? or any side effect on the infrsturture if chane the cert,.
> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
> I saw some info on web ...but i now already launch and many users
> connected. if i replaced the cert will it make the ldap invalid for
> exisiting users.???

You must make sure the CA certificate that signed your HTTP and LDAP 
certificates is trusted on your client systems. If you do that, 
everything should work fine.

> Regafs
> Barry

Honza

-- 
Jan Cholasta



From jpazdziora at redhat.com  Tue Mar 25 13:14:31 2014
From: jpazdziora at redhat.com (Jan Pazdziora)
Date: Tue, 25 Mar 2014 14:14:31 +0100
Subject: [Freeipa-users] HBAC for mod_auth_kerb (and give karma to Fedora 20
	package)
Message-ID: <20140325131431.GY3872@redhat.com>


Hello,

so you've read about the web application authentication and host-based
access control but never tried it and now you wonder how the HBAC with
Kerberos actually works in the web context ...

Why not try to set it up and see for yourself? ... And give karma
to 
	https://admin.fedoraproject.org/updates/mod_authnz_pam-0.9-1.fc20

to get

	http://fedorapeople.org/cgit/adelton/public_git/mod_authnz_pam.git/commit/?id=3ddf467cbadba121e878699da74b26351a31e547

in if you find it satisfactory.

You can use

	http://www.freeipa.org/page/Web_App_Authentication

as the guidelines but you can also try to set things up completely
without the guides, just using mod_authnz_pam's documentation at

	http://www.adelton.com/apache/mod_authnz_pam/

And comments and help with the karma would be appreciated.

-- 
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat



From sakodak at gmail.com  Tue Mar 25 18:22:33 2014
From: sakodak at gmail.com (KodaK)
Date: Tue, 25 Mar 2014 13:22:33 -0500
Subject: [Freeipa-users] AD trusts & HBACs & such
Message-ID: <CAA9J0ZFWtBR8VfUHYxy27HPU_rW94c04e8GXkvWs0TR9nH0pMg@mail.gmail.com>

I've been working with support on how to set up HBAC and sudo rules with AD
users.

>From what they've described I can only manage them on an aggregate level
using an external group.

For example, I can define an hbac rule, but that hbac rule will be vaild
for *all* AD users in the external group that was created to handle them.

Am I missing something?  If that's the case then this isn't flexible enough
for our needs.  I have to be able to specify rules based on individual
accounts.

It seems like there might be a work-around by using multiple external
groups and having each AD user in their own external group, but that would
be really cumbersome (if it's even possible.)

Do I have any other options?

Thanks,

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140325/d6005f24/attachment.htm>

From abokovoy at redhat.com  Tue Mar 25 18:59:41 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Tue, 25 Mar 2014 20:59:41 +0200
Subject: [Freeipa-users] AD trusts & HBACs & such
In-Reply-To: <CAA9J0ZFWtBR8VfUHYxy27HPU_rW94c04e8GXkvWs0TR9nH0pMg@mail.gmail.com>
References: <CAA9J0ZFWtBR8VfUHYxy27HPU_rW94c04e8GXkvWs0TR9nH0pMg@mail.gmail.com>
Message-ID: <20140325185941.GJ21211@redhat.com>

On Tue, 25 Mar 2014, KodaK wrote:
>I've been working with support on how to set up HBAC and sudo rules with AD
>users.
>
>>From what they've described I can only manage them on an aggregate level
>using an external group.
>
>For example, I can define an hbac rule, but that hbac rule will be vaild
>for *all* AD users in the external group that was created to handle them.
>
>Am I missing something?  If that's the case then this isn't flexible enough
>for our needs.  I have to be able to specify rules based on individual
>accounts.
>
>It seems like there might be a work-around by using multiple external
>groups and having each AD user in their own external group, but that would
>be really cumbersome (if it's even possible.)
>
>Do I have any other options?
Group membership in IPA follows LDAP membership rules. This means
objects must have DN to be included into an LDAP group. AD users do not
exist in IPA LDAP server, thus they cannot be referenced by DN.

HBAC rules refer objects by their LDAP DNs too.

To overcome absence of LDAP DNs for AD users and groups we have
concept of "external" groups in IPA LDAP. These are normal LDAP groups,
that lack POSIX attributes and have special attribute to store SIDs of
external objects which 'belong' to this group. We then use DN of the
"external" group to be a member.

When SSSD evaluates HBAC groups against certain AD user, it uses group
membership from Keberos ticket defined in MS-PAC structure to verify
against the set of HBAC rules. That group membership in the MS-PAC is
defined in terms of SIDs. SSSD downloads all HBAC rules related to the
host, then unrolls all groups that are referenced in the HBAC rules and
applies special handling to "external" groups by taking that specific
attribute which stores SIDs of "external" group members.

So at this point SSSD has all information to match SIDs of AD user
against HBAC rules. There is no other way to do it.

So there are two ways to handle your case -- by grouping at IPA side or
by grouping at AD side.

The latter approach is to have a group in AD that says "these users
have access to this server" and make an "external" group in IPA that
references the AD group. By deleting AD user from AD group you will
effectively deny access to an IPA machine without touching IPA rules.

There are no other ways.
-- 
/ Alexander Bokovoy



From zhu_junca at yahoo.ca  Wed Mar 26 02:49:42 2014
From: zhu_junca at yahoo.ca (Carl E. Ma)
Date: Tue, 25 Mar 2014 22:49:42 -0400
Subject: [Freeipa-users] freeIPA 3.3.4 on Centos 6.5
Message-ID: <53324046.8040906@yahoo.ca>

Hello,

I am planning to setup IPA-server in centos 6.5 environment  to manage 
user accounts(on ubuntu/centos/redhat) and automount NFS home 
directories.  The IPA-server in centos 6.x repository is 3.0.0.

Name        : ipa-server
Arch        : x86_64
Version     : 3.0.0
Release     : 37.el6
Size        : 1.1 M
Repo        : base


Is the latest 3.3.4 version  supported in centos 6.5?  I would like to 
hear your opinions before start compiling 3.3.4 from source.

Thanks,

carl



From barrykfl at gmail.com  Wed Mar 26 04:08:48 2014
From: barrykfl at gmail.com (barrykfl at gmail.com)
Date: Wed, 26 Mar 2014 12:08:48 +0800
Subject: [Freeipa-users] stop alias of https://abc.com/ipa/ui/
Message-ID: <CAELz9dsbc0kpaeNYM3229toim-2Cd91cge80C9MMsQ8=ach60A@mail.gmail.com>

Dear sir:

where can i set stop alias of /ipa/ui redirection...and let

it just use https://abc.com/ipa/ui/  absolute path?

thks

barry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140326/0b15fd52/attachment.htm>

From abokovoy at redhat.com  Wed Mar 26 04:26:53 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Wed, 26 Mar 2014 06:26:53 +0200
Subject: [Freeipa-users] freeIPA 3.3.4 on Centos 6.5
In-Reply-To: <53324046.8040906@yahoo.ca>
References: <53324046.8040906@yahoo.ca>
Message-ID: <20140326042653.GK21211@redhat.com>

On Tue, 25 Mar 2014, Carl E. Ma wrote:
>Hello,
>
>I am planning to setup IPA-server in centos 6.5 environment  to 
>manage user accounts(on ubuntu/centos/redhat) and automount NFS home 
>directories.  The IPA-server in centos 6.x repository is 3.0.0.
>
>Name        : ipa-server
>Arch        : x86_64
>Version     : 3.0.0
>Release     : 37.el6
>Size        : 1.1 M
>Repo        : base
>
>
>Is the latest 3.3.4 version  supported in centos 6.5?  I would like 
>to hear your opinions before start compiling 3.3.4 from source.
This topic raises regularly. I'd suggest you to read this thread:
https://www.redhat.com/archives/freeipa-users/2014-February/msg00255.html


-- 
/ Alexander Bokovoy



From haramaty.zvika at gmail.com  Wed Mar 26 09:44:32 2014
From: haramaty.zvika at gmail.com (=?UTF-8?B?16bXkdeZ16fXlCDXlNeo157XqteZ?=)
Date: Wed, 26 Mar 2014 11:44:32 +0200
Subject: [Freeipa-users] IPA - Samba / Redmine / Disable Kerberos?
Message-ID: <CAN3MF8CZqogFkf4HmNN2s6nb8J_wwBqyUAL_FLJ7SF38in5Hng@mail.gmail.com>

Hi.
I have a small network of CentOS6.5 servers, and installed standard IdM
(==FreeIPA).
Everything works fine.

Now I want to use IPA for other uses:

1.
Use IPA together with Samba. I *don't* have fancy Windows servers, AD, or
whatever. My network is comprised of a few CentOS servers, and some Windows
7/8 laptops that connect to it with SSH and VNC.
I have installed (successfully) Samba, which should be used only for file
sharing between Linux and Windows. No need for other features.
However, in order to use Samba I have to define each user for Samba, and
keep separate passwords.

I'm confident that I missed something, and Samba can be somehow integrate
with IPA, to use authenticate users against it.
But I didn't find any solution or HowTo...

2.
I'm using Redmine (issue tracking tool), that can authenticate against LDPA
server (http://www.redmine.org/projects/redmine/wiki/RedmineLDAP).
Can I use IPA for this?

It seems that in order to use IPA's LDAP database, the client must first
gain access from Kerberos.
I have no experience with Kerberos, but it seems that Redmine doesn't
support it.
Any ideas for solution?

3.
(related to the previous question-)
Can I somehow disable the Kerberos component of IPA, using only the easy
LDAP solution, allowing it easier integration with other tools?

Thanks,
Zvika
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140326/fa8a6cb2/attachment.htm>

From pspacek at redhat.com  Wed Mar 26 11:28:00 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Wed, 26 Mar 2014 12:28:00 +0100
Subject: [Freeipa-users] IPA - Samba / Redmine / Disable Kerberos?
In-Reply-To: <CAN3MF8CZqogFkf4HmNN2s6nb8J_wwBqyUAL_FLJ7SF38in5Hng@mail.gmail.com>
References: <CAN3MF8CZqogFkf4HmNN2s6nb8J_wwBqyUAL_FLJ7SF38in5Hng@mail.gmail.com>
Message-ID: <5332B9C0.4040501@redhat.com>

On 26.3.2014 10:44, ????? ????? wrote:
> Hi.
> I have a small network of CentOS6.5 servers, and installed standard IdM
> (==FreeIPA).
> Everything works fine.
>
> Now I want to use IPA for other uses:
>
> 1.
> Use IPA together with Samba. I *don't* have fancy Windows servers, AD, or
> whatever. My network is comprised of a few CentOS servers, and some Windows
> 7/8 laptops that connect to it with SSH and VNC.
> I have installed (successfully) Samba, which should be used only for file
> sharing between Linux and Windows. No need for other features.
> However, in order to use Samba I have to define each user for Samba, and
> keep separate passwords.
>
> I'm confident that I missed something, and Samba can be somehow integrate
> with IPA, to use authenticate users against it.
> But I didn't find any solution or HowTo...
>
> 2.
> I'm using Redmine (issue tracking tool), that can authenticate against LDPA
> server (http://www.redmine.org/projects/redmine/wiki/RedmineLDAP).
> Can I use IPA for this?
Sure :-) We don't have how-to specifically for Redmine, you need to map 
information from Redmine how-to to:
http://www.freeipa.org/page/HowTo/LDAP

Feel free to create Redmine page here:
http://www.freeipa.org/page/HowTos
(Your Fedora account should just work.)

> It seems that in order to use IPA's LDAP database, the client must first
> gain access from Kerberos.
No, you can use plain LDAP as usual as long as you don't want to use single 
sign-on.

> I have no experience with Kerberos, but it seems that Redmine doesn't
> support it.
> Any ideas for solution?
Configure Redmine with LDAP backend as usual.

> 3.
> (related to the previous question-)
> Can I somehow disable the Kerberos component of IPA, using only the easy
> LDAP solution, allowing it easier integration with other tools?
You can't "disable it" but you are not forced to use Kerberos if you don't 
want to do so. Plain LDAP bind should work for you.

(Please note that Kerberos offers single sign-on and it is believed to provide 
better security so it is worth spending time on it.)

-- 
Petr^2 Spacek



From haramaty.zvika at gmail.com  Wed Mar 26 11:42:29 2014
From: haramaty.zvika at gmail.com (=?UTF-8?B?16bXkdeZ16fXlCDXlNeo157XqteZ?=)
Date: Wed, 26 Mar 2014 13:42:29 +0200
Subject: [Freeipa-users] IPA - Samba / Redmine / Disable Kerberos?
In-Reply-To: <5332B9C0.4040501@redhat.com>
References: <CAN3MF8CZqogFkf4HmNN2s6nb8J_wwBqyUAL_FLJ7SF38in5Hng@mail.gmail.com>
	<5332B9C0.4040501@redhat.com>
Message-ID: <CAN3MF8AcQg2j8yF7PvcYvbefdPXun830nC8pPoSdWgCnt7wQeA@mail.gmail.com>

Thanks for the prompt reply.
I tried to just bind Redmine, and failed; so I assumed that it's not
possible.
Now, with that information, I'm encouraged to try again...

What about Samba?
Can you reference me to some relevant Howto/tutorial?


2014-03-26 13:28 GMT+02:00 Petr Spacek <pspacek at redhat.com>:

> On 26.3.2014 10:44, ????? ????? wrote:
>
>> Hi.
>> I have a small network of CentOS6.5 servers, and installed standard IdM
>> (==FreeIPA).
>> Everything works fine.
>>
>> Now I want to use IPA for other uses:
>>
>> 1.
>> Use IPA together with Samba. I *don't* have fancy Windows servers, AD, or
>> whatever. My network is comprised of a few CentOS servers, and some
>> Windows
>> 7/8 laptops that connect to it with SSH and VNC.
>> I have installed (successfully) Samba, which should be used only for file
>> sharing between Linux and Windows. No need for other features.
>> However, in order to use Samba I have to define each user for Samba, and
>> keep separate passwords.
>>
>> I'm confident that I missed something, and Samba can be somehow integrate
>> with IPA, to use authenticate users against it.
>> But I didn't find any solution or HowTo...
>>
>> 2.
>> I'm using Redmine (issue tracking tool), that can authenticate against
>> LDPA
>> server (http://www.redmine.org/projects/redmine/wiki/RedmineLDAP).
>> Can I use IPA for this?
>>
> Sure :-) We don't have how-to specifically for Redmine, you need to map
> information from Redmine how-to to:
> http://www.freeipa.org/page/HowTo/LDAP
>
> Feel free to create Redmine page here:
> http://www.freeipa.org/page/HowTos
> (Your Fedora account should just work.)
>
>
>  It seems that in order to use IPA's LDAP database, the client must first
>> gain access from Kerberos.
>>
> No, you can use plain LDAP as usual as long as you don't want to use
> single sign-on.
>
>
>  I have no experience with Kerberos, but it seems that Redmine doesn't
>> support it.
>> Any ideas for solution?
>>
> Configure Redmine with LDAP backend as usual.
>
>
>  3.
>> (related to the previous question-)
>> Can I somehow disable the Kerberos component of IPA, using only the easy
>> LDAP solution, allowing it easier integration with other tools?
>>
> You can't "disable it" but you are not forced to use Kerberos if you don't
> want to do so. Plain LDAP bind should work for you.
>
> (Please note that Kerberos offers single sign-on and it is believed to
> provide better security so it is worth spending time on it.)
>
> --
> Petr^2 Spacek
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140326/8026faaf/attachment.htm>

From pspacek at redhat.com  Wed Mar 26 12:03:51 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Wed, 26 Mar 2014 13:03:51 +0100
Subject: [Freeipa-users] IPA - Samba / Redmine / Disable Kerberos?
In-Reply-To: <CAN3MF8AcQg2j8yF7PvcYvbefdPXun830nC8pPoSdWgCnt7wQeA@mail.gmail.com>
References: <CAN3MF8CZqogFkf4HmNN2s6nb8J_wwBqyUAL_FLJ7SF38in5Hng@mail.gmail.com>	<5332B9C0.4040501@redhat.com>
	<CAN3MF8AcQg2j8yF7PvcYvbefdPXun830nC8pPoSdWgCnt7wQeA@mail.gmail.com>
Message-ID: <5332C227.9040804@redhat.com>

On 26.3.2014 12:42, ????? ????? wrote:
> Thanks for the prompt reply.
> I tried to just bind Redmine, and failed; so I assumed that it's not
> possible.
> Now, with that information, I'm encouraged to try again...
>
> What about Samba?
> Can you reference me to some relevant Howto/tutorial?

There is an older article:
http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/

Let us know if you encounter any problem. It is possible that the article 
needs an update...

-- 
Petr^2 Spacek



From mkosek at redhat.com  Wed Mar 26 12:19:01 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Wed, 26 Mar 2014 13:19:01 +0100
Subject: [Freeipa-users] stop alias of https://abc.com/ipa/ui/
In-Reply-To: <CAELz9dsbc0kpaeNYM3229toim-2Cd91cge80C9MMsQ8=ach60A@mail.gmail.com>
References: <CAELz9dsbc0kpaeNYM3229toim-2Cd91cge80C9MMsQ8=ach60A@mail.gmail.com>
Message-ID: <5332C5B5.5090003@redhat.com>

On 03/26/2014 05:08 AM, barrykfl at gmail.com wrote:
> Dear sir:
> 
> where can i set stop alias of /ipa/ui redirection...and let
> 
> it just use https://abc.com/ipa/ui/  absolute path?
> 
> thks
> 
> barry

/etc/httpd/conf.d/ipa-rewrite.conf

Martin



From mkosek at redhat.com  Wed Mar 26 12:29:39 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Wed, 26 Mar 2014 13:29:39 +0100
Subject: [Freeipa-users] IPA - Samba / Redmine / Disable Kerberos?
In-Reply-To: <CAN3MF8AcQg2j8yF7PvcYvbefdPXun830nC8pPoSdWgCnt7wQeA@mail.gmail.com>
References: <CAN3MF8CZqogFkf4HmNN2s6nb8J_wwBqyUAL_FLJ7SF38in5Hng@mail.gmail.com>	<5332B9C0.4040501@redhat.com>
	<CAN3MF8AcQg2j8yF7PvcYvbefdPXun830nC8pPoSdWgCnt7wQeA@mail.gmail.com>
Message-ID: <5332C833.6050701@redhat.com>

On 03/26/2014 12:42 PM, ????? ????? wrote:
> Thanks for the prompt reply.
> I tried to just bind Redmine, and failed; so I assumed that it's not
> possible.
> Now, with that information, I'm encouraged to try again...

According to [1], you should be able to create a system account for redmine in
FreeIPA LDAP (example in [2]) and pass the DN to "Account" option and fill it's
password.

Then it should be pretty straightforward to configure Redmine to bind users
against FreeIPA LDAP by filling the Base DN and the right user attributes.

BTW as Petr already said, when you make your setup working it would be indeed
very welcome and helpful for FreeIPA community if you create a howto on our
wiki [3].

Martin

[1] http://www.redmine.org/projects/redmine/wiki/RedmineLDAP
[2] ejabberd account creation in
https://www.dalemacartney.com/2012/07/05/configuring-ejabberd-to-authenticate-freeipa-users-using-ldap-group-memberships/
[3] http://www.freeipa.org/page/HowTos



From rcritten at redhat.com  Wed Mar 26 13:42:18 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Wed, 26 Mar 2014 09:42:18 -0400
Subject: [Freeipa-users] stop alias of https://abc.com/ipa/ui/
In-Reply-To: <5332C5B5.5090003@redhat.com>
References: <CAELz9dsbc0kpaeNYM3229toim-2Cd91cge80C9MMsQ8=ach60A@mail.gmail.com>
	<5332C5B5.5090003@redhat.com>
Message-ID: <5332D93A.6050003@redhat.com>

Martin Kosek wrote:
> On 03/26/2014 05:08 AM, barrykfl at gmail.com wrote:
>> Dear sir:
>>
>> where can i set stop alias of /ipa/ui redirection...and let
>>
>> it just use https://abc.com/ipa/ui/  absolute path?
>>
>> thks
>>
>> barry
>
> /etc/httpd/conf.d/ipa-rewrite.conf

You'll need to watch this file on upgrades as it can revert in some cases.

rob



From haramaty.zvika at gmail.com  Wed Mar 26 20:32:07 2014
From: haramaty.zvika at gmail.com (=?UTF-8?B?16bXkdeZ16fXlCDXlNeo157XqteZ?=)
Date: Wed, 26 Mar 2014 22:32:07 +0200
Subject: [Freeipa-users] IPA - Samba / Redmine / Disable Kerberos?
In-Reply-To: <5332C833.6050701@redhat.com>
References: <CAN3MF8CZqogFkf4HmNN2s6nb8J_wwBqyUAL_FLJ7SF38in5Hng@mail.gmail.com>
	<5332B9C0.4040501@redhat.com>
	<CAN3MF8AcQg2j8yF7PvcYvbefdPXun830nC8pPoSdWgCnt7wQeA@mail.gmail.com>
	<5332C833.6050701@redhat.com>
Message-ID: <CAN3MF8DstfY7_QYMXKR2XM7x2uFB5sFkfQVLjntG_gokqzFFyA@mail.gmail.com>

Wow. That was much easier that my previous attempt...

Here is the HowTo I wrote:
http://www.freeipa.org/page/HowTo/Authenticating_Redmine_with_IPA

I'll be glad if you review it.

Regarding Samba, that page looks a bit intimidating...

Thanks for the help.


2014-03-26 14:29 GMT+02:00 Martin Kosek <mkosek at redhat.com>:

> On 03/26/2014 12:42 PM, ????? ????? wrote:
> > Thanks for the prompt reply.
> > I tried to just bind Redmine, and failed; so I assumed that it's not
> > possible.
> > Now, with that information, I'm encouraged to try again...
>
> According to [1], you should be able to create a system account for
> redmine in
> FreeIPA LDAP (example in [2]) and pass the DN to "Account" option and fill
> it's
> password.
>
> Then it should be pretty straightforward to configure Redmine to bind users
> against FreeIPA LDAP by filling the Base DN and the right user attributes.
>
> BTW as Petr already said, when you make your setup working it would be
> indeed
> very welcome and helpful for FreeIPA community if you create a howto on our
> wiki [3].
>
> Martin
>
> [1] http://www.redmine.org/projects/redmine/wiki/RedmineLDAP
> [2] ejabberd account creation in
>
> https://www.dalemacartney.com/2012/07/05/configuring-ejabberd-to-authenticate-freeipa-users-using-ldap-group-memberships/
> [3] http://www.freeipa.org/page/HowTos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140326/5c557256/attachment.htm>

From dpal at redhat.com  Wed Mar 26 22:15:54 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Wed, 26 Mar 2014 18:15:54 -0400
Subject: [Freeipa-users] External Collaboration Domains
In-Reply-To: <20140325071208.GD3487@redhat.com>
References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net>
	<20140325071208.GD3487@redhat.com>
Message-ID: <5333519A.2060206@redhat.com>

On 03/25/2014 03:12 AM, Alexander Bokovoy wrote:
> On Tue, 25 Mar 2014, Nordgren, Bryce L -FS wrote:
>>
>>> Collaboration can be in different ways. It all depends on the use 
>>> case. It can be OpenID, SAML, Kerberos, etc. There are different 
>>> technologies and they suit better different use cases.
>>
>>> Can you please share under what circumstances such "inversion" would 
>>> actually be needed?
>>
>> Console logins in a domain specifically created for collaboration with
>> external entities. Expect that there is a one-way trust from the
>> organization's "internal" domain (providing users) to the collaboration
>> domain (providing services). The collaboration domain would host
>> services and devices necessary for the execution of various projects.
>> Project members are NOT from a small set of closely knit organizations,
>> where it is feasible to establish cross domain trusts. As this is a
>> large organization, many projects are starting, in-progress, and ending
>> at all times. New projects do not necessarily require trusts to the
>> same set of organizations as existing or finishing projects. Services
>> may be web services, shared filesystems, standalone processing
>> machines, and high performance computing assets. The services have
>> service or host principals in the collaboration domain's domain
>> controller. From an IT perspective, this is similar to interacting with
>> customers, except the customer!  s deploy and/or access stuff on your
>> network.
>>
>> Much of the horsepower in this domain will probably be some variant of
>> Linux. There are instances of high-horsepower Windows and Mac
>> devices/clusters, but they are not common.  Source code control, issue
>> trackers, networked filesystems, datafiles, and metadata development
>> webapps have a presence here. Esoteric scientific equipment may be
>> connected to the network, but will probably not be Kerberized (i.e.,
>> Gas Chromatograph Mass Spectrometer). Terminals may be Mac, Windows,
>> Linux, Android or iOS and may belong to guests. This is just in my
>> building in Montana. Nationwide the situation is likely to be more
>> chaotic. The big reason everything is here: it either violates
>> enterprise policy or needs to be accessible by external users (which
>> violates enterprise policy).
> to sum up above, you'd need POSIX identities for users and groups coming
> from nowhere to be created and associated with their external
> credentials.
>
> This is not really different from what many web sites do which accept
> 3rd-party authentication promise but then create own accounts once
> you've passed through OAuth2, for example.
>
> So you would have an IPA domain where you would have a portal that
> creates users after they successfully authenticated to a third-party you
> trust. FreeIPA 4.0 will have support for external RADIUS server
> authentication as a token that can be associated with a user. Note that
> this user has to be created first but overall this is doable.
>
> However, consequent logins through console would assume you are actually
> using your third-party password or two-factor auth directly. This means
> no previously issued OAuth2 assurance can be of any help here as you are
> not dealing with a browser here that obtained the assurance. May be at
> this point it would make sense to actually switch the user to some
> generated password or 2FA unique to the collaboration domain?
>
>
>> If such a domain were to exclusively contain web services, one wouldn't
>> need  a domain controller at all. Something like gluu or openam would
>> suffice. But I need to share files and support console access in
>> addition to web access. Using the same credentials. Which I don't want
>> to manage.
> For web services exclusively, a scheme with external RADIUS provided
> token is OK.
>
>> If the KDC is bundled as part of a larger directory solution like
>> IPA/AD, then some "extra overhead" (SID/UID) needs to be synthesized
>> for use within the domain when the identity is first encountered. This
>> is not more work than offering your realm's services to Kerberos users
>> (from IPA? AD? Kerberos+LDAP? Just Kerberos?) who arrive from a foreign
>> realm (via PKINIT or trust) when you have no way to access this
>> non-kerberos information in the user's home realm. Letting the local
>> domain controller do it guarantees it's harmonized within the realm.
> See above.
>
>> There has to be a standardized method for encoding these foreign user
>> principal names and realms. You want subsequent logins to use the same
>> principal (and same SID/UID). You also want the principal name and
>> realm to be the same no matter how it shows up in your realm (e.g., via
>> direct login or via a trust). This may involve the creation of zero or
>> more new Kerberos nametypes.
> I don't think you really need to invent something here. Authenticate
> over some third-party source at sign-up, ask user to accept terms of
> use, create IPA user for the user, associate external token with the IPA
> user based on already obtained OAuth2 token user gave you when signed
> up. Keep external identity in the IPA user account:
>
> ipa user-add <user> --radius=<radiusproxy-name> \
>                     --radius-username=<external-name> \
>                     --user-auth-type={password,radius}
>
> then set password that user will be using for non-web services. It would
> be usable for web services too, though, but that is a detail.
>
> On consequent logons to the web service use the negotiated OAuth2 token
> to authenticate to the RADIUS server that will use it to communicate
> with a third-party.
>
>
>> Maybe this could be done by adding an external login page to IPA's
>> management web interface, which coordinates the necessary actions
>> between the HTTP authentication workflow, LDAP, the DogTag CA, PKINIT
>> to the KDC, and which returns the TGT to the browser (or displays an
>> error). There are many pieces involved, but most are already gathered
>> together. Aside from browser support of this mechanism, this does not
>> seem like an overly invasive solution to any particular component.
> What we see is that increasingly people want to hide IPA web UI and
> integrate such functionality in their own tools/interfaces. So we can
> provide something like that but it would be hardly usable to others due
> to difference in the technologies used to build web UIs.
>
> Having an article that shows how to do it with one of possible tools
> would be good, yes.
>
>> In any case, IPA would need to synthesize "extra" data (UID/SID) for
>> this PKINIT/foreign-user connection, as it should be doing now for all
>> non-anonymous PKINIT connections. :) May I ask how IPA handles this
>> case now? Googling shows me that there is PKINIT support, but I can't
>> tell whether this includes setting user attributes...
> See above, read http://www.freeipa.org/page/V3/OTP
>
In addition to what Alexander said I think what would be possible soon 
is to use Ipsilon (our IdP project) gateway to authenticate using one 
authentication method and then translate the authentication into some 
other token i.e. SAML, Kerberos or something else. We are working on this.



-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From haramaty.zvika at gmail.com  Thu Mar 27 06:37:31 2014
From: haramaty.zvika at gmail.com (=?UTF-8?B?16bXkdeZ16fXlCDXlNeo157XqteZ?=)
Date: Thu, 27 Mar 2014 08:37:31 +0200
Subject: [Freeipa-users] Configuration backup (before Samba integration)
Message-ID: <CAN3MF8Av3gOKJjwv8zTD2XiDuP8Mif9MoXnX-op0d7eWC_hSCw@mail.gmail.com>

Hi.
I have a working network with IdM (FreeIPA).
I'd like to integrate it with Samba, according to
http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/

What's the recommended way to backup current IPA settings and
configurations, so in case that the Samba integration won't go well I'd be
able to revert back to my current situation?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/4a72d56b/attachment.htm>

From mkosek at redhat.com  Thu Mar 27 07:15:08 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Thu, 27 Mar 2014 08:15:08 +0100
Subject: [Freeipa-users] IPA - Samba / Redmine / Disable Kerberos?
In-Reply-To: <CAN3MF8DstfY7_QYMXKR2XM7x2uFB5sFkfQVLjntG_gokqzFFyA@mail.gmail.com>
References: <CAN3MF8CZqogFkf4HmNN2s6nb8J_wwBqyUAL_FLJ7SF38in5Hng@mail.gmail.com>	<5332B9C0.4040501@redhat.com>	<CAN3MF8AcQg2j8yF7PvcYvbefdPXun830nC8pPoSdWgCnt7wQeA@mail.gmail.com>	<5332C833.6050701@redhat.com>
	<CAN3MF8DstfY7_QYMXKR2XM7x2uFB5sFkfQVLjntG_gokqzFFyA@mail.gmail.com>
Message-ID: <5333CFFC.20508@redhat.com>

Thanks! That helps. I have few suggestions that would be great if you test:

1) Can we point Redmine to search users directly in the users container?
I.e. cn=users,cn=accounts,dc=example,dc=com instead of just dc=example,dc=com.
It will narrow down the LDAP search.

2) Can you search over LDAPS? Just to make sure that the bind and user password
do not get in plain text over the wire.

3) Does the On-the-fly user creation goes well? In current configuration it
would seem to me that some of the attributes that FreeIPA keeps for each user
are not utilized. Would something like:

On-the-fly user creation = yes
Attributes
  Login     = uid
  Firstname = givenName
  Lastname  = sn
  Email     = mail

provide better results in on the fly user creation?

Martin


On 03/26/2014 09:32 PM, ????? ????? wrote:
> Wow. That was much easier that my previous attempt...
> 
> Here is the HowTo I wrote:
> http://www.freeipa.org/page/HowTo/Authenticating_Redmine_with_IPA
> 
> I'll be glad if you review it.
> 
> Regarding Samba, that page looks a bit intimidating...
> 
> Thanks for the help.
> 
> 
> 2014-03-26 14:29 GMT+02:00 Martin Kosek <mkosek at redhat.com>:
> 
>> On 03/26/2014 12:42 PM, ????? ????? wrote:
>>> Thanks for the prompt reply.
>>> I tried to just bind Redmine, and failed; so I assumed that it's not
>>> possible.
>>> Now, with that information, I'm encouraged to try again...
>>
>> According to [1], you should be able to create a system account for
>> redmine in
>> FreeIPA LDAP (example in [2]) and pass the DN to "Account" option and fill
>> it's
>> password.
>>
>> Then it should be pretty straightforward to configure Redmine to bind users
>> against FreeIPA LDAP by filling the Base DN and the right user attributes.
>>
>> BTW as Petr already said, when you make your setup working it would be
>> indeed
>> very welcome and helpful for FreeIPA community if you create a howto on our
>> wiki [3].
>>
>> Martin
>>
>> [1] http://www.redmine.org/projects/redmine/wiki/RedmineLDAP
>> [2] ejabberd account creation in
>>
>> https://www.dalemacartney.com/2012/07/05/configuring-ejabberd-to-authenticate-freeipa-users-using-ldap-group-memberships/
>> [3] http://www.freeipa.org/page/HowTos
>>
> 



From natxo.asenjo at gmail.com  Thu Mar 27 07:36:05 2014
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Thu, 27 Mar 2014 08:36:05 +0100
Subject: [Freeipa-users] Configuration backup (before Samba integration)
In-Reply-To: <CAN3MF8Av3gOKJjwv8zTD2XiDuP8Mif9MoXnX-op0d7eWC_hSCw@mail.gmail.com>
References: <CAN3MF8Av3gOKJjwv8zTD2XiDuP8Mif9MoXnX-op0d7eWC_hSCw@mail.gmail.com>
Message-ID: <CAHBEJzXEixTSpXDwK9k8+SjP5q94XGBqo0hJqakmHycHOFby5g@mail.gmail.com>

On Thu, Mar 27, 2014 at 7:37 AM, ????? ????? <haramaty.zvika at gmail.com>wrote:

> Hi.
> I have a working network with IdM (FreeIPA).
> I'd like to integrate it with Samba, according to
> http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/
>
> What's the recommended way to backup current IPA settings and
> configurations, so in case that the Samba integration won't go well I'd be
> able to revert back to my current situation?
>
>
I would test this first in a couple of vm's first. If you have a spare pc
newer than 4 years old chances are it is powerful enough to run a
hypervisor. You can isolate a full test network there. Once you are
satifsfied with your testing and you have documented all the steps, run
them in production ;-)

--
groet,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/b381373a/attachment.htm>

From barrykfl at gmail.com  Thu Mar 27 08:08:37 2014
From: barrykfl at gmail.com (barrykfl at gmail.com)
Date: Thu, 27 Mar 2014 16:08:37 +0800
Subject: [Freeipa-users] Any coomand can extract the private of the freeipa
	domain
Message-ID: <CAELz9dsgiji+MFc8iD9XKbW_YDdPNFfEnEg9DU_hYh7RqMyoeQ@mail.gmail.com>

i want to extract the private key of the self sign cert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/34c1d4fc/attachment.htm>

From andrew.holway at gmail.com  Thu Mar 27 12:09:14 2014
From: andrew.holway at gmail.com (Andrew Holway)
Date: Thu, 27 Mar 2014 12:09:14 +0000
Subject: [Freeipa-users] Backup / Restore
Message-ID: <CAEiui-uHk8LxBo7tt5h0iVG6P8JxqofDBkx=pG1AasG7J4Jtdg@mail.gmail.com>

Hello,

I am being tasked with setting up freeipa for an organisation. A
replica will be created but they also require a backup / restore
strategy.

Has anyone implemented backup restore? Ideas? Recommendations? Dragons?

Thanks,

Andrew



From mkosek at redhat.com  Thu Mar 27 12:31:09 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Thu, 27 Mar 2014 13:31:09 +0100
Subject: [Freeipa-users] Backup / Restore
In-Reply-To: <CAEiui-uHk8LxBo7tt5h0iVG6P8JxqofDBkx=pG1AasG7J4Jtdg@mail.gmail.com>
References: <CAEiui-uHk8LxBo7tt5h0iVG6P8JxqofDBkx=pG1AasG7J4Jtdg@mail.gmail.com>
Message-ID: <53341A0D.2050107@redhat.com>

On 03/27/2014 01:09 PM, Andrew Holway wrote:
> Hello,
> 
> I am being tasked with setting up freeipa for an organisation. A
> replica will be created but they also require a backup / restore
> strategy.
> 
> Has anyone implemented backup restore? Ideas? Recommendations? Dragons?
> 
> Thanks,
> 
> Andrew

Good topic! I would be really interested in experience from FreeIPA users. I
can only provide information from FreeIPA development team member point of view.

Our thoughts on topic of Backup and restore:
http://www.freeipa.org/page/Backup_and_Restore

Original design of backup and restore scripts:
http://www.freeipa.org/page/V3/Backup_and_Restore

As you can read in the first document, we are not yet convinced that
backup&restore scripts is the right thing to do + we also do not have enough
information from the field. If these scripts is what admin wants, if yes - do
they work for them?

If you check open Backup and Restore tickest, there are really not many of them:
https://fedorahosted.org/freeipa/query?status=assigned&status=new&status=reopened&component=Backup&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&group=milestone

Martin



From bret.wortman at damascusgrp.com  Thu Mar 27 13:02:07 2014
From: bret.wortman at damascusgrp.com (Bret Wortman)
Date: Thu, 27 Mar 2014 09:02:07 -0400
Subject: [Freeipa-users] Badly corrupted IPA
Message-ID: <5334214F.9070206@damascusgrp.com>

My IPA corruption continues and I'm afraid I'm going to have to recreate 
it from scratch since no reasonable means of backup exists (which I 
understand -- that's not my complaint).

Here's what I'm facing:

# script -c 'ipa host-find mw79.damascusgrp.com'
Script started, file is typescript
--------------
1 host matched
--------------
   Host name: mw79.damascusgrp.com
   Principal name: host/mw79.damascusgrp.com at DAMASCUSGRP.COM
   Password: False
   Member of host-groups: allow_all_hosts
   Indirect Member of HBAC rule: allow_all_users_services
   Keytab: False
   SSH public key fingerprint: [snip] (ssh-dss)

----------------------------
Number of entries returned 1
----------------------------
Script done, file is typescript
# script -c 'ipa host-del mw79.damascusgrp.com'
Script started, file is typescript
ipa: ERROR: mw79.damascusgrp.com: host not found
Script done, file is typescript
#

I had unenrolled this host and was attempting to re-enroll it, and this 
is preventing its re-enrollment. Any ideas of how to force deletion of 
this host entry? I'm not LDAP savvy enough to just go in and start 
whacking LDAP entries myself, and given that my IPA database has gotten 
corrupted enough that no IPA CLI command can run without being wrapped 
in "script" or "strace" or similar, I'm hesitant to go too far. This 
machine, however, is my program manager's workstation, so it's pretty 
important to get back up and running.

Thanks,


-- 
*Bret Wortman*

http://damascusgrp.com/
http://about.me/wortmanbret

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/f2e5b5d8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 51f7de33e4b08d2bdb8b4860
Type: image/png
Size: 28526 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/f2e5b5d8/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/f2e5b5d8/attachment.p7s>

From bret.wortman at damascusgrp.com  Thu Mar 27 13:06:14 2014
From: bret.wortman at damascusgrp.com (Bret Wortman)
Date: Thu, 27 Mar 2014 09:06:14 -0400
Subject: [Freeipa-users] Badly corrupted IPA
In-Reply-To: <5334214F.9070206@damascusgrp.com>
References: <5334214F.9070206@damascusgrp.com>
Message-ID: <53342246.1020909@damascusgrp.com>

BTW, this also fails when using the web UI -- I can see the entry but 
not delete it.

On 03/27/2014 09:02 AM, Bret Wortman wrote:
> My IPA corruption continues and I'm afraid I'm going to have to 
> recreate it from scratch since no reasonable means of backup exists 
> (which I understand -- that's not my complaint).
>
> Here's what I'm facing:
>
> # script -c 'ipa host-find mw79.damascusgrp.com'
> Script started, file is typescript
> --------------
> 1 host matched
> --------------
>   Host name: mw79.damascusgrp.com
>   Principal name: host/mw79.damascusgrp.com at DAMASCUSGRP.COM
>   Password: False
>   Member of host-groups: allow_all_hosts
>   Indirect Member of HBAC rule: allow_all_users_services
>   Keytab: False
>   SSH public key fingerprint: [snip] (ssh-dss)
>
> ----------------------------
> Number of entries returned 1
> ----------------------------
> Script done, file is typescript
> # script -c 'ipa host-del mw79.damascusgrp.com'
> Script started, file is typescript
> ipa: ERROR: mw79.damascusgrp.com: host not found
> Script done, file is typescript
> #
>
> I had unenrolled this host and was attempting to re-enroll it, and 
> this is preventing its re-enrollment. Any ideas of how to force 
> deletion of this host entry? I'm not LDAP savvy enough to just go in 
> and start whacking LDAP entries myself, and given that my IPA database 
> has gotten corrupted enough that no IPA CLI command can run without 
> being wrapped in "script" or "strace" or similar, I'm hesitant to go 
> too far. This machine, however, is my program manager's workstation, 
> so it's pretty important to get back up and running.
>
> Thanks,
>
>
> -- 
> *Bret Wortman*
>
> http://damascusgrp.com/
> http://about.me/wortmanbret
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/09578695/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 28526 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/09578695/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/09578695/attachment.p7s>

From Duncan.Innes at virginmoney.com  Thu Mar 27 13:07:12 2014
From: Duncan.Innes at virginmoney.com (Innes, Duncan)
Date: Thu, 27 Mar 2014 13:07:12 -0000
Subject: [Freeipa-users] Backup / Restore
In-Reply-To: <53341A0D.2050107@redhat.com>
References: <CAEiui-uHk8LxBo7tt5h0iVG6P8JxqofDBkx=pG1AasG7J4Jtdg@mail.gmail.com>
	<53341A0D.2050107@redhat.com>
Message-ID: <56343345B145C043AE990701E3D193950478DBB9@EXVS2.nrplc.localnet>

Martin,

Did the backup/restore scripts reach more than experimental status?
Looks like they were released in FreeIPA 3.2.

It's a problem for me that this kind of functionallity hasn't yet moved
into RHEL.

Backup/restore from some corporate use perspectives, cannot rely on
system snapshotting.  Whilst a snapshot may make an easier recovery
procedure for an admin, it is a take-it-or-leave-it approach.  I cannot,
for example, restore missing data that was deleted by mistake without
loosing other edits that have happened in the interim.

A VM snapshot is certainly a valid last-stop method of backing up IPA,
but it doesn't cover some of the use cases that most companies find
themselves having to deal with.

Thanks

Duncan

> -----Original Message-----
> From: freeipa-users-bounces at redhat.com 
> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Martin Kosek
> Sent: 27 March 2014 12:31
> To: Andrew Holway; freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] Backup / Restore
> 
> On 03/27/2014 01:09 PM, Andrew Holway wrote:
> > Hello,
> > 
> > I am being tasked with setting up freeipa for an organisation. A 
> > replica will be created but they also require a backup / restore 
> > strategy.
> > 
> > Has anyone implemented backup restore? Ideas? 
> Recommendations? Dragons?
> > 
> > Thanks,
> > 
> > Andrew
> 
> Good topic! I would be really interested in experience from 
> FreeIPA users. I can only provide information from FreeIPA 
> development team member point of view.
> 
> Our thoughts on topic of Backup and restore:
> http://www.freeipa.org/page/Backup_and_Restore
> 
> Original design of backup and restore scripts:
> http://www.freeipa.org/page/V3/Backup_and_Restore
> 
> As you can read in the first document, we are not yet 
> convinced that backup&restore scripts is the right thing to 
> do + we also do not have enough information from the field. 
> If these scripts is what admin wants, if yes - do they work for them?
> 
> If you check open Backup and Restore tickest, there are 
> really not many of them:
> https://fedorahosted.org/freeipa/query?status=assigned&status=
new&status=reopened&component=Backup&order=priority&col=id&col=summary&c
ol=status&col=type&col=priority&col=milestone&col=component&grou>
p=milestone
> 
> Martin
> 
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
> 
> This message has been checked for viruses and spam by the 
> Virgin Money email scanning system powered by Messagelabs.
> 

This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs.

This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message.

Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482).

For further details of Virgin Money group companies please visit our website at virginmoney.com



From sjuhasz at chemaxon.com  Thu Mar 27 13:36:22 2014
From: sjuhasz at chemaxon.com (Sandor Juhasz)
Date: Thu, 27 Mar 2014 14:36:22 +0100 (CET)
Subject: [Freeipa-users] authenticate samba 3 or 4 with freeipa
In-Reply-To: <1492791723.116172.1395926584616.JavaMail.zimbra@chemaxon.com>
Message-ID: <22036664.121131.1395927382024.JavaMail.zimbra@chemaxon.com>

Hello, 

what is the best practice to authenticate samba file sharing with freeipa as auth service. 
Either version 3 or 4 of samba is fine, as we are looking for this only for filesharing and not 
domain service. 
Our ipa service is hosted on CentOS 6.5. 
The samba service is preferred to be hosted on Ubuntu Precise (12.04), later the new LTS. 

Found 3 methods, but all seem to have their issues. 


    1. LDAP, ldapsam passdb backend. -> needs ldap schema modification to include fields (sambaSAMAccount, sambaGroupMapping, samabaSID) and have IPA populate those with dna plugin 
    2. IPA, ipasam passdb backend -> did not find a working version from ipasam.so for ubuntu, mostly i did not find any 
    3. KRB, keytab -> seemed a bit messy, also needs ldap schema modification 


S?ndor Juh?sz 
System Administrator 
ChemAxon Ltd . 
Building Hx, GraphiSoft Park, Z?hony utca 7, Budapest, Hungary, H-1031 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/5642f06b/attachment.htm>

From rcritten at redhat.com  Thu Mar 27 14:06:49 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Thu, 27 Mar 2014 10:06:49 -0400
Subject: [Freeipa-users] Backup / Restore
In-Reply-To: <56343345B145C043AE990701E3D193950478DBB9@EXVS2.nrplc.localnet>
References: <CAEiui-uHk8LxBo7tt5h0iVG6P8JxqofDBkx=pG1AasG7J4Jtdg@mail.gmail.com>	<53341A0D.2050107@redhat.com>
	<56343345B145C043AE990701E3D193950478DBB9@EXVS2.nrplc.localnet>
Message-ID: <53343079.6000406@redhat.com>

Innes, Duncan wrote:
> Martin,
>
> Did the backup/restore scripts reach more than experimental status?
> Looks like they were released in FreeIPA 3.2.

The problem is few people have experimented with it. We need feedback to 
know whether it works or not. It worked for me in my contrived 
environment over a couple of days but that isn't exactly definitive.

Playing with this should be relatively easy and pain free. A backup 
doesn't do anything operationally except bring down the servers (for 
sanity sake). You can do live backups but those aren't recommended, and 
only backs up the data (not all the other configuration, etc).

Then you can try doing a full restore in an isolated VM as a test, and 
see how things look.

> It's a problem for me that this kind of functionallity hasn't yet moved
> into RHEL.
>
> Backup/restore from some corporate use perspectives, cannot rely on
> system snapshotting.  Whilst a snapshot may make an easier recovery
> procedure for an admin, it is a take-it-or-leave-it approach.  I cannot,
> for example, restore missing data that was deleted by mistake without
> loosing other edits that have happened in the interim.

And that is still not dealt with in the current backup/restore. To do 
that requires some sort of LDIF browser where entries can be selected 
and restored/entries replaced. No such system already exists and 
represents a large chunk of work. It is a recognized shortcoming of the 
current support.

> A VM snapshot is certainly a valid last-stop method of backing up IPA,
> but it doesn't cover some of the use cases that most companies find
> themselves having to deal with.

Agreed.

rob

>
> Thanks
>
> Duncan
>
>> -----Original Message-----
>> From: freeipa-users-bounces at redhat.com
>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Martin Kosek
>> Sent: 27 March 2014 12:31
>> To: Andrew Holway; freeipa-users at redhat.com
>> Subject: Re: [Freeipa-users] Backup / Restore
>>
>> On 03/27/2014 01:09 PM, Andrew Holway wrote:
>>> Hello,
>>>
>>> I am being tasked with setting up freeipa for an organisation. A
>>> replica will be created but they also require a backup / restore
>>> strategy.
>>>
>>> Has anyone implemented backup restore? Ideas?
>> Recommendations? Dragons?
>>>
>>> Thanks,
>>>
>>> Andrew
>>
>> Good topic! I would be really interested in experience from
>> FreeIPA users. I can only provide information from FreeIPA
>> development team member point of view.
>>
>> Our thoughts on topic of Backup and restore:
>> http://www.freeipa.org/page/Backup_and_Restore
>>
>> Original design of backup and restore scripts:
>> http://www.freeipa.org/page/V3/Backup_and_Restore
>>
>> As you can read in the first document, we are not yet
>> convinced that backup&restore scripts is the right thing to
>> do + we also do not have enough information from the field.
>> If these scripts is what admin wants, if yes - do they work for them?
>>
>> If you check open Backup and Restore tickest, there are
>> really not many of them:
>> https://fedorahosted.org/freeipa/query?status=assigned&status=
> new&status=reopened&component=Backup&order=priority&col=id&col=summary&c
> ol=status&col=type&col=priority&col=milestone&col=component&grou>
> p=milestone
>>
>> Martin
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>> This message has been checked for viruses and spam by the
>> Virgin Money email scanning system powered by Messagelabs.
>>
>
> This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs.
>
> This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message.
>
> Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.
>
> The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482).
>
> For further details of Virgin Money group companies please visit our website at virginmoney.com
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>



From rcritten at redhat.com  Thu Mar 27 14:08:28 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Thu, 27 Mar 2014 10:08:28 -0400
Subject: [Freeipa-users] Badly corrupted IPA
In-Reply-To: <53342246.1020909@damascusgrp.com>
References: <5334214F.9070206@damascusgrp.com>
	<53342246.1020909@damascusgrp.com>
Message-ID: <533430DC.9090205@redhat.com>

Bret Wortman wrote:
> BTW, this also fails when using the web UI -- I can see the entry but
> not delete it.

It sounds like you have a replication conflict entry. Try this search:

$ ldapsearch -Y GSSAPI -b cn=computers,cn=accounts,dc=example,dc=com 
fdqdn=myhost.example.com

You'll probably get something with a dn that includes a nsuniqueid in 
it. That is the conflict entry. IPA can find the host because it 
searches by fqdn too, but it deletes by generating the direct DN and 
since it doesn't match, no delete.

You can delete the wayward entry using ldapdelete.

rob

>
> On 03/27/2014 09:02 AM, Bret Wortman wrote:
>> My IPA corruption continues and I'm afraid I'm going to have to
>> recreate it from scratch since no reasonable means of backup exists
>> (which I understand -- that's not my complaint).
>>
>> Here's what I'm facing:
>>
>> # script -c 'ipa host-find mw79.damascusgrp.com'
>> Script started, file is typescript
>> --------------
>> 1 host matched
>> --------------
>>   Host name: mw79.damascusgrp.com
>>   Principal name: host/mw79.damascusgrp.com at DAMASCUSGRP.COM
>>   Password: False
>>   Member of host-groups: allow_all_hosts
>>   Indirect Member of HBAC rule: allow_all_users_services
>>   Keytab: False
>>   SSH public key fingerprint: [snip] (ssh-dss)
>>
>> ----------------------------
>> Number of entries returned 1
>> ----------------------------
>> Script done, file is typescript
>> # script -c 'ipa host-del mw79.damascusgrp.com'
>> Script started, file is typescript
>> ipa: ERROR: mw79.damascusgrp.com: host not found
>> Script done, file is typescript
>> #
>>
>> I had unenrolled this host and was attempting to re-enroll it, and
>> this is preventing its re-enrollment. Any ideas of how to force
>> deletion of this host entry? I'm not LDAP savvy enough to just go in
>> and start whacking LDAP entries myself, and given that my IPA database
>> has gotten corrupted enough that no IPA CLI command can run without
>> being wrapped in "script" or "strace" or similar, I'm hesitant to go
>> too far. This machine, however, is my program manager's workstation,
>> so it's pretty important to get back up and running.
>>
>> Thanks,
>>
>>
>> --
>> *Bret Wortman*
>>
>> http://damascusgrp.com/
>> http://about.me/wortmanbret
>>
>>
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>



From haramaty.zvika at gmail.com  Thu Mar 27 14:09:08 2014
From: haramaty.zvika at gmail.com (=?UTF-8?B?16bXkdeZ16fXlCDXlNeo157XqteZ?=)
Date: Thu, 27 Mar 2014 16:09:08 +0200
Subject: [Freeipa-users] IPA - Samba / Redmine / Disable Kerberos?
In-Reply-To: <5333CFFC.20508@redhat.com>
References: <CAN3MF8CZqogFkf4HmNN2s6nb8J_wwBqyUAL_FLJ7SF38in5Hng@mail.gmail.com>
	<5332B9C0.4040501@redhat.com>
	<CAN3MF8AcQg2j8yF7PvcYvbefdPXun830nC8pPoSdWgCnt7wQeA@mail.gmail.com>
	<5332C833.6050701@redhat.com>
	<CAN3MF8DstfY7_QYMXKR2XM7x2uFB5sFkfQVLjntG_gokqzFFyA@mail.gmail.com>
	<5333CFFC.20508@redhat.com>
Message-ID: <CAN3MF8BU5CMrgzPCh0PKRodbBDJBpeODF8AdUbHM0W+1qz_yHg@mail.gmail.com>

I have updated the HowTo with suggestions 1 & 2 (after checking them, of
course...)

Regarding suggestion 3 - I'm not sure I understand it.
Isn't that the difference I wrote between "Basic" and "Full" configurations?


2014-03-27 9:15 GMT+02:00 Martin Kosek <mkosek at redhat.com>:

> Thanks! That helps. I have few suggestions that would be great if you test:
>
> 1) Can we point Redmine to search users directly in the users container?
> I.e. cn=users,cn=accounts,dc=example,dc=com instead of just
> dc=example,dc=com.
> It will narrow down the LDAP search.
>
> 2) Can you search over LDAPS? Just to make sure that the bind and user
> password
> do not get in plain text over the wire.
>
> 3) Does the On-the-fly user creation goes well? In current configuration it
> would seem to me that some of the attributes that FreeIPA keeps for each
> user
> are not utilized. Would something like:
>
> On-the-fly user creation = yes
> Attributes
>   Login     = uid
>   Firstname = givenName
>   Lastname  = sn
>   Email     = mail
>
> provide better results in on the fly user creation?
>
> Martin
>
>
> On 03/26/2014 09:32 PM, ????? ????? wrote:
> > Wow. That was much easier that my previous attempt...
> >
> > Here is the HowTo I wrote:
> > http://www.freeipa.org/page/HowTo/Authenticating_Redmine_with_IPA
> >
> > I'll be glad if you review it.
> >
> > Regarding Samba, that page looks a bit intimidating...
> >
> > Thanks for the help.
> >
> >
> > 2014-03-26 14:29 GMT+02:00 Martin Kosek <mkosek at redhat.com>:
> >
> >> On 03/26/2014 12:42 PM, ????? ????? wrote:
> >>> Thanks for the prompt reply.
> >>> I tried to just bind Redmine, and failed; so I assumed that it's not
> >>> possible.
> >>> Now, with that information, I'm encouraged to try again...
> >>
> >> According to [1], you should be able to create a system account for
> >> redmine in
> >> FreeIPA LDAP (example in [2]) and pass the DN to "Account" option and
> fill
> >> it's
> >> password.
> >>
> >> Then it should be pretty straightforward to configure Redmine to bind
> users
> >> against FreeIPA LDAP by filling the Base DN and the right user
> attributes.
> >>
> >> BTW as Petr already said, when you make your setup working it would be
> >> indeed
> >> very welcome and helpful for FreeIPA community if you create a howto on
> our
> >> wiki [3].
> >>
> >> Martin
> >>
> >> [1] http://www.redmine.org/projects/redmine/wiki/RedmineLDAP
> >> [2] ejabberd account creation in
> >>
> >>
> https://www.dalemacartney.com/2012/07/05/configuring-ejabberd-to-authenticate-freeipa-users-using-ldap-group-memberships/
> >> [3] http://www.freeipa.org/page/HowTos
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/08096412/attachment.htm>

From bret.wortman at damascusgrp.com  Thu Mar 27 14:19:55 2014
From: bret.wortman at damascusgrp.com (Bret Wortman)
Date: Thu, 27 Mar 2014 10:19:55 -0400
Subject: [Freeipa-users] Badly corrupted IPA
In-Reply-To: <533430DC.9090205@redhat.com>
References: <5334214F.9070206@damascusgrp.com>
	<53342246.1020909@damascusgrp.com> <533430DC.9090205@redhat.com>
Message-ID: <5334338B.60707@damascusgrp.com>

That worked like a champ. As always.

Thanks, Rob.


Bret

On 03/27/2014 10:08 AM, Rob Crittenden wrote:
> Bret Wortman wrote:
>> BTW, this also fails when using the web UI -- I can see the entry but
>> not delete it.
>
> It sounds like you have a replication conflict entry. Try this search:
>
> $ ldapsearch -Y GSSAPI -b cn=computers,cn=accounts,dc=example,dc=com 
> fdqdn=myhost.example.com
>
> You'll probably get something with a dn that includes a nsuniqueid in 
> it. That is the conflict entry. IPA can find the host because it 
> searches by fqdn too, but it deletes by generating the direct DN and 
> since it doesn't match, no delete.
>
> You can delete the wayward entry using ldapdelete.
>
> rob
>
>>
>> On 03/27/2014 09:02 AM, Bret Wortman wrote:
>>> My IPA corruption continues and I'm afraid I'm going to have to
>>> recreate it from scratch since no reasonable means of backup exists
>>> (which I understand -- that's not my complaint).
>>>
>>> Here's what I'm facing:
>>>
>>> # script -c 'ipa host-find mw79.damascusgrp.com'
>>> Script started, file is typescript
>>> --------------
>>> 1 host matched
>>> --------------
>>>   Host name: mw79.damascusgrp.com
>>>   Principal name: host/mw79.damascusgrp.com at DAMASCUSGRP.COM
>>>   Password: False
>>>   Member of host-groups: allow_all_hosts
>>>   Indirect Member of HBAC rule: allow_all_users_services
>>>   Keytab: False
>>>   SSH public key fingerprint: [snip] (ssh-dss)
>>>
>>> ----------------------------
>>> Number of entries returned 1
>>> ----------------------------
>>> Script done, file is typescript
>>> # script -c 'ipa host-del mw79.damascusgrp.com'
>>> Script started, file is typescript
>>> ipa: ERROR: mw79.damascusgrp.com: host not found
>>> Script done, file is typescript
>>> #
>>>
>>> I had unenrolled this host and was attempting to re-enroll it, and
>>> this is preventing its re-enrollment. Any ideas of how to force
>>> deletion of this host entry? I'm not LDAP savvy enough to just go in
>>> and start whacking LDAP entries myself, and given that my IPA database
>>> has gotten corrupted enough that no IPA CLI command can run without
>>> being wrapped in "script" or "strace" or similar, I'm hesitant to go
>>> too far. This machine, however, is my program manager's workstation,
>>> so it's pretty important to get back up and running.
>>>
>>> Thanks,
>>>
>>>
>>> -- 
>>> *Bret Wortman*
>>>
>>> http://damascusgrp.com/
>>> http://about.me/wortmanbret
>>>
>>>
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/8cf5c495/attachment.p7s>

From mkosek at redhat.com  Thu Mar 27 14:20:45 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Thu, 27 Mar 2014 15:20:45 +0100
Subject: [Freeipa-users] IPA - Samba / Redmine / Disable Kerberos?
In-Reply-To: <CAN3MF8BU5CMrgzPCh0PKRodbBDJBpeODF8AdUbHM0W+1qz_yHg@mail.gmail.com>
References: <CAN3MF8CZqogFkf4HmNN2s6nb8J_wwBqyUAL_FLJ7SF38in5Hng@mail.gmail.com>	<5332B9C0.4040501@redhat.com>	<CAN3MF8AcQg2j8yF7PvcYvbefdPXun830nC8pPoSdWgCnt7wQeA@mail.gmail.com>	<5332C833.6050701@redhat.com>	<CAN3MF8DstfY7_QYMXKR2XM7x2uFB5sFkfQVLjntG_gokqzFFyA@mail.gmail.com>	<5333CFFC.20508@redhat.com>
	<CAN3MF8BU5CMrgzPCh0PKRodbBDJBpeODF8AdUbHM0W+1qz_yHg@mail.gmail.com>
Message-ID: <533433BD.4010108@redhat.com>

On 03/27/2014 03:09 PM, ????? ????? wrote:
> I have updated the HowTo with suggestions 1 & 2 (after checking them, of
> course...)

Good!

> Regarding suggestion 3 - I'm not sure I understand it.
> Isn't that the difference I wrote between "Basic" and "Full" configurations?

Ah, I see - you are right. I updated your article and fixed few minor issues I
saw and linked it to

http://www.freeipa.org/page/HowTos

Thank you,
Martin

> 2014-03-27 9:15 GMT+02:00 Martin Kosek <mkosek at redhat.com>:
> 
>> Thanks! That helps. I have few suggestions that would be great if you test:
>>
>> 1) Can we point Redmine to search users directly in the users container?
>> I.e. cn=users,cn=accounts,dc=example,dc=com instead of just
>> dc=example,dc=com.
>> It will narrow down the LDAP search.
>>
>> 2) Can you search over LDAPS? Just to make sure that the bind and user
>> password
>> do not get in plain text over the wire.
>>
>> 3) Does the On-the-fly user creation goes well? In current configuration it
>> would seem to me that some of the attributes that FreeIPA keeps for each
>> user
>> are not utilized. Would something like:
>>
>> On-the-fly user creation = yes
>> Attributes
>>   Login     = uid
>>   Firstname = givenName
>>   Lastname  = sn
>>   Email     = mail
>>
>> provide better results in on the fly user creation?
>>
>> Martin
>>
>>
>> On 03/26/2014 09:32 PM, ????? ????? wrote:
>>> Wow. That was much easier that my previous attempt...
>>>
>>> Here is the HowTo I wrote:
>>> http://www.freeipa.org/page/HowTo/Authenticating_Redmine_with_IPA
>>>
>>> I'll be glad if you review it.
>>>
>>> Regarding Samba, that page looks a bit intimidating...
>>>
>>> Thanks for the help.
>>>
>>>
>>> 2014-03-26 14:29 GMT+02:00 Martin Kosek <mkosek at redhat.com>:
>>>
>>>> On 03/26/2014 12:42 PM, ????? ????? wrote:
>>>>> Thanks for the prompt reply.
>>>>> I tried to just bind Redmine, and failed; so I assumed that it's not
>>>>> possible.
>>>>> Now, with that information, I'm encouraged to try again...
>>>>
>>>> According to [1], you should be able to create a system account for
>>>> redmine in
>>>> FreeIPA LDAP (example in [2]) and pass the DN to "Account" option and
>> fill
>>>> it's
>>>> password.
>>>>
>>>> Then it should be pretty straightforward to configure Redmine to bind
>> users
>>>> against FreeIPA LDAP by filling the Base DN and the right user
>> attributes.
>>>>
>>>> BTW as Petr already said, when you make your setup working it would be
>>>> indeed
>>>> very welcome and helpful for FreeIPA community if you create a howto on
>> our
>>>> wiki [3].
>>>>
>>>> Martin
>>>>
>>>> [1] http://www.redmine.org/projects/redmine/wiki/RedmineLDAP
>>>> [2] ejabberd account creation in
>>>>
>>>>
>> https://www.dalemacartney.com/2012/07/05/configuring-ejabberd-to-authenticate-freeipa-users-using-ldap-group-memberships/
>>>> [3] http://www.freeipa.org/page/HowTos
>>>>
>>>
>>
>>
> 



From barrykfl at gmail.com  Thu Mar 27 16:18:09 2014
From: barrykfl at gmail.com (barrykfl at gmail.com)
Date: Fri, 28 Mar 2014 00:18:09 +0800
Subject: [Freeipa-users] Try to re-import self sign cert fail after used 3rd
	paty cert
Message-ID: <CAELz9dsfOuQuNvJoXKof6kaEWNxZBD0m_cdH1OZUqGU-MqaKqA@mail.gmail.com>

Dear all:

I did change usin g 3rd party cert and now i tried to reimport the orginal
self sign cert i backup before all in p12 format.

Server-cert,p12 and ipacert.p12 ....i follow here and import successful.

BUT it show error during restart httpd that say untrust source. even i
added to  "NSSEnforceValidCerts off" httpd worked but web site unable to
access,  Any where i missed that i must make it trust again./

Also i tried 2nd way .... ipa-server-certinstall -w --http_pin=1234 ( i
backup p12 's password )  Server-cert.p12 but say incorrect password

it seem that the pin file txt inside is encrypted and not as same as the
password i created when  in the Server-cert.p12

any idea ?

7 23:58:19 2014] [error] SSL Library Error: -8172 Certificate is signed by
an untrusted issuer
[Thu Mar 27 23:58:19 2014] [error] Unable to verify certificate
'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the server can
start until the problem can be resolved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140328/84d7d1e4/attachment.htm>

From viktor.mendes at lmax.com  Thu Mar 27 16:46:09 2014
From: viktor.mendes at lmax.com (Viktor Mendes)
Date: Thu, 27 Mar 2014 16:46:09 +0000 (UTC)
Subject: [Freeipa-users] UNSUBSCRIBE
In-Reply-To: <CAELz9dsfOuQuNvJoXKof6kaEWNxZBD0m_cdH1OZUqGU-MqaKqA@mail.gmail.com>
References: <CAELz9dsfOuQuNvJoXKof6kaEWNxZBD0m_cdH1OZUqGU-MqaKqA@mail.gmail.com>
Message-ID: <261988269.6271027.1395938769847.JavaMail.zimbra@lmax.com>


---

LMAX Exchange, Yellow Building, 1A Nicholas Road, London W11 4AN
http://www.LMAX.com/

2013  #15 Fastest Growing Tech Company in the UK - Sunday Times Tech Track 100
2013  Best Margin Sector Platform - Profit & Loss Readers' Choice Awards 
2013  Best FX Trading Platform - ECN/MTF - WSL Institutional Trading Awards 
2011  Best Trading System - Financial Sector Technology Awards 
2011  Oracle's "Duke's Choice" Innovative Programming Framework Award

---

FX and CFDs are leveraged products that can result in losses exceeding
your deposit. They are not suitable for everyone so please ensure you fully
understand the risks involved.

The information on this email is not directed at residents of the
United States of America, Canada (although we may deal with Canadian
residents who meet the "Permitted Client" criteria), Singapore
or any
other jurisdiction where FX trading and/or CFD trading is restricted or
prohibited by local laws or regulations.

The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied
in any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail
is strictly forbidden.

LMAX Limited is regulated by the Financial Conduct Authority under
the UK laws, which differ from Australian law. We are exempt from the
requirement to hold an Australian financial services licence under the
Corporations Act 2001 (Cth) (Act) in respect of the financial services
we offer to you. We only offer our services to Australian clients who are
"wholesale clients" as defined under the Act. We may provide services in
Canada as an exempt international advisor. Consequently we may only
provide such services to clients who meet the "Permitted Client" criteria.
We are not a dealer in Canada.

LMAX Limited operates a multilateral trading facility. LMAX Limited is
authorised and regulated by the Financial Conduct Authority (firm
registration number 509778) and is a company registered in England
and Wales (number 6505809). Our registered address is Yellow
Building, 1A Nicholas Road, London, W11 4AN.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/c2e489c9/attachment.htm>

From pspacek at redhat.com  Thu Mar 27 16:51:23 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Thu, 27 Mar 2014 17:51:23 +0100
Subject: [Freeipa-users] authenticate samba 3 or 4 with freeipa
In-Reply-To: <22036664.121131.1395927382024.JavaMail.zimbra@chemaxon.com>
References: <22036664.121131.1395927382024.JavaMail.zimbra@chemaxon.com>
Message-ID: <5334570B.1040103@redhat.com>

On 27.3.2014 14:36, Sandor Juhasz wrote:
> Hello,
>
> what is the best practice to authenticate samba file sharing with freeipa as auth service.
> Either version 3 or 4 of samba is fine, as we are looking for this only for filesharing and not
> domain service.
> Our ipa service is hosted on CentOS 6.5.
> The samba service is preferred to be hosted on Ubuntu Precise (12.04), later the new LTS.
>
> Found 3 methods, but all seem to have their issues.
>
>
>      1. LDAP, ldapsam passdb backend. -> needs ldap schema modification to include fields (sambaSAMAccount, sambaGroupMapping, samabaSID) and have IPA populate those with dna plugin
>      2. IPA, ipasam passdb backend -> did not find a working version from ipasam.so for ubuntu, mostly i did not find any
The only how-to I'm aware of is:
http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/

If you insist on Ubuntu you need to get ipasam somewhere, most likely to 
compile it yourself.

Let us know if you are going to compile it, we can provide you some guidance.

See the thread 'IPA - Samba / Redmine / Disable Kerberos?'.

-- 
Petr^2 Spacek



From rcritten at redhat.com  Thu Mar 27 18:02:05 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Thu, 27 Mar 2014 14:02:05 -0400
Subject: [Freeipa-users] Try to re-import self sign cert fail after used
 3rd paty cert
In-Reply-To: <CAELz9dsfOuQuNvJoXKof6kaEWNxZBD0m_cdH1OZUqGU-MqaKqA@mail.gmail.com>
References: <CAELz9dsfOuQuNvJoXKof6kaEWNxZBD0m_cdH1OZUqGU-MqaKqA@mail.gmail.com>
Message-ID: <5334679D.2030404@redhat.com>

barrykfl at gmail.com wrote:
> Dear all:
>
> I did change usin g 3rd party cert and now i tried to reimport the
> orginal self sign cert i backup before all in p12 format.
>
> Server-cert,p12 and ipacert.p12 ....i follow here and import successful.
>
> BUT it show error during restart httpd that say untrust source. even i
> added to  "NSSEnforceValidCerts off" httpd worked but web site unable to
> access,  Any where i missed that i must make it trust again./
> Also i tried 2nd way .... ipa-server-certinstall -w --http_pin=1234 ( i
> backup p12 's password )  Server-cert.p12 but say incorrect password
>
> it seem that the pin file txt inside is encrypted and not as same as the
> password i created when  in the Server-cert.p12
>
> any idea ?
>
> 7 23:58:19 2014] [error] SSL Library Error: -8172 Certificate is signed
> by an untrusted issuer
> [Thu Mar 27 23:58:19 2014] [error] Unable to verify certificate
> 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the server
> can start until the problem can be resolved.

It may be that the IPA CA isn't in the database.

certutil -L -d /etc/httpd/alias

Look for '$REALM IPA CA'

If it isn't there you can add it with:

certutil -A -n '$REALM IPA CA' -d /etc/httpd/alias -t CT,C,C -a -i 
/etc/ipa/ca.crt

rob



From tmaugh at boingo.com  Thu Mar 27 18:58:11 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Thu, 27 Mar 2014 18:58:11 +0000
Subject: [Freeipa-users] HELP
Message-ID: <469632dc91a34c669e3625a44cbf16e5@BY2PR03MB176.namprd03.prod.outlook.com>

My Master IPA server has been lost,


My replica is still up and functioning.


what is the best way to proceed?


Do I rebuild my master and add it has a replica?


how do I get my master back in line with my IPA env?


the Master needs to be rebuilt from scratch


red hat 6.5 latest version of IPA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/8758bcc0/attachment.htm>

From natxo.asenjo at gmail.com  Thu Mar 27 19:37:09 2014
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Thu, 27 Mar 2014 20:37:09 +0100
Subject: [Freeipa-users] HELP
In-Reply-To: <469632dc91a34c669e3625a44cbf16e5@BY2PR03MB176.namprd03.prod.outlook.com>
References: <469632dc91a34c669e3625a44cbf16e5@BY2PR03MB176.namprd03.prod.outlook.com>
Message-ID: <CAHBEJzVm71KH=8s=_eRxYnoGsb5XBHymuVuxz1kGG3CPSU9CrA@mail.gmail.com>

On Thu, Mar 27, 2014 at 7:58 PM, Todd Maugh <tmaugh at boingo.com> wrote:

>  My Master IPA server has been lost,
>
>
>  My replica is still up and functioning.
>
>
>  what is the best way to proceed?
>
>
>  Do I rebuild my master and add it has a replica?
>
>
>  how do I get my master back in line with my IPA env?
>
>
>  the Master needs to be rebuilt from scratch
>
>
>  red hat 6.5 latest version of IPA
>

Just a quick question: is this a production network with real business in
risk? Or is this a test lab?

To answer your questions: I guess that it depends on whether the 2nd master
(in ipa all domain controllers are multimaster) has a copy of the CA too.
If it does then yes, you can rebuild it and create a replica.

If the domain controller does not have a copy of the CA, well, I am not
really sure at this point.

-- 
regards,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/2620a200/attachment.htm>

From rcritten at redhat.com  Thu Mar 27 19:47:18 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Thu, 27 Mar 2014 15:47:18 -0400
Subject: [Freeipa-users] HELP
In-Reply-To: <469632dc91a34c669e3625a44cbf16e5@BY2PR03MB176.namprd03.prod.outlook.com>
References: <469632dc91a34c669e3625a44cbf16e5@BY2PR03MB176.namprd03.prod.outlook.com>
Message-ID: <53348046.3080707@redhat.com>

Todd Maugh wrote:
> My Master IPA server has been lost,
>
>
> My replica is still up and functioning.
>
>
> what is the best way to proceed?
>
>
> Do I rebuild my master and add it has a replica?
>
>
> how do I get my master back in line with my IPA env?
>
>
> the Master needs to be rebuilt from scratch
>
>
> red hat 6.5 latest version of IPA

Is the replica running the CA? If not things will get very complicated.

See http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master

The replica has a replication agreement with the master that is now gone 
so you'll want to delete that agreement using ipa-replica-manage. But 
yes, once the new host is ready, create it as a new replica.

rob



From stijn.deweirdt at ugent.be  Thu Mar 27 20:35:50 2014
From: stijn.deweirdt at ugent.be (Stijn De Weirdt)
Date: Thu, 27 Mar 2014 21:35:50 +0100
Subject: [Freeipa-users] writing IPA plugin
Message-ID: <53348BA6.2080403@ugent.be>

hi all,

i'm trying to write my own FreeIPA plugin (for frontend cli usage), and 
so far so good, but i'm stuck on 2 issues:
- is it possible to have the plugin use a dedicated or additional log 
file? i can manipulate the log manager, but maybe there's a proper API 
in freeipa for it; similar to the log_file_name in 
ipapython.admin.AdminTool classes

- i want to exit the plugin on certain error conditions and want to exit 
with non-zero exitcode. how can this be done?

many thanks,

stijn



From rcritten at redhat.com  Thu Mar 27 20:43:20 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Thu, 27 Mar 2014 16:43:20 -0400
Subject: [Freeipa-users] writing IPA plugin
In-Reply-To: <53348BA6.2080403@ugent.be>
References: <53348BA6.2080403@ugent.be>
Message-ID: <53348D68.20308@redhat.com>

Stijn De Weirdt wrote:
> hi all,
>
> i'm trying to write my own FreeIPA plugin (for frontend cli usage), and
> so far so good, but i'm stuck on 2 issues:
> - is it possible to have the plugin use a dedicated or additional log
> file? i can manipulate the log manager, but maybe there's a proper API
> in freeipa for it; similar to the log_file_name in
> ipapython.admin.AdminTool classes
>
> - i want to exit the plugin on certain error conditions and want to exit
> with non-zero exitcode. how can this be done?

Which side do you want to do the logging on, the server or client side?

The return value is controlled by the exception raised. There is an rval 
attribute defined in the exception.

rob



From john.obaterspok at gmail.com  Thu Mar 27 20:47:09 2014
From: john.obaterspok at gmail.com (John Obaterspok)
Date: Thu, 27 Mar 2014 21:47:09 +0100
Subject: [Freeipa-users] kerberized vsftpd login problem
In-Reply-To: <CAOscVd+vPYNQZ8PU1ckB9eBSGxJftmU8v5uMPfgUBP1ybi_AMA@mail.gmail.com>
References: <CAOscVd+vPYNQZ8PU1ckB9eBSGxJftmU8v5uMPfgUBP1ybi_AMA@mail.gmail.com>
Message-ID: <CAOscVdLNGEwZ1Z3QKub8qWMLTA-SY=8uUnKuxN5eYcTfGqicsA@mail.gmail.com>

2014-03-23 19:45 GMT-04:00  Dmitri Pal <dpal at redhat.com>
> 2014-03-23 9:01 GMT+01:00 John Obaterspok <john.obaterspok at gmail.com>:
> >
> > Hello,
> >
> > How do I get vsftpd login to work with an existing ticket?
> > I've added ftp as an identity service (ftp/ipaserver.my.lan at MY.LAN)
> > Is there anything else I need to do to allow ftp login to vsftpd?
>
> What ftp client and server are you using?
> Do you know whether they are actually supporting Kerberos?
> May be consider other tools like scp instead?

I'm using vsftpd with default settings in Fedora 20 + ftp client from
krb5-appl-clients. vsftpd is linked to pam, gssapi_krb5, and more.
/etc/pam.d/vsftpd looks like this:

#%PAM-1.0
session    optional     pam_keyinit.so    force revoke
auth       required     pam_listfile.so item=user sense=deny
file=/etc/vsftpd/ftpusers onerr=succeed
auth       required     pam_shells.so
auth       include      password-auth
account    include      password-auth
session    required     pam_loginuid.so
session    include      password-auth

 Perhaps I need to change something in the pam file in order to allow sso?

-- john



From stijn.deweirdt at ugent.be  Thu Mar 27 20:51:16 2014
From: stijn.deweirdt at ugent.be (Stijn De Weirdt)
Date: Thu, 27 Mar 2014 21:51:16 +0100
Subject: [Freeipa-users] writing IPA plugin
In-Reply-To: <53348D68.20308@redhat.com>
References: <53348BA6.2080403@ugent.be> <53348D68.20308@redhat.com>
Message-ID: <53348F44.5010905@ugent.be>

hi rob,

>> i'm trying to write my own FreeIPA plugin (for frontend cli usage), and
>> so far so good, but i'm stuck on 2 issues:
>> - is it possible to have the plugin use a dedicated or additional log
>> file? i can manipulate the log manager, but maybe there's a proper API
>> in freeipa for it; similar to the log_file_name in
>> ipapython.admin.AdminTool classes
>>
>> - i want to exit the plugin on certain error conditions and want to exit
>> with non-zero exitcode. how can this be done?
>
> Which side do you want to do the logging on, the server or client side?
the client side
>
> The return value is controlled by the exception raised. There is an rval
> attribute defined in the exception.

thanks!

stijn

>
> rob
>
>



From stijn.deweirdt at ugent.be  Thu Mar 27 21:39:15 2014
From: stijn.deweirdt at ugent.be (Stijn De Weirdt)
Date: Thu, 27 Mar 2014 22:39:15 +0100
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <20140325074341.GE3487@redhat.com>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
	<53308B05.1040009@ugent.be> <20140324195326.GA3487@redhat.com>
	<53308DE4.80609@redhat.com> <20140324204722.GB3487@redhat.com>
	<5330A946.7010800@ugent.be> <20140325063232.GC3487@redhat.com>
	<53313066.4080001@ugent.be> <20140325074341.GE3487@redhat.com>
Message-ID: <53349A83.6040107@ugent.be>

hi alexander,

>> ity would be good anyway to have a script that checks all hosts that
>> have not enrolled yet how old the issued password is (even after
>> expiration). very useful to spot the state of ongoing deployments and
>> to spot problems. how can one obtain the creation time of the
>> password? fetch the timestamp from LDAP or is there a nice ipa API for
>> it?
> Since host object is a Kerberos principal, it has krbLastSuccessfulAuth
> and krbLastPwdChange attributes.
>
> ipa host-show host.name --all --raw
>
> will give you their values.
>
> # ipa host-show `hostname` --all --raw |grep krbLast
>    krbLastPwdChange: 20140213123016Z
>    krbLastSuccessfulAuth: 20140325073031Z
>
>
this does not seem to work on a host that has the random password set 
(or set a few times), but no keytab was created or other form of 
authentication:
> ipa host-show test.test --all --raw |grep -E 'krb|has_'
>   has_password: True
>   has_keytab: False
>   krbExtraData: AAI3mDRTcm9vdC9hZG1pbkB
>   krbPrincipalName: host/test.test at TEST
>   objectClass: krbprincipalaux
>   objectClass: krbprincipal

(this is freeipa 3.3.3 on rhel7 beta)

stijn



From rcritten at redhat.com  Fri Mar 28 01:28:18 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Thu, 27 Mar 2014 21:28:18 -0400
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <53349A83.6040107@ugent.be>
References: <53306815.8070006@ugent.be>
	<53306B44.60608@redhat.com>	<53308B05.1040009@ugent.be>
	<20140324195326.GA3487@redhat.com>	<53308DE4.80609@redhat.com>
	<20140324204722.GB3487@redhat.com>	<5330A946.7010800@ugent.be>
	<20140325063232.GC3487@redhat.com>	<53313066.4080001@ugent.be>
	<20140325074341.GE3487@redhat.com> <53349A83.6040107@ugent.be>
Message-ID: <5334D032.3020209@redhat.com>

Stijn De Weirdt wrote:
> hi alexander,
>
>>> ity would be good anyway to have a script that checks all hosts that
>>> have not enrolled yet how old the issued password is (even after
>>> expiration). very useful to spot the state of ongoing deployments and
>>> to spot problems. how can one obtain the creation time of the
>>> password? fetch the timestamp from LDAP or is there a nice ipa API for
>>> it?
>> Since host object is a Kerberos principal, it has krbLastSuccessfulAuth
>> and krbLastPwdChange attributes.
>>
>> ipa host-show host.name --all --raw
>>
>> will give you their values.
>>
>> # ipa host-show `hostname` --all --raw |grep krbLast
>>    krbLastPwdChange: 20140213123016Z
>>    krbLastSuccessfulAuth: 20140325073031Z
>>
>>
> this does not seem to work on a host that has the random password set
> (or set a few times), but no keytab was created or other form of
> authentication:
>> ipa host-show test.test --all --raw |grep -E 'krb|has_'
>>   has_password: True
>>   has_keytab: False
>>   krbExtraData: AAI3mDRTcm9vdC9hZG1pbkB
>>   krbPrincipalName: host/test.test at TEST
>>   objectClass: krbprincipalaux
>>   objectClass: krbprincipal
>
> (this is freeipa 3.3.3 on rhel7 beta)

Right, because it doesn't have Kerberos credentials yet, just a 
password. We apparently don't set any dates when setting only the host 
password. Which also means password policy probably wouldn't apply 
correctly even if you were able to set one. And I guess the question is, 
should we?

If so we'd need to always add the krbPrincipalAux objectclass and set 
this value in the password plugin.

rob



From dpal at redhat.com  Fri Mar 28 02:01:55 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Thu, 27 Mar 2014 22:01:55 -0400
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <5334D032.3020209@redhat.com>
References: <53306815.8070006@ugent.be>
	<53306B44.60608@redhat.com>	<53308B05.1040009@ugent.be>
	<20140324195326.GA3487@redhat.com>	<53308DE4.80609@redhat.com>
	<20140324204722.GB3487@redhat.com>	<5330A946.7010800@ugent.be>
	<20140325063232.GC3487@redhat.com>	<53313066.4080001@ugent.be>
	<20140325074341.GE3487@redhat.com> <53349A83.6040107@ugent.be>
	<5334D032.3020209@redhat.com>
Message-ID: <5334D813.3090501@redhat.com>

On 03/27/2014 09:28 PM, Rob Crittenden wrote:
> Stijn De Weirdt wrote:
>> hi alexander,
>>
>>>> ity would be good anyway to have a script that checks all hosts that
>>>> have not enrolled yet how old the issued password is (even after
>>>> expiration). very useful to spot the state of ongoing deployments and
>>>> to spot problems. how can one obtain the creation time of the
>>>> password? fetch the timestamp from LDAP or is there a nice ipa API for
>>>> it?
>>> Since host object is a Kerberos principal, it has krbLastSuccessfulAuth
>>> and krbLastPwdChange attributes.
>>>
>>> ipa host-show host.name --all --raw
>>>
>>> will give you their values.
>>>
>>> # ipa host-show `hostname` --all --raw |grep krbLast
>>>    krbLastPwdChange: 20140213123016Z
>>>    krbLastSuccessfulAuth: 20140325073031Z
>>>
>>>
>> this does not seem to work on a host that has the random password set
>> (or set a few times), but no keytab was created or other form of
>> authentication:
>>> ipa host-show test.test --all --raw |grep -E 'krb|has_'
>>>   has_password: True
>>>   has_keytab: False
>>>   krbExtraData: AAI3mDRTcm9vdC9hZG1pbkB
>>>   krbPrincipalName: host/test.test at TEST
>>>   objectClass: krbprincipalaux
>>>   objectClass: krbprincipal
>>
>> (this is freeipa 3.3.3 on rhel7 beta)
>
> Right, because it doesn't have Kerberos credentials yet, just a 
> password. We apparently don't set any dates when setting only the host 
> password. Which also means password policy probably wouldn't apply 
> correctly even if you were able to set one. And I guess the question 
> is, should we?
>
> If so we'd need to always add the krbPrincipalAux objectclass and set 
> this value in the password plugin.
>
> rob
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

IMO we should not treat the OTP we set for the host enrollment as a 
kerberos password.
I would rather record a time of the creation and validity period when 
the password is set in two new attributes. The validity period should be 
optional and if not provided copied from a system wide policy that can 
be set by default to say 10 min. When we do authentication with OTP we 
should check whether we are already beyond the point when the OTP is 
valid and fail enrollment.  When we validate and clear OTP we do not 
need to change these two attributes, they contain valuable info that 
might be queried later.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From dpal at redhat.com  Fri Mar 28 02:11:48 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Thu, 27 Mar 2014 22:11:48 -0400
Subject: [Freeipa-users] kerberized vsftpd login problem
In-Reply-To: <CAOscVdLNGEwZ1Z3QKub8qWMLTA-SY=8uUnKuxN5eYcTfGqicsA@mail.gmail.com>
References: <CAOscVd+vPYNQZ8PU1ckB9eBSGxJftmU8v5uMPfgUBP1ybi_AMA@mail.gmail.com>
	<CAOscVdLNGEwZ1Z3QKub8qWMLTA-SY=8uUnKuxN5eYcTfGqicsA@mail.gmail.com>
Message-ID: <5334DA64.1070209@redhat.com>

On 03/27/2014 04:47 PM, John Obaterspok wrote:
> 2014-03-23 19:45 GMT-04:00  Dmitri Pal<dpal at redhat.com>
>> 2014-03-23 9:01 GMT+01:00 John Obaterspok<john.obaterspok at gmail.com>:
>>> Hello,
>>>
>>> How do I get vsftpd login to work with an existing ticket?
>>> I've added ftp as an identity service (ftp/ipaserver.my.lan at MY.LAN)
>>> Is there anything else I need to do to allow ftp login to vsftpd?
>> What ftp client and server are you using?
>> Do you know whether they are actually supporting Kerberos?
>> May be consider other tools like scp instead?
> I'm using vsftpd with default settings in Fedora 20 + ftp client from
> krb5-appl-clients. vsftpd is linked to pam, gssapi_krb5, and more.
> /etc/pam.d/vsftpd looks like this:
>
> #%PAM-1.0
> session    optional     pam_keyinit.so    force revoke
> auth       required     pam_listfile.so item=user sense=deny
> file=/etc/vsftpd/ftpusers onerr=succeed
> auth       required     pam_shells.so
> auth       include      password-auth
> account    include      password-auth
> session    required     pam_loginuid.so
> session    include      password-auth
>
>   Perhaps I need to change something in the pam file in order to allow sso?
>
> -- john

If you want SSO the ftp server should be configured to use GSSAPI and 
not use PAM (or fail over to PAM if client does not have a ticket). A 
search of the man pages for vsftpd did not render such option. I suspect 
it is either undocumented or some other Kerberos enables ftp server 
needs to be used.
Does krb-appl package provide one?


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From prmarino1 at gmail.com  Fri Mar 28 03:05:03 2014
From: prmarino1 at gmail.com (Paul Robert Marino)
Date: Thu, 27 Mar 2014 23:05:03 -0400
Subject: [Freeipa-users] kerberized vsftpd login problem
In-Reply-To: <5334DA64.1070209@redhat.com>
Message-ID: <5334e6df.e220ec0a.0e8d.ffffc0f3@mx.google.com>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140327/75acd8d3/attachment.htm>

From barrykfl at gmail.com  Fri Mar 28 03:33:47 2014
From: barrykfl at gmail.com (barrykfl at gmail.com)
Date: Fri, 28 Mar 2014 11:33:47 +0800
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <5334D813.3090501@redhat.com>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
	<53308B05.1040009@ugent.be> <20140324195326.GA3487@redhat.com>
	<53308DE4.80609@redhat.com> <20140324204722.GB3487@redhat.com>
	<5330A946.7010800@ugent.be> <20140325063232.GC3487@redhat.com>
	<53313066.4080001@ugent.be> <20140325074341.GE3487@redhat.com>
	<53349A83.6040107@ugent.be> <5334D032.3020209@redhat.com>
	<5334D813.3090501@redhat.com>
Message-ID: <CAELz9duJGTp0Kh=eyJJr2bFP6rhuc2FxTb17vhCbF7dQsWc=iw@mail.gmail.com>

Found a error today. when browse the cert serices ..is it realte to dog tag
system ...how to restart ?

Certificate operation cannot be completed: Unable to communicate with CMS
(Not Found)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140328/6c4aaced/attachment.htm>

From sjuhasz at chemaxon.com  Fri Mar 28 08:56:53 2014
From: sjuhasz at chemaxon.com (Sandor Juhasz)
Date: Fri, 28 Mar 2014 09:56:53 +0100 (CET)
Subject: [Freeipa-users] authenticate samba 3 or 4 with freeipa
In-Reply-To: <5334570B.1040103@redhat.com>
References: <22036664.121131.1395927382024.JavaMail.zimbra@chemaxon.com>
	<5334570B.1040103@redhat.com>
Message-ID: <2068400394.73207.1395997013774.JavaMail.zimbra@chemaxon.com>

Hello, 

i am ok to compile it myself, looking for source code. I hope that way i will be able to avoid messing 
around with the ldap tree. Any help/documentation is appreciated. 


Thanks. 

s 

----- Original Message -----

From: "Petr Spacek" <pspacek at redhat.com> 
To: freeipa-users at redhat.com 
Sent: Thursday, March 27, 2014 5:51:23 PM 
Subject: Re: [Freeipa-users] authenticate samba 3 or 4 with freeipa 

On 27.3.2014 14:36, Sandor Juhasz wrote: 
> Hello, 
> 
> what is the best practice to authenticate samba file sharing with freeipa as auth service. 
> Either version 3 or 4 of samba is fine, as we are looking for this only for filesharing and not 
> domain service. 
> Our ipa service is hosted on CentOS 6.5. 
> The samba service is preferred to be hosted on Ubuntu Precise (12.04), later the new LTS. 
> 
> Found 3 methods, but all seem to have their issues. 
> 
> 
> 1. LDAP, ldapsam passdb backend. -> needs ldap schema modification to include fields (sambaSAMAccount, sambaGroupMapping, samabaSID) and have IPA populate those with dna plugin 
> 2. IPA, ipasam passdb backend -> did not find a working version from ipasam.so for ubuntu, mostly i did not find any 
The only how-to I'm aware of is: 
http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/ 

If you insist on Ubuntu you need to get ipasam somewhere, most likely to 
compile it yourself. 

Let us know if you are going to compile it, we can provide you some guidance. 

See the thread 'IPA - Samba / Redmine / Disable Kerberos?'. 

-- 
Petr^2 Spacek 

_______________________________________________ 
Freeipa-users mailing list 
Freeipa-users at redhat.com 
https://www.redhat.com/mailman/listinfo/freeipa-users 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140328/846c3ad9/attachment.htm>

From pspacek at redhat.com  Fri Mar 28 11:32:25 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Fri, 28 Mar 2014 12:32:25 +0100
Subject: [Freeipa-users] authenticate samba 3 or 4 with freeipa:
 building ipasam.so on Ubuntu
In-Reply-To: <2068400394.73207.1395997013774.JavaMail.zimbra@chemaxon.com>
References: <22036664.121131.1395927382024.JavaMail.zimbra@chemaxon.com>
	<5334570B.1040103@redhat.com>
	<2068400394.73207.1395997013774.JavaMail.zimbra@chemaxon.com>
Message-ID: <53355DC9.3050908@redhat.com>

On 28.3.2014 09:56, Sandor Juhasz wrote:
> Hello,
>
> i am ok to compile it myself, looking for source code. I hope that way i will be able to avoid messing
> around with the ldap tree. Any help/documentation is appreciated.

Basically, documentation on
http://www.freeipa.org/page/Contribute/Code and linked pages apply to your 
situation.

You will face dependency problems because you are going to build it on Ubuntu. 
Don't give up and persist :-)

I would recommend you a non-standard procedure:
- clone the git repo: $ git clone git://git.fedorahosted.org/git/freeipa.git
- enter the cloned tree: $ cd freeipa.git
- $ make version-update
-- This command will fail (for sure) because of dependency problems. However, 
it could be enough to proceed with ipasam build. You just need to generate 
version.h and similar "useless" files.

- Enter "daemons" sub-directory in the cloned tree: $ cd daemons
- $ autoreconf -fiv
- $ ./configure
- $ make

This should build freeipa.git/daemons/ipa-sam/.libs/ipasam.so library without 
building rest of FreeIPA so dependency problems should be limited only to this 
sub-tree.

Note that this procedure is completely untested.

Please let us know if it worked for you or not. I'm curious! :-)

Petr^2 Spacek

>
>
> Thanks.
>
> s
>
> ----- Original Message -----
>
> From: "Petr Spacek" <pspacek at redhat.com>
> To: freeipa-users at redhat.com
> Sent: Thursday, March 27, 2014 5:51:23 PM
> Subject: Re: [Freeipa-users] authenticate samba 3 or 4 with freeipa
>
> On 27.3.2014 14:36, Sandor Juhasz wrote:
>> Hello,
>>
>> what is the best practice to authenticate samba file sharing with freeipa as auth service.
>> Either version 3 or 4 of samba is fine, as we are looking for this only for filesharing and not
>> domain service.
>> Our ipa service is hosted on CentOS 6.5.
>> The samba service is preferred to be hosted on Ubuntu Precise (12.04), later the new LTS.
>>
>> Found 3 methods, but all seem to have their issues.
>>
>>
>> 1. LDAP, ldapsam passdb backend. -> needs ldap schema modification to include fields (sambaSAMAccount, sambaGroupMapping, samabaSID) and have IPA populate those with dna plugin
>> 2. IPA, ipasam passdb backend -> did not find a working version from ipasam.so for ubuntu, mostly i did not find any
> The only how-to I'm aware of is:
> http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/
>
> If you insist on Ubuntu you need to get ipasam somewhere, most likely to
> compile it yourself.
>
> Let us know if you are going to compile it, we can provide you some guidance.
>
> See the thread 'IPA - Samba / Redmine / Disable Kerberos?'.



From pspacek at redhat.com  Fri Mar 28 12:52:37 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Fri, 28 Mar 2014 13:52:37 +0100
Subject: [Freeipa-users] authenticate samba 3 or 4 with freeipa:
 building ipasam.so on Ubuntu
In-Reply-To: <53355DC9.3050908@redhat.com>
References: <22036664.121131.1395927382024.JavaMail.zimbra@chemaxon.com>	<5334570B.1040103@redhat.com>	<2068400394.73207.1395997013774.JavaMail.zimbra@chemaxon.com>
	<53355DC9.3050908@redhat.com>
Message-ID: <53357095.6010908@redhat.com>

On 28.3.2014 12:32, Petr Spacek wrote:
> On 28.3.2014 09:56, Sandor Juhasz wrote:
>> Hello,
>>
>> i am ok to compile it myself, looking for source code. I hope that way i
>> will be able to avoid messing
>> around with the ldap tree. Any help/documentation is appreciated.
>
> Basically, documentation on
> http://www.freeipa.org/page/Contribute/Code and linked pages apply to your
> situation.
>
> You will face dependency problems because you are going to build it on Ubuntu.
> Don't give up and persist :-)
>
> I would recommend you a non-standard procedure:
> - clone the git repo: $ git clone git://git.fedorahosted.org/git/freeipa.git
> - enter the cloned tree: $ cd freeipa.git
> - $ make version-update
> -- This command will fail (for sure) because of dependency problems. However,
> it could be enough to proceed with ipasam build. You just need to generate
> version.h and similar "useless" files.
>
> - Enter "daemons" sub-directory in the cloned tree: $ cd daemons
> - $ autoreconf -fiv
> - $ ./configure
> - $ make
>
> This should build freeipa.git/daemons/ipa-sam/.libs/ipasam.so library without
> building rest of FreeIPA so dependency problems should be limited only to this
> sub-tree.
>
> Note that this procedure is completely untested.
>
> Please let us know if it worked for you or not. I'm curious! :-)

I'm adding output from make running on my Fedora 20 so you can easily find 
include paths you need to cover by packages in your distro etc.

Enjoy :-)

-- 
Petr^2 Spacek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.log
Type: text/x-log
Size: 5512 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140328/c74a2767/attachment.bin>

From sabinranjit at lftechnology.com  Wed Mar 26 08:39:10 2014
From: sabinranjit at lftechnology.com (Sabin Ranjit)
Date: Wed, 26 Mar 2014 14:24:10 +0545
Subject: [Freeipa-users] cant authenticate using freeipa userid on
	ubuntu12.04
Message-ID: <5332922E.6060906@lftechnology.com>

hi,

i followed this page for the installation of freeipa client over the 
ubuntu 12.04 server.
http://www.redhat.com/archives/freeipa-users/2013-June/msg00091.html
everything seem to go as mentioned in the page. when i get at the 
freeipa server with the command ipa host-find
i can even see my ubuntu server listed there with "Keytab: True". The 
problem is that im not being able to authenticate with the username 
listed in the freeipa server.
if i try to run : "su ldapuserid" ubuntu errors "unknown id: ldapuserid"
i cant even ssh to the ubuntu server with the ldapuserid.

what can be the possible solutions?

please help. thanks.

regards,
sabin


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140326/3d6298a5/attachment.htm>

From rcritten at redhat.com  Fri Mar 28 13:24:40 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Fri, 28 Mar 2014 09:24:40 -0400
Subject: [Freeipa-users] Any coomand can extract the private of the
 freeipa domain
In-Reply-To: <CAELz9dsgiji+MFc8iD9XKbW_YDdPNFfEnEg9DU_hYh7RqMyoeQ@mail.gmail.com>
References: <CAELz9dsgiji+MFc8iD9XKbW_YDdPNFfEnEg9DU_hYh7RqMyoeQ@mail.gmail.com>
Message-ID: <53357818.8060400@redhat.com>

barrykfl at gmail.com wrote:
> i want to extract the private key of the self sign cert

The CA's database is in either /var/lib/pki/pki-tomcat/alias or 
/var/lib/pki-ca/alias depending on your version and distro.

I would not recommend doing anything with it directly.

rob



From rcritten at redhat.com  Fri Mar 28 13:26:54 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Fri, 28 Mar 2014 09:26:54 -0400
Subject: [Freeipa-users] cant authenticate using freeipa userid on
	ubuntu12.04
In-Reply-To: <5332922E.6060906@lftechnology.com>
References: <5332922E.6060906@lftechnology.com>
Message-ID: <5335789E.4050801@redhat.com>

Sabin Ranjit wrote:
> hi,
>
> i followed this page for the installation of freeipa client over the
> ubuntu 12.04 server.
> http://www.redhat.com/archives/freeipa-users/2013-June/msg00091.html
> everything seem to go as mentioned in the page. when i get at the
> freeipa server with the command ipa host-find
> i can even see my ubuntu server listed there with "Keytab: True". The
> problem is that im not being able to authenticate with the username
> listed in the freeipa server.
> if i try to run : "su ldapuserid" ubuntu errors "unknown id: ldapuserid"
> i cant even ssh to the ubuntu server with the ldapuserid.
>
> what can be the possible solutions?

I would check the sssd logs, and potentially increase debug logging.

rob



From devel at jasonwoods.me.uk  Fri Mar 28 13:50:08 2014
From: devel at jasonwoods.me.uk (Jason Woods)
Date: Fri, 28 Mar 2014 13:50:08 +0000
Subject: [Freeipa-users] authenticate samba 3 or 4 with freeipa:
	building ipasam.so on Ubuntu
In-Reply-To: <53355DC9.3050908@redhat.com>
References: <22036664.121131.1395927382024.JavaMail.zimbra@chemaxon.com>
	<5334570B.1040103@redhat.com>
	<2068400394.73207.1395997013774.JavaMail.zimbra@chemaxon.com>
	<53355DC9.3050908@redhat.com>
Message-ID: <15930145-D35A-4032-9273-8218B6515EDA@jasonwoods.me.uk>

Hi
(Apologies - resending to the list - I'm so used to the Reply-To already set but it appears not to be here my bad.)

> On 28 Mar 2014, at 11:32, Petr Spacek <pspacek at redhat.com> wrote:
> 
> Please let us know if it worked for you or not. I'm curious! :-)

I'm pretty curious too.

I have RHEL 6.5 with samba authenticating with IPA using ipasam.so. I needed to add two patches though to 3.0 to fix 'valid users' group resolution and also performance. They're merged into master and 3.3  and will be in RHEL 7.

Apart from the patching it was easy to do - just needed ipa-server and ipa-server-adtrust installed and setup and it did all the config for me (the adtrust part sets up samba with ipasam.so for you).

Problem is running ipasam.so without the ipa-server locally - is how to get it so the host can see ipaNTHash in the schema to check password. If ipa-server is local the host has access, otherwise it doesn't.

So be good to find out what aci or service principal stuff makes that available in an elegant and secure way.

Jason



From mkosek at redhat.com  Fri Mar 28 14:06:45 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Fri, 28 Mar 2014 15:06:45 +0100
Subject: [Freeipa-users] Announcing FreeIPA 3.3.5
Message-ID: <533581F5.104@redhat.com>

The FreeIPA team is proud to announce FreeIPA v3.3.5!

It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19 and
Fedora 20 builds are already on their way to updates-testing repo.

== Highlights in 3.3.5 ==
=== Enhancements ===
* DNS classless support for reverse domains

=== Bug fixes ===
* Lockout plugin was not applied to users with default password policy
* Migration plugin did not add users to default group (ipausers)
* AD Trust subdomains were not automatically fetched by trust-add command
* When installing Dogtag 10 replica with a CA from a Dogtag 9 based replica,
the ipa-replica-conncheck did not check if Dogtag 9 DS port is open
* When installing Dogtag 10 replica with a CA from a Dogtag 9 based replica, CA
database was not updated resulting in limited functionality of the CA
* Trust could not be added with --shared-secret option
* Active AD Trust subdomain ID range could be deleted
* FreeIPA client returned invalid group membership info when multiple AD Trusts
were configured
* /ca/ee/ca/profileSubmit proxy URI was added to allow cloning of PKI 10.1.1
and newer
* ... and numerous other small fixes

=== Test improvements ===
* Many fixes related to Active Directory integration tests

== Upgrading ==
An IPA server can be upgraded simply by installing updated rpms. The server
does not need to be shut down in advance.

Please note that if you are doing the upgrade in special environment (e.g.
FedUp) which does not allow running the LDAP server during upgrade process,
upgrade scripts need to be run manually after the first boot:
# ipa-upgradeconfig
# ipa-ldap-updater --upgrade

Also note that the performance improvements require an extended set of indexes
to be configured. RPM update for an IPA server with a excessive number of users
may require several minutes to finish.

If you have multiple servers you may upgrade them one at a time. It is expected
that all servers will be upgraded in a relatively short period (days or weeks,
not months). They should be able to co-exist peacefully but new features will
not be available on old servers and enrolling a new client against an old
server will result in the SSH keys not being uploaded.

Downgrading a server once upgraded is not supported.

Upgrading from 2.2.0 and later versions is supported. Upgrading from previous
versions is not supported and has not been tested.

An enrolled client does not need the new packages installed unless you want to
re-enroll it. SSH keys for already installed clients are not uploaded, you will
have to re-enroll the client or manually upload the keys.

== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users mailing
list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel
on Freenode.

== Detailed Changelog since 3.3.4 ==
=== Adam Misnyovszki (1) ===
* Too big font in input fields

=== Alexander Bokovoy (10) ===
* bindinstance: make sure zone manager is initialized in add_master_dns_records
* ipa-kdb: in case of delegation use original client's database entry, not the
proxy
* ipa-kdb: make sure we don't produce MS-PAC in case of authdata flag cleared
by admin
* trustdomain_find: make sure we skip short entries when --pkey-only is specified
* trust: make sure we always discover topology of the forest trust
* ipaserver/dcerpc: catch the case of insuffient permissions when establishing
trust
* fix filtering of subdomain-based trust users
* ipa-kdb: do not fetch client principal if it is the same as existing entry
* ipaserver/dcerpc: make sure to always return unicode SID of the trust domain
* trust: do not fetch subdomains in case shared secret was used to set up the trust

=== Jan Cholasta (2) ===
* Include LDFLAGS provided by rpmbuild in global LDFLAGS in the spec file.
* Remove sourcehostcategory from the default HBAC rule.

=== Jason Woods (1) ===
* ipa-sam: cache gid to sid and uid to sid requests in idmap cache

=== Martin Basti (3) ===
* DNS classless support for reverse domains
* DNS tests for classless reverse domains
* Fix test_host_plugin for DNS Classless Reverse zones

=== Martin Kosek (10) ===
* Fallback to global policy in ipa-lockout plugin
* ipa-lockout: do not fail when default realm cannot be read
* Migration does not add users to default group
* Avoid passing non-terminated string to is_master_host
* ipa-replica-install never checks for 7389 port
* Fix idrange unit test failure
* Update Dogtag 9 database during replica installation
* Proxy PKI clone /ca/ee/ca/profileSubmit URI
* Add requires for pki-core-10.0.7-1.fc19
* Become IPA 3.3.5

=== Misnyovszki Adam (1) ===
* Permission MOD command fix

=== Petr Viktorin (12) ===
* integration tests OpenSSHTransport: Expand tilde to home in root_ssh_key_filename
* ipa tool: Print the name of the server we are connecting to with -v
* test_integration.config: Fix crash in to_env when no replica is defined
* test_integration.config: Do not save the input environment
* test_integration.config: Use a more declarative approach to test-wide settings
* test_integration.config: Do not store the index in Domain and Host objects
* test_integration.config: Load/store from/to dicts
* test_integration.config: Add environment variables for JSON/YAML
* ipa-test-config: Add --json and --yaml output options
* test_integration.config: Convert some text values to str
* Add tests for integration test configuration
* test_integration.tasks: Do not fail cleanup if backup directory does not exist

=== Sumit Bose (1) ===
* extdom: do not return results from the wrong domain

=== Tomas Babej (13) ===
* ipatests: test_legacy_clients: Change "test group" to "testgroup"
* ipatests: Add records for all hosts in master's domain
* ipatests: Run restoring backup files and restoring their context in one session
* ipatests: legacy_clients: Test legacy clients with non-posix trust
* ipatests: Perform a connection test before preparing the client
* ipatests: Make sure we re-kinit as admin before adding the disabledipauser
* ipatests: Stop sssd service before deleting the cache
* ipatests: Add test cases for subdomain users on legacy clients
* ipatests: Change expected home directories returned by getent
* ipatests: Do not require group name resolution for the non-posix tests
* ipatests: Fix incorrect order of operations when restoring backup
* Prohibit deletion of active subdomain range
* ipatests: test_trust: Change expected home directories for posix users



From abokovoy at redhat.com  Fri Mar 28 14:15:29 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Fri, 28 Mar 2014 16:15:29 +0200
Subject: [Freeipa-users] authenticate samba 3 or 4 with freeipa:
 building ipasam.so on Ubuntu
In-Reply-To: <15930145-D35A-4032-9273-8218B6515EDA@jasonwoods.me.uk>
References: <22036664.121131.1395927382024.JavaMail.zimbra@chemaxon.com>
	<5334570B.1040103@redhat.com>
	<2068400394.73207.1395997013774.JavaMail.zimbra@chemaxon.com>
	<53355DC9.3050908@redhat.com>
	<15930145-D35A-4032-9273-8218B6515EDA@jasonwoods.me.uk>
Message-ID: <20140328141529.GL21211@redhat.com>

On Fri, 28 Mar 2014, Jason Woods wrote:
>Hi
>(Apologies - resending to the list - I'm so used to the Reply-To already set but it appears not to be here my bad.)
>
>> On 28 Mar 2014, at 11:32, Petr Spacek <pspacek at redhat.com> wrote:
>>
>> Please let us know if it worked for you or not. I'm curious! :-)
>
>I'm pretty curious too.
>
>I have RHEL 6.5 with samba authenticating with IPA using ipasam.so. I
>needed to add two patches though to 3.0 to fix 'valid users' group
>resolution and also performance. They're merged into master and 3.3
>and will be in RHEL 7.
>
>Apart from the patching it was easy to do - just needed ipa-server and
>ipa-server-adtrust installed and setup and it did all the config for me
>(the adtrust part sets up samba with ipasam.so for you).
>
>Problem is running ipasam.so without the ipa-server locally - is how to
>get it so the host can see ipaNTHash in the schema to check password.
>If ipa-server is local the host has access, otherwise it doesn't.
>
>So be good to find out what aci or service principal stuff makes that
>available in an elegant and secure way.
We have https://fedorahosted.org/freeipa/ticket/3999 for documenting it
all and may be creating a simple configuration tool.

Timing is not yet defined.

-- 
/ Alexander Bokovoy



From genadipost at gmail.com  Fri Mar 28 14:49:10 2014
From: genadipost at gmail.com (Genadi Postrilko)
Date: Fri, 28 Mar 2014 17:49:10 +0300
Subject: [Freeipa-users] Understanding role of the certificate in client
 - server communication.
In-Reply-To: <20140319085646.GA18421@redhat.com>
References: <CAPP+0vLBMLAe05sfN7V=Z-NJ1iDkZFYX7wQQvoiZXnuzaUgTEg@mail.gmail.com>
	<5328C79A.6070004@redhat.com>
	<CAPP+0vLmvo8_q6ajBRGgWpVd0v3fb1M9E2uMjXAk8nu+RT-qag@mail.gmail.com>
	<20140319085646.GA18421@redhat.com>
Message-ID: <CAPP+0vJPkVMPdnmoYaiT=fmKHhZpaP0kMzZ+X9=hdYaeorTS7w@mail.gmail.com>

Thank you for the answer.
Is the communication between IPA Client and Server HTTPS based? not just
SSL over TCP?
So is Kerberos? Does it have to be over HTTP? or its purely over TCP/UDP?


2014-03-19 10:56 GMT+02:00 Alexander Bokovoy <abokovoy at redhat.com>:

> On Wed, 19 Mar 2014, Genadi Postrilko wrote:
>
>> Thank you for the answer.
>> Sory if i lack the knowledge, but why SSL is needed when using kerberos?
>> Kerberos is based on 3th party that is trusted, why there is a need for
>> public key encryption?
>>
> Using Kerberos only, without asking for integrity and confidentiality
> services,  without channel bindings to the outer encryption, is prone to
> MITM even with valid TLS channels.
>
> Use of certificates allows to perform mutual authentication at the SSL
> level and later perform channel bindings of the tunnelled Kerberos
> communication.
>
> Note that Kerberos over HTTP is weak without transport level security.
> HTTP authentication per se is independent of the transport.
>
> For more details you can look at Joe Orton's talk at ApacheCon'2008:
> http://www.apachecon.com/eu2008/program/materials/kerb-sso-http.pdf
> --
> / Alexander Bokovoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140328/9470621e/attachment.htm>

From abokovoy at redhat.com  Fri Mar 28 15:07:54 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Fri, 28 Mar 2014 17:07:54 +0200
Subject: [Freeipa-users] Understanding role of the certificate in client
 - server communication.
In-Reply-To: <CAPP+0vJPkVMPdnmoYaiT=fmKHhZpaP0kMzZ+X9=hdYaeorTS7w@mail.gmail.com>
References: <CAPP+0vLBMLAe05sfN7V=Z-NJ1iDkZFYX7wQQvoiZXnuzaUgTEg@mail.gmail.com>
	<5328C79A.6070004@redhat.com>
	<CAPP+0vLmvo8_q6ajBRGgWpVd0v3fb1M9E2uMjXAk8nu+RT-qag@mail.gmail.com>
	<20140319085646.GA18421@redhat.com>
	<CAPP+0vJPkVMPdnmoYaiT=fmKHhZpaP0kMzZ+X9=hdYaeorTS7w@mail.gmail.com>
Message-ID: <20140328150754.GM21211@redhat.com>

On Fri, 28 Mar 2014, Genadi Postrilko wrote:
>Thank you for the answer.
>Is the communication between IPA Client and Server HTTPS based? not just
>SSL over TCP?
Depends on the protocol being used.

You really need to go and look per protocol.

For example:

HTTPS is used only when you are using IPA's Web UI or when IPA command
line utilities ('ipa ...') are in use. Day to day work on IPA clients is
usually handled by SSSD.

SSSD processes talk Kerberos and LDAP to IPA server.

Kerberos is using own protocol (Kerberos) over TCP and/or UDP. Note that
Kerberos communications differ depending on the mode of operation and in
most cases include both integrity and confidentiality services where
needed.

LDAP is done with Kerberos authentication and TLS use within LDAP
protocol over TCP.

>So is Kerberos? Does it have to be over HTTP? or its purely over TCP/UDP?
Kerberos does not go over HTTP. You can use Kerberos to negotiate over HTTPS
but this is only for specific cases when someone is talking to
a kerberized web-service, like IPA's Web UI or its XML-RPC end point.


We didn't redefine any of the existing protocols for that. There are
already tools and means to achieve secure communication channels and we
are (carefully) using them for greater good.

>2014-03-19 10:56 GMT+02:00 Alexander Bokovoy <abokovoy at redhat.com>:
>
>> On Wed, 19 Mar 2014, Genadi Postrilko wrote:
>>
>>> Thank you for the answer.
>>> Sory if i lack the knowledge, but why SSL is needed when using kerberos?
>>> Kerberos is based on 3th party that is trusted, why there is a need for
>>> public key encryption?
>>>
>> Using Kerberos only, without asking for integrity and confidentiality
>> services,  without channel bindings to the outer encryption, is prone to
>> MITM even with valid TLS channels.
>>
>> Use of certificates allows to perform mutual authentication at the SSL
>> level and later perform channel bindings of the tunnelled Kerberos
>> communication.
>>
>> Note that Kerberos over HTTP is weak without transport level security.
>> HTTP authentication per se is independent of the transport.
>>
>> For more details you can look at Joe Orton's talk at ApacheCon'2008:
>> http://www.apachecon.com/eu2008/program/materials/kerb-sso-http.pdf
>> --
>> / Alexander Bokovoy
>>

-- 
/ Alexander Bokovoy



From mchesler at chesent.com  Fri Mar 28 21:08:58 2014
From: mchesler at chesent.com (Matt Chesler)
Date: Fri, 28 Mar 2014 17:08:58 -0400
Subject: [Freeipa-users] Certificate Woes
Message-ID: <CACjq759OfkOgnRM_OsaGaJZF5C3=i7uJvdWi-2jume-Q6KESww@mail.gmail.com>

Hi all,

Our IPA instance started acting strangely earlier today.  I restarted the
IPA service on the primary node and things seemed to return to normal.
 Over the course of the day, we decided to add a third IPA server to our
environment.  When I attempted to perform the ipa-replica-prepare, I
received the following error:

[Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your
certificate as expired.

After some additional digging, I discovered that several certs appear to
have expired recently, despite the fact that auto-renew appears to be
enabled.  The original node no longer exists.  All of the posts I seem to
be able to find indicate that I need the CSR from the original host.  How
can I renew my IPA certs without the original master?  Below is the
scrubbed output of "getcert list".

Thanks in advance for any help!

-Matt

# getcert list
Number of certificates and requests being tracked: 8.
Request ID '20131108192721':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=EXAMPLE.NET
subject: CN=ipa_server.example.com,O=EXAMPLE.NET
expires: 2015-11-09 17:22:30 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA
track: yes
auto-renew: yes
Request ID '20131108192808':
status: NEED_GUIDANCE
stuck: yes
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin='598671221310'
certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-retrieve-agent-submit
issuer: CN=Certificate Authority,O=EXAMPLE.NET
subject: CN=CA Audit,O=EXAMPLE.NET
expires: 2014-03-22 21:25:52 UTC
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/restart_pkicad
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20131108192809':
status: NEED_GUIDANCE
stuck: yes
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB',pin='598671221310'
certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-retrieve-agent-submit
issuer: CN=Certificate Authority,O=EXAMPLE.NET
subject: CN=OCSP Subsystem,O=EXAMPLE.NET
expires: 2014-03-22 21:25:50 UTC
eku: id-kp-OCSPSigning
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/restart_pkicad
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20131108192810':
status: NEED_GUIDANCE
stuck: yes
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB',pin='598671221310'
certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-retrieve-agent-submit
issuer: CN=Certificate Authority,O=EXAMPLE.NET
subject: CN=CA Subsystem,O=EXAMPLE.NET
expires: 2014-03-22 21:25:51 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/restart_pkicad "subsystemCert
cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20131108192811':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB',pin='598671221310'
certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=EXAMPLE.NET
subject: CN=ipa_server.example.com,O=EXAMPLE.NET
expires: 2015-10-29 19:28:04 UTC
eku: id-kp-serverAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20131108192901':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-NET',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-NET/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-NET',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=EXAMPLE.NET
subject: CN=ipa_server.example.com,O=EXAMPLE.NET
expires: 2015-11-09 17:22:29 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv EXAMPLE-NET
track: yes
auto-renew: yes
Request ID '20131108192951':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=EXAMPLE.NET
subject: CN=ipa_server.example.com,O=EXAMPLE.NET
expires: 2015-11-09 17:22:30 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes
Request ID '20131108193035':
status: NEED_GUIDANCE
stuck: yes
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB'
CA: dogtag-ipa-retrieve-agent-submit
issuer: CN=Certificate Authority,O=EXAMPLE.NET
subject: CN=IPA RA,O=EXAMPLE.NET
expires: 2014-03-22 21:26:43 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140328/e957ccc6/attachment.htm>

From rcritten at redhat.com  Fri Mar 28 21:33:13 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Fri, 28 Mar 2014 17:33:13 -0400
Subject: [Freeipa-users] Certificate Woes
In-Reply-To: <CACjq759OfkOgnRM_OsaGaJZF5C3=i7uJvdWi-2jume-Q6KESww@mail.gmail.com>
References: <CACjq759OfkOgnRM_OsaGaJZF5C3=i7uJvdWi-2jume-Q6KESww@mail.gmail.com>
Message-ID: <5335EA99.2050801@redhat.com>

Matt Chesler wrote:
> Hi all,
>
> Our IPA instance started acting strangely earlier today.  I restarted
> the IPA service on the primary node and things seemed to return to
> normal.  Over the course of the day, we decided to add a third IPA
> server to our environment.  When I attempted to perform the
> ipa-replica-prepare, I received the following error:
>
> [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your
> certificate as expired.
>
> After some additional digging, I discovered that several certs appear to
> have expired recently, despite the fact that auto-renew appears to be
> enabled.  The original node no longer exists.  All of the posts I seem
> to be able to find indicate that I need the CSR from the original host.
>   How can I renew my IPA certs without the original master?  Below is
> the scrubbed output of "getcert list".

The original node is the one configured to do the renewal. See 
http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master

rob



From dpal at redhat.com  Fri Mar 28 21:39:27 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 28 Mar 2014 17:39:27 -0400
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <CAELz9duJGTp0Kh=eyJJr2bFP6rhuc2FxTb17vhCbF7dQsWc=iw@mail.gmail.com>
References: <53306815.8070006@ugent.be> <53306B44.60608@redhat.com>
	<53308B05.1040009@ugent.be> <20140324195326.GA3487@redhat.com>
	<53308DE4.80609@redhat.com> <20140324204722.GB3487@redhat.com>
	<5330A946.7010800@ugent.be> <20140325063232.GC3487@redhat.com>
	<53313066.4080001@ugent.be> <20140325074341.GE3487@redhat.com>
	<53349A83.6040107@ugent.be> <5334D032.3020209@redhat.com>
	<5334D813.3090501@redhat.com>
	<CAELz9duJGTp0Kh=eyJJr2bFP6rhuc2FxTb17vhCbF7dQsWc=iw@mail.gmail.com>
Message-ID: <5335EC0F.2040101@redhat.com>

On 03/27/2014 11:33 PM, barrykfl at gmail.com wrote:
> Found a error today. when browse the cert serices ..is it realte to 
> dog tag system ...how to restart ?
> Certificate operation cannot be completed: Unable to communicate with 
> CMS (Not Found)
ipactrl stop
ipactrl start

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From shreerajkarulkar at yahoo.com  Fri Mar 28 22:34:56 2014
From: shreerajkarulkar at yahoo.com (Shree)
Date: Fri, 28 Mar 2014 15:34:56 -0700 (PDT)
Subject: [Freeipa-users] ipa-client-install fails on replica because of
	kinit cannot contact any KDC
In-Reply-To: <5331353C.9030603@redhat.com>
References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<5303B22A.9070709@redhat.com>	<1!	392751504.80428.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com>	!	<53051B35.2050409@redhat.com>	<1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com!	>	<53051F62.40405@redhat.com>	<1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com!	>	<53052E64.3050903@redhat.com>	<1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c!	!	om>	<53061B18.40001@redhat.com>	<1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<53066CD0.5080501@redhat.!	!
	com> <1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com>
	<1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo! !
	.com> <532A9E07.6040604@redhat.com>
	<1395445491.29606.YahooMailNeo@web160105.mail.bf1.yahoo.com>
	<532DFCD0.8060907@redhat.com>
	<1395685201.97247.YahooMailNeo@web160104.mail.bf1.yahoo.com>
	<5331353C.9030603@redhat.com>
Message-ID: <1396046096.70517.YahooMailNeo@web160103.mail.bf1.yahoo.com>

Martin
First of all thank you so much for your detailed analysis. I got a chance to finally take a look at it today. I tried your suggested changes to the /etc/krb5.conf and I now get the following response.

[root at www ~]# kinit
kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting initial credentials
[root at www ~]# kinit skarulkar
kinit: Cannot contact any KDC for realm ''MYDOMAIN.COM' while getting initial credentials
[root at www ~]# vi /etc/krb5.conf
[root at www ~]# kinit skarulkar at mydomain.com
kinit: Cannot find KDC for requested realm while getting initial credentials

Now I have seen this issue earlier in the project but I don't remember what I did to fix this.


ldap.mydomain.com is our primary which connects to ldap2.mydomain.com that exists in a separate VLAN? through specific ACLs in the firewall. They sync with each other fine. My clients are only able to talk to ldap2.mydomain.com. And out of 40 + clients that I moved from ldap to ldap2 I only seem to have issue with this last one?
I have even tried dropping a test VM in the same VLAN and it had no issues joining the IPA. So that rules out any ACL misconfigurations to this VLAN.



Shreeraj 
---------------------------------------------------------------------------------------- 

Change is the only Constant !



On Tuesday, March 25, 2014 12:55 AM, Martin Kosek <mkosek at redhat.com> wrote:
 
It searching for ldap.mydomain.com because you still have DNS SRV record
_kerberos._udp.mydomain.com. pointing to it. I would start there.

As for the failure, I would check that the generated /etc/krb5.conf is correct:

~~~~~~~~~
includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
? default_realm = MYDOMAIN.COM
? dns_lookup_realm = false
? dns_lookup_kdc = false
? rdns = false
? ticket_lifetime = 24h
? forwardable = yes

[realms]
? MYDOMAIN.COM = {
? ? kdc = ldap2.mydomain.com:88
? ? master_kdc = ldap2.mydomain.com:88
? ? admin_server = ldap2.mydomain.com:749
? ? default_domain = mydomain.com
? ? pkinit_anchors = FILE:/etc/ipa/ca.crt
? }

[domain_realm]
? .mydomain.com = MYDOMAIN.COM
? mydomain.com = MYDOMAIN.COM
? .mydomain.com = MYDOMAIN.COM
? mydomain.com = MYDOMAIN.COM
~~~~~~~~

(I assume you did more anonymizing that expected, ipa-client-install does not
generate 2 domain_realm mappings unless client domain is different that server
domain (e.g. client.other.mydomain.com and server.mydomain.com)).

What I would do in your place is to:
1) Backup your current /etc/krb5.conf
2) Replace it with the krb5.conf which was generated during ipa-client-install
(you can find non-anonymized version in ipaclient-install.log)
3) Try to kinit: kinit skarulkar at MYDOMAIN.COM

Then it will be easier to troubleshoot. To get more information what kinit
actually does, try enabling a trace:

# KRB5_TRACE=/dev/stdout kinit skarulkar at MYDOMAIN.COM

You will be then able to see if it really connects to right IP address which
would enable you to debug further.

Martin


On 03/24/2014 07:20 PM, Shree wrote:
> If you look at the attached logs, you can see it is going to the correct dns server. dig information is also correct. There is something else going on I can figure out what?
> 
> 
>? 
> Shreeraj 
> ---------------------------------------------------------------------------------------- 
> 
> Change is the only Constant !
> 
> 
> 
> On Saturday, March 22, 2014 2:12 PM, Dmitri Pal <dpal at redhat.com> wrote:
>? 
> On 03/21/2014 07:44 PM, Shree wrote: 
> Hi
>> Attaching the install log. It complains about unable to reach
>? ? ? ?  certain ports, however my tests by using telnet were successful.
>? ? ? ?  Also to refresh your memory the client should be reaching for
>? ? ? ?  the replica lda2.mydomain.com and not ldap.mydomain.com which it
>? ? ? ?  does for the most part but I found a couple of instances of
>? ? ? ?  ldap.mydomain.com in the log. Let me know what you find. I can't
>? ? ? ?  believe I migrated over 40 servers and only this one refuses to
>? ? ? ?  install ipa-client.
>>
>>
> If it is getting to the wrong server then it is either looking at
>? ?  the wrong DNS server (see resolve.conf) which is telling it to use
>? ?  the wrong IPA server (may be from some old try/POC) or it has some
>? ?  explicit entries entered in /etc/hosts.
> 
> 
> 
> 
>>
>>? 
>> Shreeraj 
>> ---------------------------------------------------------------------------------------- 
>>
>> Change is the only Constant !
>>
>>
>>
>> On Thursday, March 20, 2014 4:29 AM, Martin Kosek <mkosek at redhat.com> wrote:
>>
>> On 03/19/2014 10:37 PM, Shree wrote: 
>>
>>> Hello
>>> I was able to successfully move all my clients to
>? ? ? ? ? ? ? ? ?  the replica except on the process I had to upgrade the
>? ? ? ? ? ? ? ? ?  client to "ipa-client-3.0.0-37.el6.x86_64" and some
>? ? ? ? ? ? ? ? ?  times run a --uninstall 
>>>
>>> . Bit it works for the most part. Have been
>? ? ? ? ? ? ? ? ?  struggling with one last host with errors like below.
>? ? ? ? ? ? ? ? ?  I have tested the port connectivity using telnet and
>? ? ? ? ? ? ? ? ?  netcat commands but the install thinks these ports are
>? ? ? ? ? ? ? ? ?  blocked? 
>>>
>>>? 
>>>
>>>
>>> kerberos authentication failed
>>> kinit: Cannot contact any KDC for realm
>? ? ? ? ? ? ? ? ?  'MYDOMAIN.COM' while getting initial credentials
>>>
>>> Please make sure the following ports are opened
>? ? ? ? ? ? ? ? ?  in the firewall settings:
>>>? ? ?  TCP: 80, 88, 389
>>>? ? ?  UDP: 88 (at least one of TCP/UDP ports 88
>? ? ? ? ? ? ? ? ?  has to be open)
>>> Also note that following ports are necessary for
>? ? ? ? ? ? ? ? ?  ipa-client working properly after enrollment:
>>>? ? ?  TCP: 464
>>>? ? ?  UDP: 464, 123 (if NTP enabled)
>>> Installation failed. Rolling back changes.
>>> Disabling client Kerberos and LDAP configurations
>>> Redundant SSSD configuration file
>? ? ? ? ? ? ? ? ?  /etc/sssd/sssd.conf was moved to
>? ? ? ? ? ? ? ? ?  /etc/sssd/sssd.conf.deleted
>>> Restoring client configuration files
>>> Client uninstall complete.
>>> [root at www /]#
>>>
>>> In the /var/log/ipaclient-install.log I also see
>? ? ? ? ? ? ? ? ?  things like below. I get Autodiscovery failures but I
>? ? ? ? ? ? ? ? ?  am manually entering things and they have been
>? ? ? ? ? ? ? ? ?  working.
>>>
>>> 2014-03-19T21:13:47Z DEBUG Found:
>? ? ? ? ? ? ? ? ?  cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
>>> 2014-03-19T21:13:47Z DEBUG Discovery result:
>? ? ? ? ? ? ? ? ?  Success; server=ldap2.mydomain.com,
>? ? ? ? ? ? ? ? ?  domain=mydomain.com, kdc=ldap.mydomain.com,
>? ? ? ? ? ? ? ? ?  basedn=dc=mydomain,dc=com
>>> 2014-03-19T21:13:47Z DEBUG Validated servers:
>? ? ? ? ? ? ? ? ?  ldap2.mydomain.com
>>> 2014-03-19T21:13:47Z WARNING The failure to use
>? ? ? ? ? ? ? ? ?  DNS to find your IPA server indicates that your
>? ? ? ? ? ? ? ? ?  resolv.conf file is not properly configured.
>>> 2014-03-19T21:13:47Z INFO Autodiscovery of
>? ? ? ? ? ? ? ? ?  servers for failover cannot work with this
>? ? ? ? ? ? ? ? ?  configuration.
>>> 2014-03-19T21:13:47Z INFO If you proceed with the
>? ? ? ? ? ? ? ? ?  installation, services will be configured to always
>? ? ? ? ? ? ? ? ?  access the discovered server for all operations and
>? ? ? ? ? ? ? ? ?  will not fail over to other servers in case of
>? ? ? ? ? ? ? ? ?  failure.
>>
>> Ok. I would guess you have some DNS issue. But it is
>? ? ? ? ? ? ? ?  hard to tell without the
>> entire ipaclient-install.log of the failed installation.
>>
>> Martin 
>>
>>
>>
>>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140328/8744b0da/attachment.htm>

From stijn.deweirdt at ugent.be  Sat Mar 29 12:54:03 2014
From: stijn.deweirdt at ugent.be (Stijn De Weirdt)
Date: Sat, 29 Mar 2014 13:54:03 +0100
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <5334D813.3090501@redhat.com>
References: <53306815.8070006@ugent.be>	<53306B44.60608@redhat.com>	<53308B05.1040009@ugent.be>	<20140324195326.GA3487@redhat.com>	<53308DE4.80609@redhat.com>	<20140324204722.GB3487@redhat.com>	<5330A946.7010800@ugent.be>	<20140325063232.GC3487@redhat.com>	<53313066.4080001@ugent.be>	<20140325074341.GE3487@redhat.com>
	<53349A83.6040107@ugent.be>	<5334D032.3020209@redhat.com>
	<5334D813.3090501@redhat.com>
Message-ID: <5336C26B.5040706@ugent.be>

hi all,

> IMO we should not treat the OTP we set for the host enrollment as a
> kerberos password.
> I would rather record a time of the creation and validity period when
> the password is set in two new attributes. The validity period should be
> optional and if not provided copied from a system wide policy that can
> be set by default to say 10 min. When we do authentication with OTP we
> should check whether we are already beyond the point when the OTP is
> valid and fail enrollment.  When we validate and clear OTP we do not
> need to change these two attributes, they contain valuable info that
> might be queried later.
>
i like this idea. full host password policy is probably overkill for an 
OTP that only makes sense once in the lifetime of the host (OTP here 
means not only is the password itself only valid once; the whole 
password authentication is only valid/usable once).

btw, is it easy (as in API exists) to add new (site specific) attributes 
for a host? if so, i can already toy around with it for now. (storing 
the creation time in it and some cron job might suffice for now)

stijn



From dpal at redhat.com  Sun Mar 30 15:24:49 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sun, 30 Mar 2014 11:24:49 -0400
Subject: [Freeipa-users] change min and max lifetime of random password
In-Reply-To: <5336C26B.5040706@ugent.be>
References: <53306815.8070006@ugent.be>	<53306B44.60608@redhat.com>	<53308B05.1040009@ugent.be>	<20140324195326.GA3487@redhat.com>	<53308DE4.80609@redhat.com>	<20140324204722.GB3487@redhat.com>	<5330A946.7010800@ugent.be>	<20140325063232.GC3487@redhat.com>	<53313066.4080001@ugent.be>	<20140325074341.GE3487@redhat.com>
	<53349A83.6040107@ugent.be>	<5334D032.3020209@redhat.com>
	<5334D813.3090501@redhat.com> <5336C26B.5040706@ugent.be>
Message-ID: <53383741.809@redhat.com>

On 03/29/2014 08:54 AM, Stijn De Weirdt wrote:
> hi all,
>
>> IMO we should not treat the OTP we set for the host enrollment as a
>> kerberos password.
>> I would rather record a time of the creation and validity period when
>> the password is set in two new attributes. The validity period should be
>> optional and if not provided copied from a system wide policy that can
>> be set by default to say 10 min. When we do authentication with OTP we
>> should check whether we are already beyond the point when the OTP is
>> valid and fail enrollment.  When we validate and clear OTP we do not
>> need to change these two attributes, they contain valuable info that
>> might be queried later.
>>
> i like this idea. full host password policy is probably overkill for 
> an OTP that only makes sense once in the lifetime of the host (OTP 
> here means not only is the password itself only valid once; the whole 
> password authentication is only valid/usable once).
>
> btw, is it easy (as in API exists) to add new (site specific) 
> attributes for a host? if so, i can already toy around with it for 
> now. (storing the creation time in it and some cron job might suffice 
> for now)
>
> stijn
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


Here is a starting point.
http://www.freeipa.org/page/Contribute/Code

You need to create
a) Design
- You can destil this thread into couple paragraphs
b) Schema
   - try to reuse existing attributes if possible instead of inventing 
new ones
   - define a new AUXILIARY object class that would contain these attributes
   - Load schema into the project, make it a part of the source code, 
installation and update/upgrade
c) Plugin to manage
   - Create a python mgmt framework plugin to set these attributes when 
the OTP is created.
   - See http://abbra.fedorapeople.org/guide.html on now to do it
   - You probably want to make the field(s) visible in the UI but read 
only to show how much time is left for enrollment, but this can be a 
separate RFE done later.
d) Enrollment logic
   - You need to fix the enrollment logic to validate these new 
attributes during the enrollment. IMO it should be backward compatible 
meaning that if host entry does not have these attributes the enrollment 
does not expire (something to mention on the design page).

It sounds a lot but it is not once you get more experienced with the 
system. It can you do at least parts of that, would be great.
Good luck!

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From bnordgren at fs.fed.us  Sun Mar 30 17:18:04 2014
From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS)
Date: Sun, 30 Mar 2014 17:18:04 +0000
Subject: [Freeipa-users] External Collaboration Domains
In-Reply-To: <5333519A.2060206@redhat.com>
References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net>
	<20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com>
Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net>

Hey guys,

Back again. Thanks for your responses so far.

OTP is interesting, but requires that an account be created in the local domain, which is kind of opposed to the notion of federated identities.

Ipsilon is also interesting, from its description as a gateway to non-Kerberos identitiy providers. I have not located much information about it, though.

I've taken a couple of days to put together an RFE with three use cases and tons of pictures. It locally maintains user attributes in LDAP without creating a corresponding authentication principal in Kerberos. It offers a little more flexibility for integrating AD users to an IPA managed POSIX realm without conflicting with the existing method. It also makes possible the management of inter-organizational cross realm operation using PKINIT. Finally, it describes an interface between the IPA server and Ipsilon (or any identity gateway), and a mechanism by which Ipsilon may acquire TGTs for the local realm on behalf of clients who authenticate via remote, non-Kerberos identity providers. This last workflow is generic and supports methods other than a web-browser.

Please take a look and help me improve it. Also pls educate me out of any mistakes you detect. Part of the reason for doing this is for me to make sure I learned Kerberos concepts correctly.

 http://www.freeipa.org/page/External_Users_in_IPA

Thanks,
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.




From abokovoy at redhat.com  Sun Mar 30 18:26:19 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Sun, 30 Mar 2014 21:26:19 +0300
Subject: [Freeipa-users] External Collaboration Domains
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net>
References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net>
	<20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net>
Message-ID: <20140330182619.GA19628@redhat.com>

On Sun, 30 Mar 2014, Nordgren, Bryce L -FS wrote:
>Hey guys,
>
>Back again. Thanks for your responses so far.
>
>OTP is interesting, but requires that an account be created in the
>local domain, which is kind of opposed to the notion of federated
>identities.
>
>Ipsilon is also interesting, from its description as a gateway to
>non-Kerberos identitiy providers. I have not located much information
>about it, though.
>
>I've taken a couple of days to put together an RFE with three use cases
>and tons of pictures. It locally maintains user attributes in LDAP
>without creating a corresponding authentication principal in Kerberos.
>It offers a little more flexibility for integrating AD users to an IPA
>managed POSIX realm without conflicting with the existing method. It
>also makes possible the management of inter-organizational cross realm
>operation using PKINIT. Finally, it describes an interface between the
>IPA server and Ipsilon (or any identity gateway), and a mechanism by
>which Ipsilon may acquire TGTs for the local realm on behalf of clients
>who authenticate via remote, non-Kerberos identity providers. This last
>workflow is generic and supports methods other than a web-browser.
>
>Please take a look and help me improve it. Also pls educate me out of
>any mistakes you detect. Part of the reason for doing this is for me to
>make sure I learned Kerberos concepts correctly.
>
> http://www.freeipa.org/page/External_Users_in_IPA
Thanks for the writeup. 

I think it does not really differ from what I described, conceptually.
It is, however, requiring much more work than what I described.

FreeIPA has flat LDAP DIT. Adding support for separate OUs is in itself
a non-trivial task.

Provisioning of an external user's account in LDAP in a separate OU
does not change anything from what we already would do for creating
accounts for external users on the fly, in standard users tree, and
putting them into a specific group set.

However, provisioning users in a separate OU would also mean changing
many of other functional modules to add awareness of those OUs. HBAC,
for example, needs changes on both server and client (SSSD) side. Client
side changes to properly recognize DNs of external users from a
separate OU when resolving HBAC rules will need to be distributed to all
IPA clients, including those where upgrade of the software is not
possible due to a customer constraints. Re-using existing mechanisms has
own advantages of not changing the client side.

PKINIT use in Kerberos is a big issue. Right now certificates produced
by FreeIPA do not include special extension that Kerberos KDC requires
to have PKINIT working. We have a ticket to solve this but it depends on
few items missing in FreeIPA, Dogtag, and nss. Solving it is required
for full OTP use, so we might gain this feature sooner or later.

I would generally not recommend both diminishing or relying too much on
existing RFCs for certain LDAP storage schema proposals, specifically
for Kerberos. These have little value outside of specific Kerberos KDC
backend utilizing them. We have already our own schema, specific enough
for FreeIPA and we are going to continue using it, regardless how
'expired' or new certain RFCs. There is simply no universal agreement
here and no need for it, actually.

What's reasonable and can be relatively easily pulled in from your
proposal is a mechanism to get users automatically provisioned in
FreeIPA based on their cross realm identities. For example, for cross
realm trust with AD we have means to selectively block certain SIDs from
being imported from the AD. The rest is recognized and accepted but no
local external groups created for them. We simply can automate creating
the groups on login attempt if SIDs involved aren't blocked. This
automation should solve majority of administrative load.

-- 
/ Alexander Bokovoy



From bnordgren at fs.fed.us  Sun Mar 30 19:14:42 2014
From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS)
Date: Sun, 30 Mar 2014 19:14:42 +0000
Subject: [Freeipa-users] External Collaboration Domains
In-Reply-To: <20140330182619.GA19628@redhat.com>
References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net>
	<20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net>
	<20140330182619.GA19628@redhat.com>
Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net>

> I think it does not really differ from what I described, conceptually.
> It is, however, requiring much more work than what I described.
>
> FreeIPA has flat LDAP DIT. Adding support for separate OUs is in itself a non-
> trivial task.

Ah. Well since that's the case, separate OUs are gone. (You may have to hit "reload" in your browser to get the new figure.) It does require that the RDN of all external entities encode both the name and the realm of the external Kerberos principal in order to avoid collisions. Is the current "external user" provisioning method able to handle the same name coming from two domains or does it assume that collisions will never happen?

> PKINIT use in Kerberos is a big issue. Right now certificates produced by
> FreeIPA do not include special extension that Kerberos KDC requires to have
> PKINIT working. We have a ticket to solve this but it depends on few items
> missing in FreeIPA, Dogtag, and nss. Solving it is required for full OTP use, so
> we might gain this feature sooner or later.

The proposal actually doesn't involve producing kx509 certificates, only consuming them. :) I think these are two issues which can be handled in parallel rather than having one block the other. ;)

> What's reasonable and can be relatively easily pulled in from your proposal is
> a mechanism to get users automatically provisioned in FreeIPA based on
> their cross realm identities. For example, for cross realm trust with AD we
> have means to selectively block certain SIDs from being imported from the
> AD. The rest is recognized and accepted but no local external groups created
> for them. We simply can automate creating the groups on login attempt if
> SIDs involved aren't blocked. This automation should solve majority of
> administrative load.

>From my cursory examination of the code, I proposed auditing the KDC's AS and TGS conversations to trigger this automatic provisioning. Is this an approach worth keeping?

I understand that IPA's bread and butter is to attach itself to a pre existing AD domain to simplify the administration of Linux machines within the same administrative boundaries.  This is a subset of Use Case 1. I just want to make sure that there's a plan in place for situations where the domain of origin is not AD, and no SID is exported  (the rest of Use Case 1, and Use Cases 2 & 3.) This is just a generalization of the procedure to allow "AD" users access to services such that users from non-AD realms can also be included.

Use Case 1 could be named "Intra-organizational cross-realm operation", Use Case 2 could be named "Inter-organizational cross realm operation", and Use Case 3 could be named "Multi-technology cross-realm operation". 2&3 involve independent administrative entities with a fair amount of autonomy. Traditional enterprise approaches are not valid for 2&3. :)

Thanks for the review!
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.




From dpal at redhat.com  Sun Mar 30 22:34:18 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sun, 30 Mar 2014 18:34:18 -0400
Subject: [Freeipa-users] External Collaboration Domains
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net>
References: <82E7C9A01FD0764CACDD35D10F5DFB6E6A3F38@001FSN2MPN1-045.001f.mgd2.msft.net>
	<20140325071208.GD3487@redhat.com> <5333519A.2060206@redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6A60DC@001FSN2MPN1-045.001f.mgd2.msft.net>
	<20140330182619.GA19628@redhat.com>
	<82E7C9A01FD0764CACDD35D10F5DFB6E6A617E@001FSN2MPN1-045.001f.mgd2.msft.net>
Message-ID: <53389BEA.9050905@redhat.com>

On 03/30/2014 03:14 PM, Nordgren, Bryce L -FS wrote:
>> I think it does not really differ from what I described, conceptually.
>> It is, however, requiring much more work than what I described.
>>
>> FreeIPA has flat LDAP DIT. Adding support for separate OUs is in itself a non-
>> trivial task.
> Ah. Well since that's the case, separate OUs are gone. (You may have to hit "reload" in your browser to get the new figure.) It does require that the RDN of all external entities encode both the name and the realm of the external Kerberos principal in order to avoid collisions. Is the current "external user" provisioning method able to handle the same name coming from two domains or does it assume that collisions will never happen?
>
>> PKINIT use in Kerberos is a big issue. Right now certificates produced by
>> FreeIPA do not include special extension that Kerberos KDC requires to have
>> PKINIT working. We have a ticket to solve this but it depends on few items
>> missing in FreeIPA, Dogtag, and nss. Solving it is required for full OTP use, so
>> we might gain this feature sooner or later.
> The proposal actually doesn't involve producing kx509 certificates, only consuming them. :) I think these are two issues which can be handled in parallel rather than having one block the other. ;)
>
>> What's reasonable and can be relatively easily pulled in from your proposal is
>> a mechanism to get users automatically provisioned in FreeIPA based on
>> their cross realm identities. For example, for cross realm trust with AD we
>> have means to selectively block certain SIDs from being imported from the
>> AD. The rest is recognized and accepted but no local external groups created
>> for them. We simply can automate creating the groups on login attempt if
>> SIDs involved aren't blocked. This automation should solve majority of
>> administrative load.
>  From my cursory examination of the code, I proposed auditing the KDC's AS and TGS conversations to trigger this automatic provisioning. Is this an approach worth keeping?
>
> I understand that IPA's bread and butter is to attach itself to a pre existing AD domain to simplify the administration of Linux machines within the same administrative boundaries.  This is a subset of Use Case 1. I just want to make sure that there's a plan in place for situations where the domain of origin is not AD, and no SID is exported  (the rest of Use Case 1, and Use Cases 2&  3.) This is just a generalization of the procedure to allow "AD" users access to services such that users from non-AD realms can also be included.
>
> Use Case 1 could be named "Intra-organizational cross-realm operation", Use Case 2 could be named "Inter-organizational cross realm operation", and Use Case 3 could be named "Multi-technology cross-realm operation". 2&3 involve independent administrative entities with a fair amount of autonomy. Traditional enterprise approaches are not valid for 2&3. :)
>
> Thanks for the review!
> 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.
>


Wow!
First of all thanks for a nice pictures and sharing your ideas.
A lot of work and though put into it.

Let me just point couple things:
1) It looks like the whole idea is about creating entries for external 
users on the server when external user authenticates via KDC. But don't 
we already lookup cache these users in a local SSSD cache and expose via 
the compat tree for legacy clients?
AFAIU the purpose is to be able to create local groups for the external 
users. May be we can do something and use compat tree DNs for external 
users?
In general it is better to distill the problem we are trying to solve: 
did I get it right?

2) I think PKINIT and related part of the proposal is not something that 
we would do.
Instead of PKI based Ipsilon would use GSS proxy that implements 
s4u2proxy + s4u2self to acquire a ticket on user behalf.
This functionality already exists, so there is no new code need.

3) The case when you send TGT back to the client from Ipsilon that 
authenticated user and acquired TGT on his behalf is an interesting one. 
The intent for client to later use SSH is understandable though hard to 
achieve. Currently there is no mechanism for Ipsilon or Ipsilon like 
gateways to return the TGT for a user and pass it to client browser. 
There is also no way a browser can save this TGT in the cache.

Bottom line:
Let us focus on the problem we are trying to solve here. Keep in mind 
that we have not started designing IPA to IPA trusts and Kerberos to IPA 
trusts. It might very well be that we would need to create some external 
entries for those trusts so IMO looking into these trust scenarios would 
reveal where our AD integration approach lacks external info and needs 
to be extended. If we want to solve the high level problem of trusts in 
general we need to build those specific flows and see what data is not 
in ldap and we can get it there. A simple mental exercise  suggests that 
we would need something for grouping of the identities coming from a 
vanilla trusted Kerberos domain. May be this is something we should 
drill down as a next step?




-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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





From barrykfl at gmail.com  Mon Mar 31 02:34:18 2014
From: barrykfl at gmail.com (barrykfl at gmail.com)
Date: Mon, 31 Mar 2014 10:34:18 +0800
Subject: [Freeipa-users] Issue on import official cert of godaddy.
Message-ID: <CAELz9dtZDdk-QtKikNfG2SqHR+ix9bHC_aaVPLmipmTbC41r7g@mail.gmail.com>

Dear all:

I have succesfful impont certs to http and ldap but some inssue arise.

1) when i click in service in the UI it still using OLD entries of seld
sign cert and given out error ...pls see attachment,.

How to reflect the godaddy cert there and it cannot be deleted .??


2)  when start up dirsrv it casue some warning out say:
Starting dirsrv:
    ABS-COM...[31/Mar/2014:10:25:59 +0800] - SSL alert:
CERT_VerifyCertificateNow:      verify certificate failed for cert *.
wisers.com - GoDaddy.com, Inc. of family cn=RSA,c
n=encryption,cn=config (Netscape Portable Runtime error -8172 - Peer's
certificate iss     uer has been marked as not trusted by the user.)

any where i should import again to skip the error and realize the change no
prompt out errors?

Regards

Barry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140331/d4a5c0b1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Untitled.jpg
Type: image/jpeg
Size: 69401 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140331/d4a5c0b1/attachment.jpg>

From rcritten at redhat.com  Mon Mar 31 14:02:21 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 31 Mar 2014 10:02:21 -0400
Subject: [Freeipa-users] ipa-client-install fails on replica because of
 kinit cannot contact any KDC
In-Reply-To: <1396046096.70517.YahooMailNeo@web160103.mail.bf1.yahoo.com>
References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com>	!	<53051B35.2050409@redhat.com>	<1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com!	>	<53051F62.40405@redhat.com>	<1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com!	>	<53052E64.3050903@redhat.com>	<1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c!	!	om>	<53061B18.40001@redhat.com>	<1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<53066CD0.5080501@redhat.!	!	com>
	<1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com>	<1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo!
	!	.com>
	<532A9E07.6040604@redhat.com>	<1395445491.29606.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<532DFCD0.8060907@redhat.com>	<1395685201.97247.YahooMailNeo@web160104.mail.bf1.yahoo.com>	<5331353C.9030603@redhat.com>
	<1396046096.70517.YahooMailNeo@web160103.mail.bf1.yahoo.com>
Message-ID: <5339756D.5080108@redhat.com>

Shree wrote:
> Martin
> First of all thank you so much for your detailed analysis. I got a
> chance to finally take a look at it today. I tried your suggested
> changes to the /etc/krb5.conf and I now get the following response.
>
> [root at www ~]# kinit
> kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting
> initial credentials
> [root at www ~]# kinit skarulkar
> kinit: Cannot contact any KDC for realm ''MYDOMAIN.COM' while getting
> initial credentials
> [root at www ~]# vi /etc/krb5.conf
> [root at www ~]# kinit skarulkar at mydomain.com
> kinit: Cannot find KDC for requested realm while getting initial credentials
>
> Now I have seen this issue earlier in the project but I don't remember
> what I did to fix this.
>
> ldap.mydomain.com is our primary which connects to ldap2.mydomain.com
> that exists in a separate VLAN  through specific ACLs in the firewall.
> They sync with each other fine. My clients are only able to talk to
> ldap2.mydomain.com. And out of 40 + clients that I moved from ldap to
> ldap2 I only seem to have issue with this last one?
> I have even tried dropping a test VM in the same VLAN and it had no
> issues joining the IPA. So that rules out any ACL misconfigurations to
> this VLAN.

Did you try the tracing that Martin suggested?

rob

>
>
> Shreeraj
> ----------------------------------------------------------------------------------------
>
>
> Change is the only Constant !
>
>
> On Tuesday, March 25, 2014 12:55 AM, Martin Kosek <mkosek at redhat.com> wrote:
> It searching for ldap.mydomain.com because you still have DNS SRV record
> _kerberos._udp.mydomain.com. pointing to it. I would start there.
>
> As for the failure, I would check that the generated /etc/krb5.conf is
> correct:
>
> ~~~~~~~~~
> includedir /var/lib/sss/pubconf/krb5.include.d/
>
> [libdefaults]
> default_realm = MYDOMAIN.COM
>    dns_lookup_realm = false
>    dns_lookup_kdc = false
>    rdns = false
>    ticket_lifetime = 24h
>    forwardable = yes
>
> [realms]
>    MYDOMAIN.COM = {
>      kdc = ldap2.mydomain.com:88
>      master_kdc = ldap2.mydomain.com:88
>      admin_server = ldap2.mydomain.com:749
>      default_domain = mydomain.com
>      pkinit_anchors = FILE:/etc/ipa/ca.crt
>    }
>
> [domain_realm]
>    .mydomain.com = MYDOMAIN.COM
>    mydomain.com = MYDOMAIN.COM
>    .mydomain.com = MYDOMAIN.COM
>    mydomain.com = MYDOMAIN.COM
> ~~~~~~~~
>
> (I assume you did more anonymizing that expected, ipa-client-install
> does not
> generate 2 domain_realm mappings unless client domain is different that
> server
> domain (e.g. client.other.mydomain.com and server.mydomain.com)).
>
> What I would do in your place is to:
> 1) Backup your current /etc/krb5.conf
> 2) Replace it with the krb5.conf which was generated during
> ipa-client-install
> (you can find non-anonymized version in ipaclient-install.log)
> 3) Try to kinit: kinit skarulkar at MYDOMAIN.COM
> <mailto:skarulkar at MYDOMAIN.COM>
>
> Then it will be easier to troubleshoot. To get more information what kinit
> actually does, try enabling a trace:
>
> # KRB5_TRACE=/dev/stdout kinit skarulkar at MYDOMAIN.COM
> <mailto:skarulkar at MYDOMAIN.COM>
>
> You will be then able to see if it really connects to right IP address which
> would enable you to debug further.
>
> Martin
>
> On 03/24/2014 07:20 PM, Shree wrote:
>  > If you look at the attached logs, you can see it is going to the
> correct dns server. dig information is also correct. There is something
> else going on I can figure out what?
>  >
>  >
>  >
>  > Shreeraj
>  >
> ----------------------------------------------------------------------------------------
>
>  >
>  > Change is the only Constant !
>  >
>  >
>  >
>  > On Saturday, March 22, 2014 2:12 PM, Dmitri Pal <dpal at redhat.com
> <mailto:dpal at redhat.com>> wrote:
>  >
>  > On 03/21/2014 07:44 PM, Shree wrote:
>  > Hi
>  >> Attaching the install log. It complains about unable to reach
>  >        certain ports, however my tests by using telnet were successful.
>  >        Also to refresh your memory the client should be reaching for
>  >        the replica lda2.mydomain.com and not ldap.mydomain.com which it
>  >        does for the most part but I found a couple of instances of
>  >        ldap.mydomain.com in the log. Let me know what you find. I can't
>  >        believe I migrated over 40 servers and only this one refuses to
>  >        install ipa-client.
>  >>
>  >>
>  > If it is getting to the wrong server then it is either looking at
>  >    the wrong DNS server (see resolve.conf) which is telling it to use
>  >    the wrong IPA server (may be from some old try/POC) or it has some
>  >    explicit entries entered in /etc/hosts.
>  >
>  >
>  >
>  >
>  >>
>  >>
>  >> Shreeraj
>  >>
> ----------------------------------------------------------------------------------------
>
>  >>
>  >> Change is the only Constant !
>  >>
>  >>
>  >>
>  >> On Thursday, March 20, 2014 4:29 AM, Martin Kosek <mkosek at redhat.com
> <mailto:mkosek at redhat.com>> wrote:
>  >>
>  >> On 03/19/2014 10:37 PM, Shree wrote:
>  >>
>  >>> Hello
>  >>> I was able to successfully move all my clients to
>  >                  the replica except on the process I had to upgrade the
>  >                  client to "ipa-client-3.0.0-37.el6.x86_64" and some
>  >                  times run a --uninstall
>  >>>
>  >>> . Bit it works for the most part. Have been
>  >                  struggling with one last host with errors like below.
>  >                  I have tested the port connectivity using telnet and
>  >                  netcat commands but the install thinks these ports are
>  >                  blocked?
>  >>>
>  >>>
>  >>>
>  >>>
>  >>> kerberos authentication failed
>  >>> kinit: Cannot contact any KDC for realm
>  >                  'MYDOMAIN.COM' while getting initial credentials
>  >>>
>  >>> Please make sure the following ports are opened
>  >                  in the firewall settings:
>  >>>      TCP: 80, 88, 389
>  >>>      UDP: 88 (at least one of TCP/UDP ports 88
>  >                  has to be open)
>  >>> Also note that following ports are necessary for
>  >                  ipa-client working properly after enrollment:
>  >>>      TCP: 464
>  >>>      UDP: 464, 123 (if NTP enabled)
>  >>> Installation failed. Rolling back changes.
>  >>> Disabling client Kerberos and LDAP configurations
>  >>> Redundant SSSD configuration file
>  >                  /etc/sssd/sssd.conf was moved to
>  >                  /etc/sssd/sssd.conf.deleted
>  >>> Restoring client configuration files
>  >>> Client uninstall complete.
>  >>> [root at www <mailto:root at www> /]#
>  >>>
>  >>> In the /var/log/ipaclient-install.log I also see
>  >                  things like below. I get Autodiscovery failures but I
>  >                  am manually entering things and they have been
>  >     working.
>  >>>
>  >>> 2014-03-19T21:13:47Z DEBUG Found:
>  >                  cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
>  >>> 2014-03-19T21:13:47Z DEBUG Discovery result:
>  >                  Success; server=ldap2.mydomain.com,
>  >                  domain=mydomain.com, kdc=ldap.mydomain.com,
>  >                  basedn=dc=mydomain,dc=com
>  >>> 2014-03-19T21:13:47Z DEBUG Validated servers:
>  >                  ldap2.mydomain.com
>  >>> 2014-03-19T21:13:47Z WARNING The failure to use
>  >               DNS to find your IPA server indicates that your
>  >                  resolv.conf file is not properly configured.
>  >>> 2014-03-19T21:13:47Z INFO Autodiscovery of
>  >                  servers for failover cannot work with this
>  >                  configuration.
>  >>> 2014-03-19T21:13:47Z INFO If you proceed with the
>  >                  installation, services will be configured to always
>  >                  access the discovered server for all operations and
>  >                  will not fail over to other servers in case of
>  >                  failure.
>  >>
>  >> Ok. I would guess you have some DNS issue. But it is
>  >                hard to tell without the
>  >> entire ipaclient-install.log of the failed installation.
>  >>
>  >> Martin
>  >>
>  >>
>  >>
>  >>
>  >
>  >
>
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>



From rcritten at redhat.com  Mon Mar 31 14:07:59 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 31 Mar 2014 10:07:59 -0400
Subject: [Freeipa-users] Issue on import official cert of godaddy.
In-Reply-To: <CAELz9dtZDdk-QtKikNfG2SqHR+ix9bHC_aaVPLmipmTbC41r7g@mail.gmail.com>
References: <CAELz9dtZDdk-QtKikNfG2SqHR+ix9bHC_aaVPLmipmTbC41r7g@mail.gmail.com>
Message-ID: <533976BF.2050602@redhat.com>

barrykfl at gmail.com wrote:
> Dear all:
> I have succesfful impont certs to http and ldap but some inssue arise.
> 1) when i click in service in the UI it still using OLD entries of seld
> sign cert and given out error ...pls see attachment,.
> How to reflect the godaddy cert there and it cannot be deleted .??

You're misreading this. The IPA CA is still installed and has issued 
some certificates to some service (and probably hosts). I'm guessing you 
removed the IPA CA certificate from /etc/httpd/alias. You need to add it 
back to let IPA talk to its CA again.

> 2)  when start up dirsrv it casue some warning out say:
> Starting dirsrv:
>      ABS-COM...[31/Mar/2014:10:25:59 +0800] - SSL alert:
> CERT_VerifyCertificateNow:      verify certificate failed for cert
> *.wisers.com <http://wisers.com> - GoDaddy.com, Inc. of family
> cn=RSA,c     n=encryption,cn=config (Netscape Portable Runtime error
> -8172 - Peer's certificate iss     uer has been marked as not trusted by
> the user.)
> any where i should import again to skip the error and realize the change
> no prompt out errors?

You need to add the GoDaddy CA cert chain to the 389-ds cert database in 
/etc/dirsrv/slapd-ABS-COM/

rob



From rcritten at redhat.com  Mon Mar 31 14:36:36 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 31 Mar 2014 10:36:36 -0400
Subject: [Freeipa-users] stop alias of https://abc.com/ipa/ui/
In-Reply-To: <CAELz9dtaPwAxn269Go7aGweFabqK31i1KggD0z2Hjedmsg8Gyw@mail.gmail.com>
References: <CAELz9dsbc0kpaeNYM3229toim-2Cd91cge80C9MMsQ8=ach60A@mail.gmail.com>	<5332C5B5.5090003@redhat.com>	<5332D93A.6050003@redhat.com>	<CAELz9durzd3UncbM32fnAz7wKLONHMB0DJY00=3NfQqw02nL8Q@mail.gmail.com>	<5339774A.9030602@redhat.com>
	<CAELz9dtaPwAxn269Go7aGweFabqK31i1KggD0z2Hjedmsg8Gyw@mail.gmail.com>
Message-ID: <53397D74.9050700@redhat.com>

barrykfl at gmail.com wrote:
> Http:// still able to acces
> 
> I want only https to access

That should be the default with a few exceptions. We'd need to see your
ipa-rewrite.conf.

rob

> 
> 2014/3/31 ??10:11 ? "Rob Crittenden" <rcritten at redhat.com 
> <mailto:rcritten at redhat.com>> ???
> 
>     barrykfl at gmail.com <mailto:barrykfl at gmail.com> wrote:
> 
> 
>         Hi:
>         I disable the redirection subcessfully but where to make it use
>         https
>         not http ?
>         now http:\\abc.com/ipa/ui <http://abc.com/ipa/ui>
>         <http://abc.com/ipa/ui> still able to redirect
>         https.
> 
> 
>     I don't understand the question.
> 
>     rob
> 
>         2014-03-26 21:42 GMT+08:00 Rob Crittenden <rcritten at redhat.com
>         <mailto:rcritten at redhat.com>
>         <mailto:rcritten at redhat.com <mailto:rcritten at redhat.com>>>:
> 
>              Martin Kosek wrote:
> 
>                  On 03/26/2014 05:08 AM, barrykfl at gmail.com
>         <mailto:barrykfl at gmail.com>
>                  <mailto:barrykfl at gmail.com <mailto:barrykfl at gmail.com>>
>         wrote:
> 
>                      Dear sir:
> 
>                      where can i set stop alias of /ipa/ui
>         redirection...and let
> 
>                      it just use https://abc.com/ipa/ui/  absolute path?
> 
>                      thks
> 
>                      barry
> 
> 
>                  /etc/httpd/conf.d/ipa-rewrite.____conf
> 
> 
>              You'll need to watch this file on upgrades as it can revert
>         in some
>              cases.
> 
>              rob
> 
> 
> 



From rcritten at redhat.com  Mon Mar 31 14:37:45 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 31 Mar 2014 10:37:45 -0400
Subject: [Freeipa-users] Issue on import official cert of godaddy.
In-Reply-To: <CAELz9duuR2_JKnh-WimY5+f1xn=GejbWT80Q+e+7cdCHFU003w@mail.gmail.com>
References: <CAELz9dtZDdk-QtKikNfG2SqHR+ix9bHC_aaVPLmipmTbC41r7g@mail.gmail.com>	<533976BF.2050602@redhat.com>
	<CAELz9duuR2_JKnh-WimY5+f1xn=GejbWT80Q+e+7cdCHFU003w@mail.gmail.com>
Message-ID: <53397DB9.9020709@redhat.com>

barrykfl at gmail.com wrote:
> I follow the mAnual.using ipa cert install
> 
> It will auto remove ipa cert after u insert godaddy .  Should i add them 
> back? No.conflict?

You only need to add in the CA. There will be no conflict.

> 2)do.umeant ca root cert of godaddy ? Ialread try added any ca root cert 
> of godaddy the error still comes out

You need to add the CA that issued the wildcard cert they gave you.
Typically there are one or more subordinate CAs that actually issue the
certificates.

rob

> 
> 2014/3/31 ??10:08 ? "Rob Crittenden" <rcritten at redhat.com 
> <mailto:rcritten at redhat.com>> ???
> 
>     barrykfl at gmail.com <mailto:barrykfl at gmail.com> wrote:
> 
>         Dear all:
>         I have succesfful impont certs to http and ldap but some inssue
>         arise.
>         1) when i click in service in the UI it still using OLD entries
>         of seld
>         sign cert and given out error ...pls see attachment,.
>         How to reflect the godaddy cert there and it cannot be deleted .??
> 
> 
>     You're misreading this. The IPA CA is still installed and has issued
>     some certificates to some service (and probably hosts). I'm guessing
>     you removed the IPA CA certificate from /etc/httpd/alias. You need
>     to add it back to let IPA talk to its CA again.
> 
>         2)  when start up dirsrv it casue some warning out say:
>         Starting dirsrv:
>               ABS-COM...[31/Mar/2014:10:25:__59 +0800] - SSL alert:
>         CERT_VerifyCertificateNow:      verify certificate failed for cert
>         *.wisers.com <http://wisers.com> <http://wisers.com> -
>         GoDaddy.com, Inc. of family
>         cn=RSA,c     n=encryption,cn=config (Netscape Portable Runtime error
>         -8172 - Peer's certificate iss     uer has been marked as not
>         trusted by
>         the user.)
>         any where i should import again to skip the error and realize
>         the change
>         no prompt out errors?
> 
> 
>     You need to add the GoDaddy CA cert chain to the 389-ds cert
>     database in /etc/dirsrv/slapd-ABS-COM/
> 
>     rob
> 



From shreerajkarulkar at yahoo.com  Mon Mar 31 15:02:54 2014
From: shreerajkarulkar at yahoo.com (Shree)
Date: Mon, 31 Mar 2014 08:02:54 -0700 (PDT)
Subject: [Freeipa-users] ipa-client-install fails on replica because of
	kinit cannot contact any KDC
In-Reply-To: <5339756D.5080108@redhat.com>
References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<1392758319.6501.YahooMailNeo@web160102.mail.bf1.yahoo.com>	!	<53051B35.2050409@redhat.com>	<1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com!	>	<53051F62.40405@redhat.com>	<1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com!	>	<53052E64.3050903@redhat.com>	<1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c!	!	om>	<53061B18.40001@redhat.com>	<1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<53066CD0.5080501@redhat.!	!	com>
	<1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com>	<1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo!
	!	.com>
	<532A9E07.6040604@redhat.com>	<1395445491.29606.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<532DFCD0.8060907@redhat.com>	<1395685201.97247.YahooMailNeo@web160104.mail.bf1.yahoo.com>	<5331353C.9030603@redhat.com>
	<1396046096.70517.YahooMailNeo@web160103.mail.bf1.yahoo.com>
	<5339756D.5080108@redhat.com>
Message-ID: <1396278174.64201.YahooMailNeo@web160103.mail.bf1.yahoo.com>

Rob
This is what I get.

[root at www ~]# KRB5_TRACE=/dev/stdout kinit skarulkar at mydomain.com
[14858] 1396278013.584391: Getting initial credentials for skarulkar at mydomain.com
[14858] 1396278013.584975: Sending request (188 bytes) to mydomain.com
[14858] 1396278013.585470: Retrying AS request with master KDC
[14858] 1396278013.585492: Getting initial credentials for skarulkar at mydomain.com
[14858] 1396278013.585848: Sending request (188 bytes) to mydomain.com (master)
kinit: Cannot find KDC for requested realm while getting initial credentials
[root at www ~]#


?
Shreeraj 
---------------------------------------------------------------------------------------- 

Change is the only Constant !
On Monday, March 31, 2014 7:02 AM, Rob Crittenden <rcritten at redhat.com> wrote:
 
Shree wrote:
> Martin
> First of all thank you so much for your detailed analysis. I got a
> chance to finally take a look at it today. I tried your suggested
> changes to the /etc/krb5.conf and I now get the following response.
>
> [root at www ~]# kinit
> kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting
> initial credentials
> [root at www ~]# kinit skarulkar
> kinit: Cannot contact any KDC for realm ''MYDOMAIN.COM' while getting
> initial credentials
> [root at www ~]# vi /etc/krb5.conf
> [root at www ~]# kinit skarulkar at mydomain.com
> kinit: Cannot find KDC for requested realm while getting initial credentials
>
> Now I have seen this issue earlier in the project but I don't remember
> what I did to fix this.
>
> ldap.mydomain.com is our primary which connects to ldap2.mydomain.com
> that exists in a separate VLAN? through specific ACLs in the firewall.
> They sync with each other fine. My clients are only able to talk to
> ldap2.mydomain.com. And out of 40 + clients that I moved from ldap to
> ldap2 I only seem to have issue with this last one?
> I have even tried dropping a test VM in the same VLAN and it had no
> issues joining the IPA. So that rules out any ACL misconfigurations to
> this VLAN.

Did you try the tracing that Martin suggested?

rob

>
>
> Shreeraj
> ----------------------------------------------------------------------------------------
>
>
> Change is the only Constant !
>
>
> On Tuesday, March 25, 2014 12:55 AM, Martin Kosek <mkosek at redhat.com> wrote:
> It searching for ldap.mydomain.com because you still have DNS SRV record
> _kerberos._udp.mydomain.com. pointing to it. I would start there.
>
> As for the failure, I would check that the generated /etc/krb5.conf is
> correct:
>
> ~~~~~~~~~
> includedir /var/lib/sss/pubconf/krb5.include.d/
>
> [libdefaults]
> default_realm = MYDOMAIN.COM
>? ? dns_lookup_realm = false
>? ? dns_lookup_kdc = false
>? ? rdns = false
>? ? ticket_lifetime = 24h
>? ? forwardable = yes
>
> [realms]
>? ? MYDOMAIN.COM = {
>? ? ? kdc = ldap2.mydomain.com:88
>? ? ? master_kdc = ldap2.mydomain.com:88
>? ? ? admin_server = ldap2.mydomain.com:749
>? ? ? default_domain = mydomain.com
>? ? ? pkinit_anchors = FILE:/etc/ipa/ca.crt
>? ? }
>
> [domain_realm]
>? ? .mydomain.com = MYDOMAIN.COM
>? ? mydomain.com = MYDOMAIN.COM
>? ? .mydomain.com = MYDOMAIN.COM
>? ? mydomain.com = MYDOMAIN.COM
> ~~~~~~~~
>
> (I assume you did more anonymizing that expected, ipa-client-install
> does not
> generate 2 domain_realm mappings unless client domain is different that
> server
> domain (e.g. client.other.mydomain.com and server.mydomain.com)).
>
> What I would do in your place is to:
> 1) Backup your current /etc/krb5.conf
> 2) Replace it with the krb5.conf which was generated during
> ipa-client-install
> (you can find non-anonymized version in ipaclient-install.log)
> 3) Try to kinit: kinit skarulkar at MYDOMAIN.COM
> <mailto:skarulkar at MYDOMAIN.COM>
>
> Then it will be easier to troubleshoot. To get more information what kinit
> actually does, try enabling a trace:
>
> # KRB5_TRACE=/dev/stdout kinit skarulkar at MYDOMAIN.COM
> <mailto:skarulkar at MYDOMAIN.COM>
>
> You will be then able to see if it really connects to right IP address which
> would enable you to debug further.
>
> Martin
>
> On 03/24/2014 07:20 PM, Shree wrote:
>? > If you look at the attached logs, you can see it is going to the
> correct dns server. dig information is also correct. There is something
> else going on I can figure out what?
>? >
>? >
>? >
>? > Shreeraj
>? >
> ----------------------------------------------------------------------------------------
>
>? >
>? > Change is the only Constant !
>? >
>? >
>? >
>? > On Saturday, March 22, 2014 2:12 PM, Dmitri Pal <dpal at redhat.com
> <mailto:dpal at redhat.com>> wrote:
>? >
>? > On 03/21/2014 07:44 PM, Shree wrote:
>? > Hi
>? >> Attaching the install log. It complains about unable to reach
>? >? ? ? ? certain ports, however my tests by using telnet were successful.
>? >? ? ? ? Also to refresh your memory the client should be reaching for
>? >? ? ? ? the replica lda2.mydomain.com and not ldap.mydomain.com which it
>? >? ? ? ? does for the most part but I found a couple of instances of
>? >? ? ? ? ldap.mydomain.com in the log. Let me know what you find. I can't
>? >? ? ? ? believe I migrated over 40 servers and only this one refuses to
>? >? ? ? ? install ipa-client.
>? >>
>? >>
>? > If it is getting to the wrong server then it is either looking at
>? >? ? the wrong DNS server (see resolve.conf) which is telling it to use
>? >? ? the wrong IPA server (may be from some old try/POC) or it has some
>? >? ? explicit entries entered in /etc/hosts.
>? >
>? >
>? >
>? >
>? >>
>? >>
>? >> Shreeraj
>? >>
> ----------------------------------------------------------------------------------------
>
>? >>
>? >> Change is the only Constant !
>? >>
>? >>
>? >>
>? >> On Thursday, March 20, 2014 4:29 AM, Martin Kosek <mkosek at redhat.com
> <mailto:mkosek at redhat.com>> wrote:
>? >>
>? >> On 03/19/2014 10:37 PM, Shree wrote:
>? >>
>? >>> Hello
>? >>> I was able to successfully move all my clients to
>? >? ? ? ? ? ? ? ? ? the replica except on the process I had to upgrade the
>? >? ? ? ? ? ? ? ? ? client to "ipa-client-3.0.0-37.el6.x86_64" and some
>? >? ? ? ? ? ? ? ? ? times run a --uninstall
>? >>>
>? >>> . Bit it works for the most part. Have been
>? >? ? ? ? ? ? ? ? ? struggling with one last host with errors like below.
>? >? ? ? ? ? ? ? ? ? I have tested the port connectivity using telnet and
>? >? ? ? ? ? ? ? ? ? netcat commands but the install thinks these ports are
>? >? ? ? ? ? ? ? ? ? blocked?
>? >>>
>? >>>
>? >>>
>? >>>
>? >>> kerberos authentication failed
>? >>> kinit: Cannot contact any KDC for realm
>? >? ? ? ? ? ? ? ? ? 'MYDOMAIN.COM' while getting initial credentials
>? >>>
>? >>> Please make sure the following ports are opened
>? >? ? ? ? ? ? ? ? ? in the firewall settings:
>? >>>? ? ? TCP: 80, 88, 389
>? >>>? ? ? UDP: 88 (at least one of TCP/UDP ports 88
>? >? ? ? ? ? ? ? ? ? has to be open)
>? >>> Also note that following ports are necessary for
>? >? ? ? ? ? ? ? ? ? ipa-client working properly after enrollment:
>? >>>? ? ? TCP: 464
>? >>>? ? ? UDP: 464, 123 (if NTP enabled)
>? >>> Installation failed. Rolling back changes.
>? >>> Disabling client Kerberos and LDAP configurations
>? >>> Redundant SSSD configuration file
>? >? ? ? ? ? ? ? ? ? /etc/sssd/sssd.conf was moved to
>? >? ? ? ? ? ? ? ? ? /etc/sssd/sssd.conf.deleted
>? >>> Restoring client configuration files
>? >>> Client uninstall complete.
>? >>> [root at www <mailto:root at www> /]#

>? >>>
>? >>> In the /var/log/ipaclient-install.log I also see
>? >? ? ? ? ? ? ? ? ? things like below. I get Autodiscovery failures but I
>? >? ? ? ? ? ? ? ? ? am manually entering things and they have been
>? >? ?  working.
>? >>>
>? >>> 2014-03-19T21:13:47Z DEBUG Found:
>? >? ? ? ? ? ? ? ? ? cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
>? >>> 2014-03-19T21:13:47Z DEBUG Discovery result:
>? >? ? ? ? ? ? ? ? ? Success; server=ldap2.mydomain.com,
>? >? ? ? ? ? ? ? ? ? domain=mydomain.com, kdc=ldap.mydomain.com,
>? >? ? ? ? ? ? ? ? ? basedn=dc=mydomain,dc=com
>? >>> 2014-03-19T21:13:47Z DEBUG Validated servers:
>? >? ? ? ? ? ? ? ? ? ldap2.mydomain.com
>? >>> 2014-03-19T21:13:47Z WARNING The failure to use
>? >? ? ? ? ? ? ?  DNS to find your IPA server indicates that your
>? >? ? ? ? ? ? ? ? ? resolv.conf file is not properly configured.
>? >>> 2014-03-19T21:13:47Z INFO Autodiscovery of
>? >? ? ? ? ? ? ? ? ? servers for failover cannot work with this
>? >? ? ? ? ? ? ? ? ? configuration.
>? >>> 2014-03-19T21:13:47Z INFO If you proceed with the
>? >? ? ? ? ? ? ? ? ? installation, services will be configured to always
>? >? ? ? ? ? ? ? ? ? access the discovered server for all operations and
>? >? ? ? ? ? ? ? ? ? will not fail over to other servers in case of
>? >? ? ? ? ? ? ? ? ? failure.
>? >>
>? >> Ok. I would guess you have some DNS issue. But it is
>? >? ? ? ? ? ? ? ? hard to tell without the
>? >> entire ipaclient-install.log of the failed installation.
>? >>
>? >> Martin
>? >>
>? >>
>? >>
>? >>
>? >
>? >
>
>
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140331/6ce7d05d/attachment.htm>

From rcritten at redhat.com  Mon Mar 31 15:09:50 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 31 Mar 2014 11:09:50 -0400
Subject: [Freeipa-users] ipa-client-install fails on replica because of
 kinit cannot contact any KDC
In-Reply-To: <1396278174.64201.YahooMailNeo@web160103.mail.bf1.yahoo.com>
References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<53051B35.2050409@redhat.com>	<1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com!	>	<53051F62.40405@redhat.com>	<1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com!	>	<53052E64.3050903@redhat.com>	<1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c!	!	om>	<53061B18.40001@redhat.com>	<1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<53066CD0.5080501@redhat.!	!	com>
	<1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com>	<1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo!
	!	.com>
	<532A9E07.6040604@redhat.com>	<1395445491.29606.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<532DFCD0.8060907@redhat.com>	<1395685201.97247.YahooMailNeo@web160104.mail.bf1.yahoo.com>	<5331353C.9030603@redhat.com>
	<1396046096.70517.YahooMailNeo@web160103.mail.bf1.yahoo.com>
	<5339756D.5080108@redhat.com>
	<1396278174.64201.YahooMailNeo@web160103.mail.bf1.yahoo.com>
Message-ID: <5339853E.8080108@redhat.com>

Shree wrote:
> Rob
> This is what I get.

Realm is case-sensitive, try skarulkar at MYDOMAIN.COM

rob

>
> [root at www ~]# KRB5_TRACE=/dev/stdout kinit skarulkar at mydomain.com
> [14858] 1396278013.584391: Getting initial credentials for
> skarulkar at mydomain.com
> [14858] 1396278013.584975: Sending request (188 bytes) to mydomain.com
> [14858] 1396278013.585470: Retrying AS request with master KDC
> [14858] 1396278013.585492: Getting initial credentials for
> skarulkar at mydomain.com
> [14858] 1396278013.585848: Sending request (188 bytes) to mydomain.com
> (master)
> kinit: Cannot find KDC for requested realm while getting initial credentials
> [root at www ~]#
>
> Shreeraj
> ----------------------------------------------------------------------------------------
>
>
> Change is the only Constant !
> On Monday, March 31, 2014 7:02 AM, Rob Crittenden <rcritten at redhat.com>
> wrote:
> Shree wrote:
>  > Martin
>  > First of all thank you so much for your detailed analysis. I got a
>  > chance to finally take a look at it today. I tried your suggested
>  > changes to the /etc/krb5.conf and I now get the following response.
>  >
>  > [root at www <mailto:root at www> ~]# kinit
>  > kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting
>  > initial credentials
>  > [root at www <mailto:root at www> ~]# kinit skarulkar
>  > kinit: Cannot contact any KDC for realm ''MYDOMAIN.COM' while getting
>  > initial credentials
>  > [root at www <mailto:root at www> ~]# vi /etc/krb5.conf
>  > [root at www <mailto:root at www> ~]# kinit skarulkar at mydomain.com
> <mailto:skarulkar at mydomain.com>
>  > kinit: Cannot find KDC for requested realm while getting initial
> credentials
>  >
>  > Now I have seen this issue earlier in the project but I don't remember
>  > what I did to fix this.
>  >
>  > ldap.mydomain.com is our primary which connects to ldap2.mydomain.com
>  > that exists in a separate VLAN  through specific ACLs in the firewall.
>  > They sync with each other fine. My clients are only able to talk to
>  > ldap2.mydomain.com. And out of 40 + clients that I moved from ldap to
>  > ldap2 I only seem to have issue with this last one?
>  > I have even tried dropping a test VM in the same VLAN and it had no
>  > issues joining the IPA. So that rules out any ACL misconfigurations to
>  > this VLAN.
>
> Did you try the tracing that Martin suggested?
>
> rob
>
>  >
>  >
>  > Shreeraj
>  >
> ----------------------------------------------------------------------------------------
>  >
>  >
>  > Change is the only Constant !
>  >
>  >
>  > On Tuesday, March 25, 2014 12:55 AM, Martin Kosek <mkosek at redhat.com
> <mailto:mkosek at redhat.com>> wrote:
>  > It searching for ldap.mydomain.com because you still have DNS SRV record
>  > _kerberos._udp.mydomain.com. pointing to it. I would start there.
>  >
>  > As for the failure, I would check that the generated /etc/krb5.conf is
>  > correct:
>  >
>  > ~~~~~~~~~
>  > includedir /var/lib/sss/pubconf/krb5.include.d/
>  >
>  > [libdefaults]
>  > default_realm = MYDOMAIN.COM
>  >    dns_lookup_realm = false
>  >    dns_lookup_kdc = false
>  >    rdns = false
>  >    ticket_lifetime = 24h
>  >    forwardable = yes
>  >
>  > [realms]
>  >    MYDOMAIN.COM = {
>  >      kdc = ldap2.mydomain.com:88
>  >      master_kdc = ldap2.mydomain.com:88
>  >      admin_server = ldap2.mydomain.com:749
>  >      default_domain = mydomain.com
>  >      pkinit_anchors = FILE:/etc/ipa/ca.crt
>  >    }
>  >
>  > [domain_realm]
>  >    .mydomain.com = MYDOMAIN.COM
>  >    mydomain.com = MYDOMAIN.COM
>  >    .mydomain.com = MYDOMAIN.COM
>  >    mydomain.com = MYDOMAIN.COM
>  > ~~~~~~~~
>  >
>  > (I assume you did more anonymizing that expected, ipa-client-install
>  > does not
>  > generate 2 domain_realm mappings unless client domain is different that
>  > server
>  > domain (e.g. client.other.mydomain.com and server.mydomain.com)).
>  >
>  > What I would do in your place is to:
>  > 1) Backup your current /etc/krb5.conf
>  > 2) Replace it with the krb5.conf which was generated during
>  > ipa-client-install
>  > (you can find non-anonymized version in ipaclient-install.log)
>  > 3) Try to kinit: kinit skarulkar at MYDOMAIN.COM
> <mailto:skarulkar at MYDOMAIN.COM>
>  > <mailto:skarulkar at MYDOMAIN.COM <mailto:skarulkar at MYDOMAIN.COM>>
>  >
>  > Then it will be easier to troubleshoot. To get more information what
> kinit
>  > actually does, try enabling a trace:
>  >
>  > # KRB5_TRACE=/dev/stdout kinit skarulkar at MYDOMAIN.COM
> <mailto:skarulkar at MYDOMAIN.COM>
>  > <mailto:skarulkar at MYDOMAIN.COM <mailto:skarulkar at MYDOMAIN.COM>>
>  >
>  > You will be then able to see if it really connects to right IP
> address which
>  > would enable you to debug further.
>  >
>  > Martin
>  >
>  > On 03/24/2014 07:20 PM, Shree wrote:
>  >  > If you look at the attached logs, you can see it is going to the
>  > correct dns server. dig information is also correct. There is something
>  > else going on I can figure out what?
>  >  >
>  >  >
>  >  >
>  >  > Shreeraj
>  >  >
>  >
> ----------------------------------------------------------------------------------------
>  >
>  >  >
>  >  > Change is the only Constant !
>  >  >
>  >  >
>  >  >
>  >  > On Saturday, March 22, 2014 2:12 PM, Dmitri Pal <dpal at redhat.com
> <mailto:dpal at redhat.com>
>  > <mailto:dpal at redhat.com <mailto:dpal at redhat.com>>> wrote:
>  >  >
>  >  > On 03/21/2014 07:44 PM, Shree wrote:
>  >  > Hi
>  >  >> Attaching the install log. It complains about unable to reach
>  >  >        certain ports, however my tests by using telnet were
> successful.
>  >  >        Also to refresh your memory the client should be reaching for
>  >  >        the replica lda2.mydomain.com and not ldap.mydomain.com
> which it
>  >  >        does for the most part but I found a couple of instances of
>  >  >     ldap.mydomain.com in the log. Let me know what you find. I can't
>  >  >        believe I migrated over 40 servers and only this one refuses to
>  >  >        install ipa-client.
>  >  >>
>  >  >>
>  >  > If it is getting to the wrong server then it is either looking at
>  >  >    the wrong DNS server (see resolve.conf) which is telling it to use
>  >  >    the wrong IPA server (may be from some old try/POC) or it has some
>  >  >    explicit entries entered in /etc/hosts.
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >>
>  >  >>
>  >  >> Shreeraj
>  >  >>
>  >
> ----------------------------------------------------------------------------------------
>  >
>  >  >>
>  >  >> Change is the only Constant !
>  >  >>
>  >  >>
>  >  >>
>  >  >> On Thursday, March 20, 2014 4:29 AM, Martin Kosek
> <mkosek at redhat.com <mailto:mkosek at redhat.com>
>  > <mailto:mkosek at redhat.com <mailto:mkosek at redhat.com>>> wrote:
>  >  >>
>  >  >> On 03/19/2014 10:37 PM, Shree wrote:
>  >  >>
>  >  >>> Hello
>  >  >>> I was able to successfully move all my clients to
>  >  >                  the replica except on the process I had to
> upgrade the
>  >  >                  client to "ipa-client-3.0.0-37.el6.x86_64" and some
>  >  >                  times run a --uninstall
>  >  >>>
>  >  >>> . Bit it works for the most part. Have been
>  >  >                  struggling with one last host with errors like below.
>  >  >                  I have tested the port connectivity using telnet and
>  >  >               netcat commands but the install thinks these ports are
>  >  >                  blocked?
>  >  >>>
>  >  >>>
>  >  >>>
>  >  >>>
>  >  >>> kerberos authentication failed
>  >  >>> kinit: Cannot contact any KDC for realm
>  >  >                  'MYDOMAIN.COM' while getting initial credentials
>  >  >>>
>  >  >>> Please make sure the following ports are opened
>  >  >                  in the firewall settings:
>  >  >>>   TCP: 80, 88, 389
>  >  >>>      UDP: 88 (at least one of TCP/UDP ports 88
>  >  >                  has to be open)
>  >  >>> Also note that following ports are necessary for
>  >  >                  ipa-client working properly after enrollment:
>  >  >>>      TCP: 464
>  >  >>>      UDP: 464, 123 (if NTP enabled)
>  >  >>> Installation failed. Rolling back changes.
>  >  >>> Disabling client Kerberos and LDAP configurations
>  >  >>> Redundant SSSD configuration file
>  >  > /etc/sssd/sssd.conf was moved to
>  >  >                  /etc/sssd/sssd.conf.deleted
>  >  >>> Restoring client configuration files
>  >  >>> Client uninstall complete.
>  >  >>> [root at www <mailto:root at www> <mailto:root at www <mailto:root at www>> /]#
>
>  >  >>>
>  >  >>> In the /var/log/ipaclient-install.log I also see
>  >  >                  things like below. I get Autodiscovery failures but I
>  >  >                  am manually entering things and they have been
>  >  >    working.
>  >  >>>
>  >  >>> 2014-03-19T21:13:47Z DEBUG Found:
>  >  >                  cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
>  >  >>> 2014-03-19T21:13:47Z DEBUG Discovery result:
>  >  >                  Success; server=ldap2.mydomain.com,
>  >  >                  domain=mydomain.com, kdc=ldap.mydomain.com,
>  >  >                  basedn=dc=mydomain,dc=com
>  >  >>> 2014-03-19T21:13:47Z DEBUG Validated servers:
>  >  >   ldap2.mydomain.com
>  >  >>> 2014-03-19T21:13:47Z WARNING The failure to use
>  >  >              DNS to find your IPA server indicates that your
>  >  >                  resolv.conf file is not properly configured.
>  >  >>> 2014-03-19T21:13:47Z INFO Autodiscovery of
>  >  >                  servers for failover cannot work with this
>  >  >                  configuration.
>  >  >>> 2014-03-19T21:13:47Z INFO If you proceed with the
>  >  >                  installation, services will be configured to always
>  >  >                  access the discovered server for all operations and
>  >  >                  will not fail over to other servers in case of
>  >  >                  failure.
>  >  >>
>  >  >> Ok. I would guess you have some DNS issue. But it is
>  >  >                hard to tell without the
>  >  >> entire ipaclient-install.log of the failed installation.
>  >  >>
>  >  >> Martin
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  > >
>  >  >
>  >
>  >
>  >
>  >
>  >
>  > _______________________________________________
>  > Freeipa-users mailing list
>  > Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
>  > https://www.redhat.com/mailman/listinfo/freeipa-users
>  >
>
>
>



From shreerajkarulkar at yahoo.com  Mon Mar 31 15:14:36 2014
From: shreerajkarulkar at yahoo.com (Shree)
Date: Mon, 31 Mar 2014 08:14:36 -0700 (PDT)
Subject: [Freeipa-users] ipa-client-install fails on replica because of
	kinit cannot contact any KDC
In-Reply-To: <5339853E.8080108@redhat.com>
References: <1391740394.55730.YahooMailNeo@web160103.mail.bf1.yahoo.com>	<53051B35.2050409@redhat.com>	<1392844152.65387.YahooMailNeo@web160101.mail.bf1.yahoo.com!	>	<53051F62.40405@redhat.com>	<1392846681.99272.YahooMailNeo@web160106.mail.bf1.yahoo.com!	>	<53052E64.3050903@redhat.com>	<1392853943.52122.YahooMailNeo@web160103.mail.bf1.yahoo.c!	!	om>	<53061B18.40001@redhat.com>	<1392926335.76571.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<53066CD0.5080501@redhat.!	!	com>
	<1392958339.79606.YahooMailNeo@web160106.mail.bf1.yahoo.com>	<1395265074.69093.YahooMailNeo@web160101.mail.bf1.yahoo!
	!	.com>
	<532A9E07.6040604@redhat.com>	<1395445491.29606.YahooMailNeo@web160105.mail.bf1.yahoo.com>	<532DFCD0.8060907@redhat.com>	<1395685201.97247.YahooMailNeo@web160104.mail.bf1.yahoo.com>	<5331353C.9030603@redhat.com>
	<1396046096.70517.YahooMailNeo@web160103.mail.bf1.yahoo.com>
	<5339756D.5080108@redhat.com>
	<1396278174.64201.YahooMailNeo@web160103.mail.bf1.yahoo.com>
	<5339853E.8080108@redhat! .com>
Message-ID: <1396278876.85775.YahooMailNeo@web160104.mail.bf1.yahoo.com>

Excellent Rob
I see that it is trying the IP address on the main master (ldap.mydomain) and not the ldap2.mydomain. So how do I fix it or where do I find that?


?
Shreeraj 
---------------------------------------------------------------------------------------- 

Change is the only Constant !
On Monday, March 31, 2014 8:09 AM, Rob Crittenden <rcritten at redhat.com> wrote:
 
Shree wrote:
> Rob
> This is what I get.

Realm is case-sensitive, try skarulkar at MYDOMAIN.COM

rob

>
> [root at www ~]# KRB5_TRACE=/dev/stdout kinit skarulkar at mydomain.com
> [14858] 1396278013.584391: Getting initial credentials for
> skarulkar at mydomain.com
> [14858] 1396278013.584975: Sending request (188 bytes) to mydomain.com
> [14858] 1396278013.585470: Retrying AS request with master KDC
> [14858] 1396278013.585492: Getting initial credentials for
> skarulkar at mydomain.com
> [14858] 1396278013.585848: Sending request (188 bytes) to mydomain.com
> (master)
> kinit: Cannot find KDC for requested realm while getting initial credentials
> [root at www ~]#
>
> Shreeraj
> ----------------------------------------------------------------------------------------
>
>
> Change is the only Constant !
> On Monday, March 31, 2014 7:02 AM, Rob Crittenden <rcritten at redhat.com>
> wrote:
> Shree wrote:
>? > Martin
>? > First of all thank you so much for your detailed analysis. I got a
>? > chance to finally take a look at it today. I tried your suggested
>? > changes to the /etc/krb5.conf and I now get the following response.
>? >
>? > [root at www <mailto:root at www> ~]# kinit
>? > kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting
>? > initial credentials
>? > [root at www <mailto:root at www> ~]# kinit skarulkar
>? > kinit: Cannot contact any KDC for realm ''MYDOMAIN.COM' while getting
>? > initial credentials
>? > [root at www <mailto:root at www> ~]# vi /etc/krb5.conf
>? > [root at www <mailto:root at www> ~]# kinit skarulkar at mydomain.com
> <mailto:skarulkar at mydomain.com>
>? > kinit: Cannot find KDC for requested realm while getting initial
> credentials
>? >
>? > Now I have seen this issue earlier in the project but I don't remember
>? > what I did to fix this.
>? >
>? > ldap.mydomain.com is our primary which connects to ldap2.mydomain.com
>? > that exists in a separate VLAN? through specific ACLs in the firewall.
>? > They sync with each other fine. My clients are only able to talk to
>? > ldap2.mydomain.com. And out of 40 + clients that I moved from ldap to
>? > ldap2 I only seem to have issue with this last one?
>? > I have even tried dropping a test VM in the same VLAN and it had no
>? > issues joining the IPA. So that rules out any ACL misconfigurations to
>? > this VLAN.
>
> Did you try the tracing that Martin suggested?
>
> rob
>
>? >
>? >
>? > Shreeraj
>? >
> ----------------------------------------------------------------------------------------
>? >
>? >
>? > Change is the only Constant !
>? >
>? >
>? > On Tuesday, March 25, 2014 12:55 AM, Martin Kosek <mkosek at redhat.com
> <mailto:mkosek at redhat.com>> wrote:
>? > It searching for ldap.mydomain.com because you still have DNS SRV record
>? > _kerberos._udp.mydomain.com. pointing to it. I would start there.
>? >
>? > As for the failure, I would check that the generated /etc/krb5.conf is
>? > correct:
>? >
>? > ~~~~~~~~~
>? > includedir /var/lib/sss/pubconf/krb5.include.d/
>? >
>? > [libdefaults]
>? > default_realm = MYDOMAIN.COM
>? >? ? dns_lookup_realm = false
>? >? ? dns_lookup_kdc = false
>? >? ? rdns = false
>? >? ? ticket_lifetime = 24h
>? >? ? forwardable = yes
>? >
>? > [realms]
>? >? ? MYDOMAIN.COM = {
>? >? ? ? kdc = ldap2.mydomain.com:88
>? >? ? ? master_kdc = ldap2.mydomain.com:88
>? >? ? ? admin_server = ldap2.mydomain.com:749
>? >? ? ? default_domain = mydomain.com
>? >? ? ? pkinit_anchors = FILE:/etc/ipa/ca.crt
>? >? ? }
>? >
>? > [domain_realm]
>? >? ? .mydomain.com = MYDOMAIN.COM
>? >? ? mydomain.com = MYDOMAIN.COM
>? >? ? .mydomain.com = MYDOMAIN.COM
>? >? ? mydomain.com = MYDOMAIN.COM
>? > ~~~~~~~~
>? >
>? > (I assume you did more anonymizing that expected, ipa-client-install
>? > does not
>? > generate 2 domain_realm mappings unless client domain is different that
>? > server
>? > domain (e.g. client.other.mydomain.com and server.mydomain.com)).
>? >
>? > What I would do in your place is to:
>? > 1) Backup your current /etc/krb5.conf
>? > 2) Replace it with the krb5.conf which was generated during
>? > ipa-client-install
>? > (you can find non-anonymized version in ipaclient-install.log)
>? > 3) Try to kinit: kinit skarulkar at MYDOMAIN.COM
> <mailto:skarulkar at MYDOMAIN.COM>
>? > <mailto:skarulkar at MYDOMAIN.COM <mailto:skarulkar at MYDOMAIN.COM>>
>? >
>? > Then it will be easier to troubleshoot. To get more information what
> kinit
>? > actually does, try enabling a trace:
>? >
>? > # KRB5_TRACE=/dev/stdout kinit skarulkar at MYDOMAIN.COM
> <mailto:skarulkar at MYDOMAIN.COM>
>? > <mailto:skarulkar at MYDOMAIN.COM <mailto:skarulkar at MYDOMAIN.COM>>
>? >
>? > You will be then able to see if it really connects to right IP
> address which
>? > would enable you to debug further.
>? >
>? > Martin
>? >
>? > On 03/24/2014 07:20 PM, Shree wrote:
>? >? > If you look at the attached logs, you can see it is going to the
>? > correct dns server. dig information is also correct. There is something
>? > else going on I can figure out what?
>? >? >
>? >? >
>? >? >
>? >? > Shreeraj
>? >? >
>? >
> ----------------------------------------------------------------------------------------
>? >
>? >? >
>? >? > Change is the only Constant !
>? >? >
>? >? >
>? >? >
>? >? > On Saturday, March 22, 2014 2:12 PM, Dmitri Pal <dpal at redhat.com
> <mailto:dpal at redhat.com>
>? > <mailto:dpal at redhat.com <mailto:dpal at redhat.com>>> wrote:
>? >? >
>? >? > On 03/21/2014 07:44 PM, Shree wrote:
>? >? > Hi
>? >? >> Attaching the install log. It complains about unable to reach
>? >? >? ? ? ? certain ports, however my tests by using telnet were
> successful.
>? >? >? ? ? ? Also to refresh your memory the client should be reaching for
>? >? >? ? ? ? the replica lda2.mydomain.com and not ldap.mydomain.com
> which it
>? >? >? ? ? ? does for the most part but I found a couple of instances of
>? >? >? ?  ldap.mydomain.com in the log. Let me know what you find. I can't
>? >? >? ? ? ? believe I migrated over 40 servers and only this one refuses to
>? >? >? ? ? ? install ipa-client.
>? >? >>
>? >? >>
>? >? > If it is getting to the wrong server then it is either looking at
>? >? >? ? the wrong DNS server (see resolve.conf) which is telling it to use
>? >? >? ? the wrong IPA server (may be from some old try/POC) or it has some
>? >? >? ? explicit entries entered in /etc/hosts.
>? >? >
>? >? >
>? >? >
>? >? >
>? >? >>
>? >? >>
>? >? >> Shreeraj
>? >? >>
>? >
> ----------------------------------------------------------------------------------------
>? >
>? >? >>
>? >? >> Change is the only Constant !
>? >? >>
>? >? >>
>? >? >>
>? >? >> On Thursday, March 20, 2014 4:29 AM, Martin Kosek
> <mkosek at redhat.com <mailto:mkosek at redhat.com>
>? > <mailto:mkosek at redhat.com <mailto:mkosek at redhat.com>>> wrote:
>? >? >>
>? >? >> On 03/19/2014 10:37 PM, Shree wrote:
>? >? >>
>? >? >>> Hello
>? >? >>> I was able to successfully move all my clients to
>? >? >? ? ? ? ? ? ? ? ? the replica except on the process I had to
> upgrade the
>? >? >? ? ? ? ? ? ? ? ? client to "ipa-client-3.0.0-37.el6.x86_64" and some
>? >? >? ? ? ? ? ? ? ? ? times run a --uninstall
>? >? >>>
>? >? >>> . Bit it works for the most part. Have been
>? >? >? ? ? ? ? ? ? ? ? struggling with one last host with errors like below.
>? >? >? ? ? ? ? ? ? ? ? I have tested the port connectivity using telnet and
>? >? >? ? ? ? ? ? ?  netcat commands but the install thinks these ports are
>? >? >? ? ? ? ? ? ? ? ? blocked?
>? >? >>>
>? >? >>>
>? >? >>>
>? >? >>>
>? >? >>> kerberos authentication failed
>? >? >>> kinit: Cannot contact any KDC for realm
>? >? >? ? ? ? ? ? ? ? ? 'MYDOMAIN.COM' while getting initial credentials
>? >? >>>
>? >? >>> Please make sure the following ports are opened
>? >? >? ? ? ? ? ? ? ? ? in the firewall settings:
>? >? >>>?  TCP: 80, 88, 389
>? >? >>>? ? ? UDP: 88 (at least one of TCP/UDP ports 88
>? >? >? ? ? ? ? ? ? ? ? has to be open)
>? >? >>> Also note that following ports are necessary for
>? >? >? ? ? ? ? ? ? ? ? ipa-client working properly after enrollment:
>? >? >>>? ? ? TCP: 464
>? >? >>>? ? ? UDP: 464, 123 (if NTP enabled)
>? >? >>> Installation failed. Rolling back changes.
>? >? >>> Disabling client Kerberos and LDAP configurations
>? >? >>> Redundant SSSD configuration file
>? >? > /etc/sssd/sssd.conf was moved to
>? >? >? ? ? ? ? ? ? ? ? /etc/sssd/sssd.conf.deleted
>? >? >>> Restoring client configuration files
>? >? >>> Client uninstall complete.
>? >? >>> [root at www <mailto:root at www> <mailto:root at www <mailto:root at www>> /]#
>
>? >? >>>
>? >? >>> In the /var/log/ipaclient-install.log I also see
>? >? >? ? ? ? ? ? ? ? ? things like below. I get Autodiscovery failures but I
>? >? >? ? ? ? ? ? ? ? ? am manually entering things and they have been
>? >? >? ? working.
>? >? >>>
>? >? >>> 2014-03-19T21:13:47Z DEBUG Found:
>? >? >? ? ? ? ? ? ? ? ? cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
>? >? >>> 2014-03-19T21:13:47Z DEBUG Discovery result:
>? >? >? ? ? ? ? ? ? ? ? Success; server=ldap2.mydomain.com,
>? >? >? ? ? ? ? ? ? ? ? domain=mydomain.com, kdc=ldap.mydomain.com,
>? >? >? ? ? ? ? ? ? ? ? basedn=dc=mydomain,dc=com
>? >? >>> 2014-03-19T21:13:47Z DEBUG Validated servers:
>? >? >?  ldap2.mydomain.com
>? >? >>> 2014-03-19T21:13:47Z WARNING The failure to use
>? >? >? ? ? ? ? ? ? DNS to find your IPA server indicates that your
>? >? >? ? ? ? ? ? ? ? ? resolv.conf file is not properly configured.
>? >? >>> 2014-03-19T21:13:47Z INFO Autodiscovery of
>? >? >? ? ? ? ? ? ? ? ? servers for failover cannot work with this
>? >? >? ? ? ? ? ? ? ? ? configuration.
>? >? >>> 2014-03-19T21:13:47Z INFO If you proceed with the
>? >? >? ? ? ? ? ? ? ? ? installation, services will be configured to always
>? >? >? ? ? ? ? ? ? ? ? access the discovered server for all operations and
>? >? >? ? ? ? ? ? ? ? ? will not fail over to other servers in case of
>? >? >? ? ? ? ? ? ? ? ? failure.
>? >? >>
>? >? >> Ok. I would guess you have some DNS issue. But it is
>? >? >? ? ? ? ? ? ? ? hard to tell without the
>? >? >> entire ipaclient-install.log of the failed installation.
>? >? >>
>? >? >> Martin
>? >? >>
>? >? >>
>? >? >>
>? >? >>
>? > >
>? >? >
>? >
>? >
>? >
>? >
>? >
>? > _______________________________________________
>? > Freeipa-users mailing list
>? > Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>

>? > https://www.redhat.com/mailman/listinfo/freeipa-users
>? >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140331/46df2333/attachment.htm>

From michael.mcconachie at hotmail.com  Mon Mar 31 18:59:30 2014
From: michael.mcconachie at hotmail.com (The Dude)
Date: Mon, 31 Mar 2014 18:59:30 +0000
Subject: [Freeipa-users] ipa-server-install + NATTED interface question
Message-ID: <BAY179-W166B0111BDE2716CEC1F48C630@phx.gbl>

Hi all; avid user of both FreeIPA and IPA for a few years now. I have a unique situation that I hope someone can provide some insight, or help with. I am presented a private, and public (floating) IP after RX a VM from my IaaS provider. The 'public' IP is NATted, and not visible from w/in the VM, but is reachable outside of the VM.

In other words, if you were to do an 'ip a': eth0 would return the private IP.

11.11.11.11 (private)192.168.10.10 (public)


Because the installer only sees the 11.11.11.11 address, it bombs saying that I can't use that public IP (being obfuscated by NAT). So, my question is: if I have to use the private IP for installs, what configs should I edit to make Apache/TC respond to the public IP as requests come into it?

I have already modified the conf/server.xml file, and added an 'address' filed/property.Apache might need some mods, I headed over to the httpd.conf file and didn't see anything out of the ordinary (except there are 0 VirtualServer entries..)

Ideas?

Michael J. McConachie | keys.fedoraproject.org | PubKey: 0xEDE583C4
NOTE: The information included and/or attached in this electronic mail transmission may contain confidential or privileged information and is intended solely for the addressee(s). Any unauthorized disclosure, reproduction, distribution or the taking of action in reliance on the contents of the information are strictly prohibited. If you have received the message in error, please notify the sender by reply transmission and delete the message without copying, disclosing or forwarding.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140331/85a761e5/attachment.htm>

From mail at willsheldon.com  Mon Mar 31 19:13:30 2014
From: mail at willsheldon.com (Will Sheldon)
Date: Mon, 31 Mar 2014 12:13:30 -0700
Subject: [Freeipa-users] ipa-server-install + NATTED interface question
In-Reply-To: <BAY179-W166B0111BDE2716CEC1F48C630@phx.gbl>
References: <BAY179-W166B0111BDE2716CEC1F48C630@phx.gbl>
Message-ID: <BE5E12D31D9B40FE914DA610A0D258D2@willsheldon.com>


I had this issue as well.

It would be good to add a `curl icanhazip.com` check to the script to allow for 1:1 nat in places like AWS.

I successfully worked around the issue by allocating the external IP to an internal sub interface during the install:

so run:

ifconfig eth0:0 192.168.10.10 netmask 255.255.255.0 up 

then try the install again.



Kind regards,

Will Sheldon


On Monday, March 31, 2014 at 11:59 AM, The Dude wrote:

> Hi all; avid user of both FreeIPA and IPA for a few years now. I have a unique situation that I hope someone can provide some insight, or help with. I am presented a private, and public (floating) IP after RX a VM from my IaaS provider. The 'public' IP is NATted, and not visible from w/in the VM, but is reachable outside of the VM.
> 
> In other words, if you were to do an 'ip a': eth0 would return the private IP.
> 
> 11.11.11.11 (private)
> 192.168.10.10 (public)
> 
> 
> Because the installer only sees the 11.11.11.11 address, it bombs saying that I can't use that public IP (being obfuscated by NAT). So, my question is: if I have to use the private IP for installs, what configs should I edit to make Apache/TC respond to the public IP as requests come into it?
> 
> I have already modified the conf/server.xml file, and added an 'address' filed/property.
> Apache might need some mods, I headed over to the httpd.conf file and didn't see anything out of the ordinary (except there are 0 VirtualServer entries..)
> 
> Ideas?
> 
> Michael J. McConachie | keys.fedoraproject.org (http://keys.fedoraproject.org) | PubKey: 0xEDE583C4
> NOTE: The information included and/or attached in this electronic mail transmission may contain confidential or privileged information and is intended solely for the addressee(s). Any unauthorized disclosure, reproduction, distribution or the taking of action in reliance on the contents of the information are strictly prohibited. If you have received the message in error, please notify the sender by reply transmission and delete the message without copying, disclosing or forwarding.
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com (mailto:Freeipa-users at redhat.com)
> https://www.redhat.com/mailman/listinfo/freeipa-users
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140331/81727de8/attachment.htm>

From michael.mcconachie at hotmail.com  Mon Mar 31 19:24:42 2014
From: michael.mcconachie at hotmail.com (The Dude)
Date: Mon, 31 Mar 2014 19:24:42 +0000
Subject: [Freeipa-users] ipa-server-install + NATTED interface question
In-Reply-To: <BE5E12D31D9B40FE914DA610A0D258D2@willsheldon.com>
References: <BAY179-W166B0111BDE2716CEC1F48C630@phx.gbl>,
	<BE5E12D31D9B40FE914DA610A0D258D2@willsheldon.com>
Message-ID: <BAY179-W64E0E28633DCB8E7F5B7D48C630@phx.gbl>

Hi Will,

Hilarious. It's always after you hit 'enter' when sending emails to distro lists that you realize what you should have done. (I did what you mentioned below moments after sending out the email to the list.)

None the less, I wanted to say THANK YOU for responding. Hopefully, it will help others out there.

Have a great day,

Mike



Date: Mon, 31 Mar 2014 12:13:30 -0700
From: mail at willsheldon.com
To: michael.mcconachie at hotmail.com
CC: freeipa-users at redhat.com
Subject: Re: [Freeipa-users] ipa-server-install + NATTED interface question


                
                    

                I had this issue as well.
It would be good to add a `curl icanhazip.com` check to the script to allow for 1:1 nat in places like AWS.
I successfully worked around the issue by allocating the external IP to an internal sub interface during the install:
so run:
ifconfig eth0:0 192.168.10.10 netmask 255.255.255.0 up 
then try the install again.

                

Kind regards,



Will Sheldon


                 
                On Monday, March 31, 2014 at 11:59 AM, The Dude wrote:
                
                    


Hi all; avid user of both FreeIPA and IPA for a few years now. I have a unique situation that I hope someone can provide some insight, or help with. I am presented a private, and public (floating) IP after RX a VM from my IaaS provider. The 'public' IP is NATted, and not visible from w/in the VM, but is reachable outside of the VM.

In other words, if you were to do an 'ip a': eth0 would return the private IP.

11.11.11.11 (private)192.168.10.10 (public)


Because the installer only sees the 11.11.11.11 address, it bombs saying that I can't use that public IP (being obfuscated by NAT). So, my question is: if I have to use the private IP for installs, what configs should I edit to make Apache/TC respond to the public IP as requests come into it?

I have already modified the conf/server.xml file, and added an 'address' filed/property.Apache might need some mods, I headed over to the httpd.conf file and didn't see anything out of the ordinary (except there are 0 VirtualServer entries..)

Ideas?

Michael J. McConachie | keys.fedoraproject.org | PubKey: 0xEDE583C4
NOTE: The information included and/or attached in this electronic mail transmission may contain confidential or privileged information and is intended solely for the addressee(s). Any unauthorized disclosure, reproduction, distribution or the taking of action in reliance on the contents of the information are strictly prohibited. If you have received the message in error, please notify the sender by reply transmission and delete the message without copying, disclosing or forwarding.
 		 	   		  
_______________________________________________Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users
                 
                 
                 
                 
                
                 
                
                    

                 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140331/5af922f1/attachment.htm>

From gustavoberman at gmail.com  Mon Mar 31 19:15:21 2014
From: gustavoberman at gmail.com (Gustavo Berman)
Date: Mon, 31 Mar 2014 19:15:21 +0000 (UTC)
Subject: [Freeipa-users]
	=?utf-8?q?cant_authenticate_using_freeipa_userid_?=
	=?utf-8?q?on=09ubuntu12=2E04?=
References: <5332922E.6060906@lftechnology.com>
Message-ID: <loom.20140331T211153-825@post.gmane.org>


Sabin Ranjit <sabinranjit at ...> writes:

> 
> 
>     hi,
>     i followed this page for the installation of freeipa client over the
>     ubuntu 12.04
server.http://www.redhat.com/archives/freeipa-users/2013-June/msg00091.html
>     everything seem to go as mentioned in the page. when i get at the
>     freeipa server with the command ipa host-find 
>     i can even see my ubuntu server listed there with "Keytab: True". The
problem is that im not being able
>       to authenticate with the username listed in the freeipa server.
>       if i try to run : "su ldapuserid" ubuntu errors "unknown id:
>       ldapuserid"
>       i cant even ssh to the ubuntu server with the ldapuserid.
>       what can be the possible solutions?
>       please help. thanks.
>       regards,
>       sabin
>   


Hi Sabin
Please try my howto:
http://askubuntu.com/questions/295075/freeipa-client-on-ubuntu

I assembled it from that same mail and other sources

Tavo.




From rcritten at redhat.com  Mon Mar 31 20:58:29 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 31 Mar 2014 16:58:29 -0400
Subject: [Freeipa-users] cant authenticate using freeipa userid on
	ubuntu12.04
In-Reply-To: <loom.20140331T211153-825@post.gmane.org>
References: <5332922E.6060906@lftechnology.com>
	<loom.20140331T211153-825@post.gmane.org>
Message-ID: <5339D6F5.8040608@redhat.com>

Gustavo Berman wrote:
>
> Sabin Ranjit <sabinranjit at ...> writes:
>
>>
>>
>>      hi,
>>      i followed this page for the installation of freeipa client over the
>>      ubuntu 12.04
> server.http://www.redhat.com/archives/freeipa-users/2013-June/msg00091.html
>>      everything seem to go as mentioned in the page. when i get at the
>>      freeipa server with the command ipa host-find
>>      i can even see my ubuntu server listed there with "Keytab: True". The
> problem is that im not being able
>>        to authenticate with the username listed in the freeipa server.
>>        if i try to run : "su ldapuserid" ubuntu errors "unknown id:
>>        ldapuserid"
>>        i cant even ssh to the ubuntu server with the ldapuserid.
>>        what can be the possible solutions?
>>        please help. thanks.
>>        regards,
>>        sabin
>>
>
>
> Hi Sabin
> Please try my howto:
> http://askubuntu.com/questions/295075/freeipa-client-on-ubuntu
>
> I assembled it from that same mail and other sources
>
> Tavo.

Sabin, if you can confirm these steps maybe we can add this to the Howto 
section on freeipa.org. Except for the localhost thing (probably 
unnecessary) and maybe messing with the version (we might agree to 
disagree on that) this looks really good.

cheers

rob



From tmaugh at boingo.com  Mon Mar 31 22:36:38 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Mon, 31 Mar 2014 22:36:38 +0000
Subject: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled
 to new server cant authenticate
Message-ID: <c16c7bc4a4f34705b1c746c775d49541@BY2PR03MB176.namprd03.prod.outlook.com>

Hi,

I have a rhel5 client  I had problems with my IPA environment and had to rebuild

I'm on the latest version of IPA with a red hat 6 server

I successfully enrolled the client to the new server (same domain, same realm) I had removed all old certs, sysrestores, and ipa/default.conf

I can ssh to the box as root, and then either su or kinit to any IPA user with out issue

But when I try to ssh as the ipauser to the box it gives me permission denied, please try again

I cleared out the sssd cache and restarted sssd

Is there something I'm missing or a log to check?

I need to worked this out before I move forward enrolling other previously enrolled clients.

Thanks

Todd Maugh
Sr System Engineer
Boingo Wireless
tmaugh at boingo.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140331/ed7d6484/attachment.htm>

From tmaugh at boingo.com  Mon Mar 31 22:39:17 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Mon, 31 Mar 2014 22:39:17 +0000
Subject: [Freeipa-users] FW: cant authenticate using freeipa userid
	on	ubuntu12.04
References: <5332922E.6060906@lftechnology.com>
	<loom.20140331T211153-825@post.gmane.org> <5339D6F5.8040608@redhat.com>
Message-ID: <c1a926db7b8a40d2a29d7c6aaf21604f@BY2PR03MB176.namprd03.prod.outlook.com>

I have found this to be my only way to get Ubuntu to work with ipa as clients

Add the IDM servers to the hosts file

		echo "{ip address of idmserver}   {fqdn of idm server " >> /etc/hosts

Set the Hostname for the box

		echo "ubuntu-idm-02.boingo.com" > /etc/hostname
	
Add ipa and sssd repos to box

		apt-add-repository http://ppa.launchpad.net/freeipa/ppa/ubuntu

		apt-add-repository 'http://ppa.launchpad.net/sssd/updates/ubuntu'

		apt-get update

Install the Ipa Client

		apt-get install -y freeipa-client


Realm: YOUR REALM

DOMAIN: YOUR DOMAIN

SERVER: FQDN OF YOUR IDMSERVER

user to enroll: admin

password : YOUR PASSWORD


Make some modifications to ubuntu

		mkdir -p /etc/pki/nssdb

		certutil -N --empty-password -d /etc/pki/nssdb 

		mkdir -p /var/run/ipa

Clear out original install 

		rm -f /etc/ipa/default.conf

Move aside and re version the python version

		cp /usr/share/pyshared/ipapython/version.py /usr/share/pyshared/ipapython/version.py.bak

		sed -i "s/API_VERSION=.*/API_VERSION=u'2.49'/g" /usr/share/pyshared/ipapython/version.py

install the ipa

		ipa-client-install


		restart sssd

		service sssd restart



you should then have a walking talking Ubuntu client

-----Original Message-----
From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden
Sent: Monday, March 31, 2014 1:58 PM
To: Gustavo Berman; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] cant authenticate using freeipa userid on ubuntu12.04

Gustavo Berman wrote:
>
> Sabin Ranjit <sabinranjit at ...> writes:
>
>>
>>
>>      hi,
>>      i followed this page for the installation of freeipa client over the
>>      ubuntu 12.04
> server.http://www.redhat.com/archives/freeipa-users/2013-June/msg00091
> .html
>>      everything seem to go as mentioned in the page. when i get at the
>>      freeipa server with the command ipa host-find
>>      i can even see my ubuntu server listed there with "Keytab: 
>> True". The
> problem is that im not being able
>>        to authenticate with the username listed in the freeipa server.
>>        if i try to run : "su ldapuserid" ubuntu errors "unknown id:
>>        ldapuserid"
>>        i cant even ssh to the ubuntu server with the ldapuserid.
>>        what can be the possible solutions?
>>        please help. thanks.
>>        regards,
>>        sabin
>>
>
>
> Hi Sabin
> Please try my howto:
> http://askubuntu.com/questions/295075/freeipa-client-on-ubuntu
>
> I assembled it from that same mail and other sources
>
> Tavo.

Sabin, if you can confirm these steps maybe we can add this to the Howto section on freeipa.org. Except for the localhost thing (probably
unnecessary) and maybe messing with the version (we might agree to disagree on that) this looks really good.

cheers

rob

_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



From rcritten at redhat.com  Mon Mar 31 22:43:39 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 31 Mar 2014 18:43:39 -0400
Subject: [Freeipa-users] uninstalled IPA client and reinstalled and
 enrolled to new server cant authenticate
In-Reply-To: <c16c7bc4a4f34705b1c746c775d49541@BY2PR03MB176.namprd03.prod.outlook.com>
References: <c16c7bc4a4f34705b1c746c775d49541@BY2PR03MB176.namprd03.prod.outlook.com>
Message-ID: <5339EF9B.3070606@redhat.com>

Todd Maugh wrote:
> Hi,
>
> I have a rhel5 client  I had problems with my IPA environment and had to
> rebuild
>
> I?m on the latest version of IPA with a red hat 6 server
>
> I successfully enrolled the client to the new server (same domain, same
> realm) I had removed all old certs, sysrestores, and ipa/default.conf
>
> I can ssh to the box as root, and then either su or kinit to any IPA
> user with out issue
>
> But when I try to ssh as the ipauser to the box it gives me permission
> denied, please try again
>
> I cleared out the sssd cache and restarted sssd
>
> Is there something I?m missing or a log to check?
>
> I need to worked this out before I move forward enrolling other
> previously enrolled clients.

Check your HBAC rules.

rob



From tmaugh at boingo.com  Mon Mar 31 22:30:28 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Mon, 31 Mar 2014 22:30:28 +0000
Subject: [Freeipa-users] cant authenticate using freeipa userid
	on	ubuntu12.04
In-Reply-To: <5339D6F5.8040608@redhat.com>
References: <5332922E.6060906@lftechnology.com>
	<loom.20140331T211153-825@post.gmane.org> <5339D6F5.8040608@redhat.com>
Message-ID: <461636472dbe40ab886f1d98d9ec7f02@BY2PR03MB176.namprd03.prod.outlook.com>

I have found this to be my only way to get Ubuntu to work with ipa as clients

Add the IDM servers to the hosts file

		echo "{ip address of idmserver}   {fqdn of idm server " >> /etc/hosts

Set the Hostname for the box

		echo "ubuntu-idm-02.boingo.com" > /etc/hostname
	
Add ipa and sssd repos to box

		apt-add-repository http://ppa.launchpad.net/freeipa/ppa/ubuntu

		apt-add-repository 'http://ppa.launchpad.net/sssd/updates/ubuntu'

		apt-get update

Install the Ipa Client

		apt-get install -y freeipa-client


Realm: YOUR REALM

DOMAIN: YOUR DOMAIN

SERVER: FQDN OF YOUR IDMSERVER

user to enroll: admin

password : YOUR PASSWORD


Make some modifications to ubuntu

		mkdir -p /etc/pki/nssdb

		certutil -N --empty-password -d /etc/pki/nssdb 

		mkdir -p /var/run/ipa

Clear out original install 

		rm -f /etc/ipa/default.conf

Move aside and re version the python version

		cp /usr/share/pyshared/ipapython/version.py /usr/share/pyshared/ipapython/version.py.bak

		sed -i "s/API_VERSION=.*/API_VERSION=u'2.49'/g" /usr/share/pyshared/ipapython/version.py

install the ipa

		ipa-client-install


		restart sssd

		service sssd restart



you should then have a walking talking Ubuntu client

-----Original Message-----
From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden
Sent: Monday, March 31, 2014 1:58 PM
To: Gustavo Berman; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] cant authenticate using freeipa userid on ubuntu12.04

Gustavo Berman wrote:
>
> Sabin Ranjit <sabinranjit at ...> writes:
>
>>
>>
>>      hi,
>>      i followed this page for the installation of freeipa client over the
>>      ubuntu 12.04
> server.http://www.redhat.com/archives/freeipa-users/2013-June/msg00091
> .html
>>      everything seem to go as mentioned in the page. when i get at the
>>      freeipa server with the command ipa host-find
>>      i can even see my ubuntu server listed there with "Keytab: 
>> True". The
> problem is that im not being able
>>        to authenticate with the username listed in the freeipa server.
>>        if i try to run : "su ldapuserid" ubuntu errors "unknown id:
>>        ldapuserid"
>>        i cant even ssh to the ubuntu server with the ldapuserid.
>>        what can be the possible solutions?
>>        please help. thanks.
>>        regards,
>>        sabin
>>
>
>
> Hi Sabin
> Please try my howto:
> http://askubuntu.com/questions/295075/freeipa-client-on-ubuntu
>
> I assembled it from that same mail and other sources
>
> Tavo.

Sabin, if you can confirm these steps maybe we can add this to the Howto section on freeipa.org. Except for the localhost thing (probably
unnecessary) and maybe messing with the version (we might agree to disagree on that) this looks really good.

cheers

rob

_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



From tmaugh at boingo.com  Mon Mar 31 22:46:12 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Mon, 31 Mar 2014 22:46:12 +0000
Subject: [Freeipa-users] uninstalled IPA client and reinstalled and
 enrolled to new server cant authenticate
In-Reply-To: <5339EF9B.3070606@redhat.com>
References: <c16c7bc4a4f34705b1c746c775d49541@BY2PR03MB176.namprd03.prod.outlook.com>
	<5339EF9B.3070606@redhat.com>
Message-ID: <94b3969cbcd3400d804b4c3dc4332fd7@BY2PR03MB176.namprd03.prod.outlook.com>

HBAC rules are set to allow_all enabled 

-----Original Message-----
From: Rob Crittenden [mailto:rcritten at redhat.com] 
Sent: Monday, March 31, 2014 3:44 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate

Todd Maugh wrote:
> Hi,
>
> I have a rhel5 client  I had problems with my IPA environment and had 
> to rebuild
>
> I'm on the latest version of IPA with a red hat 6 server
>
> I successfully enrolled the client to the new server (same domain, 
> same
> realm) I had removed all old certs, sysrestores, and ipa/default.conf
>
> I can ssh to the box as root, and then either su or kinit to any IPA 
> user with out issue
>
> But when I try to ssh as the ipauser to the box it gives me permission 
> denied, please try again
>
> I cleared out the sssd cache and restarted sssd
>
> Is there something I'm missing or a log to check?
>
> I need to worked this out before I move forward enrolling other 
> previously enrolled clients.

Check your HBAC rules.

rob




From rcritten at redhat.com  Mon Mar 31 22:52:32 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 31 Mar 2014 18:52:32 -0400
Subject: [Freeipa-users] uninstalled IPA client and reinstalled and
 enrolled to new server cant authenticate
In-Reply-To: <94b3969cbcd3400d804b4c3dc4332fd7@BY2PR03MB176.namprd03.prod.outlook.com>
References: <c16c7bc4a4f34705b1c746c775d49541@BY2PR03MB176.namprd03.prod.outlook.com>
	<5339EF9B.3070606@redhat.com>
	<94b3969cbcd3400d804b4c3dc4332fd7@BY2PR03MB176.namprd03.prod.outlook.com>
Message-ID: <5339F1B0.8030209@redhat.com>

Todd Maugh wrote:
> HBAC rules are set to allow_all enabled

Ok. I'd start with increasing the sssd log level and see what it says.

I gather that basic nss works since you can kinit as other users.

You may want to check for SELinux AVCs as well.

rob

>
> -----Original Message-----
> From: Rob Crittenden [mailto:rcritten at redhat.com]
> Sent: Monday, March 31, 2014 3:44 PM
> To: Todd Maugh; freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate
>
> Todd Maugh wrote:
>> Hi,
>>
>> I have a rhel5 client  I had problems with my IPA environment and had
>> to rebuild
>>
>> I'm on the latest version of IPA with a red hat 6 server
>>
>> I successfully enrolled the client to the new server (same domain,
>> same
>> realm) I had removed all old certs, sysrestores, and ipa/default.conf
>>
>> I can ssh to the box as root, and then either su or kinit to any IPA
>> user with out issue
>>
>> But when I try to ssh as the ipauser to the box it gives me permission
>> denied, please try again
>>
>> I cleared out the sssd cache and restarted sssd
>>
>> Is there something I'm missing or a log to check?
>>
>> I need to worked this out before I move forward enrolling other
>> previously enrolled clients.
>
> Check your HBAC rules.
>
> rob
>



From tmaugh at boingo.com  Mon Mar 31 23:05:18 2014
From: tmaugh at boingo.com (Todd Maugh)
Date: Mon, 31 Mar 2014 23:05:18 +0000
Subject: [Freeipa-users] uninstalled IPA client and reinstalled and
 enrolled to new server cant authenticate
In-Reply-To: <5339F1B0.8030209@redhat.com>
References: <c16c7bc4a4f34705b1c746c775d49541@BY2PR03MB176.namprd03.prod.outlook.com>
	<5339EF9B.3070606@redhat.com>
	<94b3969cbcd3400d804b4c3dc4332fd7@BY2PR03MB176.namprd03.prod.outlook.com>,
	<5339F1B0.8030209@redhat.com>
Message-ID: <95da496c517c455281c0833c200367f0@BY2PR03MB176.namprd03.prod.outlook.com>


[root at black-62 sssd]# tail -f sssd_ops.boingo.com.log
(Mon Mar 31 22:58:01 2014) [sssd[be[ops.boingo.com]]] [be_resolve_server_done] (4): Found address for server idm-master-els.ops.boingo.com: [172.22.170.46] TTL 7200
(Mon Mar 31 22:58:01 2014) [sssd[be[ops.boingo.com]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/black-62.qa.boingo.com
(Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [child_sig_handler] (4): child [13134] finished successfully.
(Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [fo_set_port_status] (4): Marking port 0 of server 'idm-master-els.ops.boingo.com' as 'working'
(Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [set_server_common_status] (4): Marking server 'idm-master-els.ops.boingo.com' as 'working'
(Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [be_run_online_cb] (3): Going online. Running callbacks.
(Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
(Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [delayed_online_authentication_callback] (5): Backend is online, starting delayed online authentication.
(Mon Mar 31 22:59:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6]
(Mon Mar 31 22:59:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
(Mon Mar 31 23:00:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6]
(Mon Mar 31 23:00:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
(Mon Mar 31 23:01:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6]
(Mon Mar 31 23:01:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
(Mon Mar 31 23:02:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6]
(Mon Mar 31 23:02:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
(Mon Mar 31 23:03:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6]
(Mon Mar 31 23:03:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success

I see this in the sssd Logs  but still not authenticating

will check out AVC and SELinux very frustrating


________________________________________
From: Rob Crittenden <rcritten at redhat.com>
Sent: Monday, March 31, 2014 3:52 PM
To: Todd Maugh; freeipa-users at redhat.com
Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate

Todd Maugh wrote:
> HBAC rules are set to allow_all enabled

Ok. I'd start with increasing the sssd log level and see what it says.

I gather that basic nss works since you can kinit as other users.

You may want to check for SELinux AVCs as well.

rob

>
> -----Original Message-----
> From: Rob Crittenden [mailto:rcritten at redhat.com]
> Sent: Monday, March 31, 2014 3:44 PM
> To: Todd Maugh; freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate
>
> Todd Maugh wrote:
>> Hi,
>>
>> I have a rhel5 client  I had problems with my IPA environment and had
>> to rebuild
>>
>> I'm on the latest version of IPA with a red hat 6 server
>>
>> I successfully enrolled the client to the new server (same domain,
>> same
>> realm) I had removed all old certs, sysrestores, and ipa/default.conf
>>
>> I can ssh to the box as root, and then either su or kinit to any IPA
>> user with out issue
>>
>> But when I try to ssh as the ipauser to the box it gives me permission
>> denied, please try again
>>
>> I cleared out the sssd cache and restarted sssd
>>
>> Is there something I'm missing or a log to check?
>>
>> I need to worked this out before I move forward enrolling other
>> previously enrolled clients.
>
> Check your HBAC rules.
>
> rob
>




From dpal at redhat.com  Mon Mar 31 23:07:42 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 31 Mar 2014 19:07:42 -0400
Subject: [Freeipa-users] uninstalled IPA client and reinstalled and
 enrolled to new server cant authenticate
In-Reply-To: <95da496c517c455281c0833c200367f0@BY2PR03MB176.namprd03.prod.outlook.com>
References: <c16c7bc4a4f34705b1c746c775d49541@BY2PR03MB176.namprd03.prod.outlook.com>	<5339EF9B.3070606@redhat.com>	<94b3969cbcd3400d804b4c3dc4332fd7@BY2PR03MB176.namprd03.prod.outlook.com>,
	<5339F1B0.8030209@redhat.com>
	<95da496c517c455281c0833c200367f0@BY2PR03MB176.namprd03.prod.outlook.com>
Message-ID: <5339F53E.4010200@redhat.com>

On 03/31/2014 07:05 PM, Todd Maugh wrote:
> [root at black-62 sssd]# tail -f sssd_ops.boingo.com.log
> (Mon Mar 31 22:58:01 2014) [sssd[be[ops.boingo.com]]] [be_resolve_server_done] (4): Found address for server idm-master-els.ops.boingo.com: [172.22.170.46] TTL 7200
> (Mon Mar 31 22:58:01 2014) [sssd[be[ops.boingo.com]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/black-62.qa.boingo.com
> (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [child_sig_handler] (4): child [13134] finished successfully.
> (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [fo_set_port_status] (4): Marking port 0 of server 'idm-master-els.ops.boingo.com' as 'working'
> (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [set_server_common_status] (4): Marking server 'idm-master-els.ops.boingo.com' as 'working'
> (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [be_run_online_cb] (3): Going online. Running callbacks.
> (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
> (Mon Mar 31 22:58:02 2014) [sssd[be[ops.boingo.com]]] [delayed_online_authentication_callback] (5): Backend is online, starting delayed online authentication.
> (Mon Mar 31 22:59:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6]
> (Mon Mar 31 22:59:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
> (Mon Mar 31 23:00:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6]
> (Mon Mar 31 23:00:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
> (Mon Mar 31 23:01:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6]
> (Mon Mar 31 23:01:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
> (Mon Mar 31 23:02:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6]
> (Mon Mar 31 23:02:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
> (Mon Mar 31 23:03:01 2014) [sssd[be[ops.boingo.com]]] [be_get_account_info] (4): Got request for [4097][1][name=tmp.XXXXUiK3X6]
> (Mon Mar 31 23:03:01 2014) [sssd[be[ops.boingo.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
>
> I see this in the sssd Logs  but still not authenticating
>
> will check out AVC and SELinux very frustrating


Check your SSH configuration. Does it use PAM or it uses GSSAPI?
Check PAM config for SSH.

>
> ________________________________________
> From: Rob Crittenden <rcritten at redhat.com>
> Sent: Monday, March 31, 2014 3:52 PM
> To: Todd Maugh; freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate
>
> Todd Maugh wrote:
>> HBAC rules are set to allow_all enabled
> Ok. I'd start with increasing the sssd log level and see what it says.
>
> I gather that basic nss works since you can kinit as other users.
>
> You may want to check for SELinux AVCs as well.
>
> rob
>
>> -----Original Message-----
>> From: Rob Crittenden [mailto:rcritten at redhat.com]
>> Sent: Monday, March 31, 2014 3:44 PM
>> To: Todd Maugh; freeipa-users at redhat.com
>> Subject: Re: [Freeipa-users] uninstalled IPA client and reinstalled and enrolled to new server cant authenticate
>>
>> Todd Maugh wrote:
>>> Hi,
>>>
>>> I have a rhel5 client  I had problems with my IPA environment and had
>>> to rebuild
>>>
>>> I'm on the latest version of IPA with a red hat 6 server
>>>
>>> I successfully enrolled the client to the new server (same domain,
>>> same
>>> realm) I had removed all old certs, sysrestores, and ipa/default.conf
>>>
>>> I can ssh to the box as root, and then either su or kinit to any IPA
>>> user with out issue
>>>
>>> But when I try to ssh as the ipauser to the box it gives me permission
>>> denied, please try again
>>>
>>> I cleared out the sssd cache and restarted sssd
>>>
>>> Is there something I'm missing or a log to check?
>>>
>>> I need to worked this out before I move forward enrolling other
>>> previously enrolled clients.
>> Check your HBAC rules.
>>
>> rob
>>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.