[Freeipa-users] RHEL5 IPA client for RHEL6.3 IPA server?

[David Summers]

I have looked back through the last year of mail archives for this list 
and haven't yet found anything on this.


I spent a day or so trying to get a RHEL6.3 server set up with several 
clients,


Clients:
RHEL 6.3 32-bit
RHEL 6.3 64-bit
RHEL 5.8 32-bit
RHEL 5.8 64-bit

So far I've been able to get the RHEL 6.3 clients to register and setup 
up as a client for RHEL 6.3 IPA server but whenever I try to install the 
ipa-client on RHEL 5.8 I just get the following error:


[root@rh5 ~]# ipa-client-install
Discovery was successful!
Hostname: rh5.summersoft
Realm: SUMMERSOFT
DNS Domain: summersoft
IPA Server: ipaserver.summersoft
BaseDN: dc=summersoft


Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Unable to sync time with IPA NTP server, assuming the time is in sync.
Password for admin@SUMMERSOFT:

Joining realm failed: SASL Bind failed Local error (-2) !
child exited with 9
Installation failed. Rolling back changes.
IPA client is not configured on this system.

In the install log:

2012-10-16 23:16:34,410 DEBUG stderr=
2012-10-16 23:16:35,032 DEBUG args=/usr/sbin/ipa-join -s 
ipaserver.summersoft -b

 dc=summersoft
2012-10-16 23:16:35,032 DEBUG stdout=
2012-10-16 23:16:35,032 DEBUG stderr=SASL Bind failed Local error (-2) !
child exited with 9


Is RHEL 5.8 a supported client for RHEL 6.3 IPA server?

If so, what am I doing wrong?  I tried following both the RHEL 5.8 and 
RHEL 6.3 install instructions but

nothing I have tried is working so far!

Thanks in advance for any help or pointers you can provide.

   - David Summers

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

Re: [Freeipa-users] RHEL5 IPA client for RHEL6.3 IPA server?

[Rob Crittenden]

David Summers wrote:


I have looked back through the last year of mail archives for this list
and haven't yet found anything on this.

I spent a day or so trying to get a RHEL6.3 server set up with several
clients,

Clients:
RHEL 6.3 32-bit
RHEL 6.3 64-bit
RHEL 5.8 32-bit
RHEL 5.8 64-bit

So far I've been able to get the RHEL 6.3 clients to register and setup
up as a client for RHEL 6.3 IPA server but whenever I try to install the
ipa-client on RHEL 5.8 I just get the following error:

[root@rh5 ~]# ipa-client-install
Discovery was successful!
Hostname: rh5.summersoft
Realm: SUMMERSOFT
DNS Domain: summersoft
IPA Server: ipaserver.summersoft
BaseDN: dc=summersoft


Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Unable to sync time with IPA NTP server, assuming the time is in sync.
Password for admin@SUMMERSOFT:

Joining realm failed: SASL Bind failed Local error (-2) !
child exited with 9
Installation failed. Rolling back changes.
IPA client is not configured on this system.

In the install log:

2012-10-16 23:16:34,410 DEBUG stderr=
2012-10-16 23:16:35,032 DEBUG args=/usr/sbin/ipa-join -s
ipaserver.summersoft -b
  dc=summersoft
2012-10-16 23:16:35,032 DEBUG stdout=
2012-10-16 23:16:35,032 DEBUG stderr=SASL Bind failed Local error (-2) !
child exited with 9


Is RHEL 5.8 a supported client for RHEL 6.3 IPA server?

If so, what am I doing wrong?  I tried following both the RHEL 5.8 and
RHEL 6.3 install instructions but
nothing I have tried is working so far!

Thanks in advance for any help or pointers you can provide.

- David Summers


What is the version of the 5.8 ipa-client package? You want 
ipa-client-2.1.3-2.el5_8


rob

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

Re: [Freeipa-users] web admin tool will not login with kerberos ticket

[Rob Crittenden]

Brian Vetter wrote:

I had a happy, working 2.2 FreeIPA installation humming along last
week. I had to do some maintenance so I shut everything down. When I
brought everything up, I can no longer log into the web admin tool. I
get a "Kerberos ticket is no longer valid" error.

Using the troubleshooting pages on the wiki as a guide, I can kinit
successfully and see the tickets using klist. I can use the ldapsearch
tool using GSSAPI to authenticate as well and can return results from
the ldap server. 'ldapsearch -Y GSSAPI -b "dc=dcc,dc=mobi" uid=admin'
returns a valid ldap recors for my admin user. I ran this command kinit
from multiple kerberos principals/users and each worked.

I verified my config settings again with firefox and they are still set
correctly (auth.delegation-uris, auth.trusted-users both set to my
domain .dcc.mobi). The cert was accepted (no warnings about the cert not
being trusted because I had already set it to trusted). I turned on the
NSPR logging as described in the documents, and didn't see an error,
although I can't tell if this is correct:

492291904[7f4d1d31f6a0]:   using REQ_DELEGATE
492291904[7f4d1d31f6a0]:   service = geonosis.dcc.mobi
492291904[7f4d1d31f6a0]:   using negotiate-gss
492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::nsAuthGSSAPI()
492291904[7f4d1d31f6a0]: Attempting to load gss functions
492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::Init()
492291904[7f4d1d31f6a0]: nsHttpNegotiateAuth::GenerateCredentials()
[challenge=Negotiate]
492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::GetNextToken()
492291904[7f4d1d31f6a0]:   leaving nsAuthGSSAPI::GetNextToken [rv=0]
492291904[7f4d1d31f6a0]:   Sending a token of length 1394


There is nothing in /var/log/httpd/error_log. /var/log/httpd/access_log
does have a few entries:

10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ca/ocsp HTTP/1.1"
200 2298 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:16.0)
Gecko/20100101 Firefox/16.0"
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ipa/session/json
HTTP/1.1" 401 -
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "GET
/ipa/session/login_kerberos HTTP/1.1" 401 1861
10.1.1.10 - ad...@dcc.mobi 
[16/Oct/2012:18:05:26 -0500] "GET /ipa/session/login_kerberos
HTTP/1.1" 200 -
10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ipa/session/json
HTTP/1.1" 401 -


The 401's aren't surprising here since somehow, something is not
properly authenticating.

I also looked in /var/log/krb5kdc.log and see the following line when
authenticating:

Oct 16 18:12:17 geonosis.dcc.mobi krb5kdc[1193](info): TGS_REQ (1
etypes {18}) 10.1.1.10: ISSUE: authtime 1350424404, etypes {rep=18
tkt=18 ses=18}, ad...@dcc.mobi  for
krbtgt/dcc.m...@dcc.mobi 


I don't believe this describes an error, but I'm not an expert reading
that log type.

 From what I can tell, the problems seem to be between the apache server
and the browser. Both worked fine together last week. Is there something
I can turn on in Apache (perhaps in the ipa.conf or auth_kerb.conf
files) that can help debug this? Or better yet, anyone else seen this
and have an answer? Is there some key/ticket/etc associated with the
http server that might be "wrong" now (somehow whacked during the reboot)?


If you set LogLevel debug in /etc/httpd/conf.d/nss.conf and restart the 
httpd service you'll get a lot of debugging output from ipa and 
mod_auth_kerb, one of which may provide some pointers.


rob

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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Macklin, Jason]

Okay,

  Rule name: test4
  Enabled: TRUE
  Command category: all
  Users: asteinfeld
  Hosts: dbduwdu062.dbr.roche.com
  Host Groups: tempsudo

Client dbduwdu062 is matched in the rule by both the hosts and groups entry.

/etc/nsswitch.conf has:

Netgroups: files sss

Getent netgroup tempsudo returns:

[jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo
tempsudo  (dbduwdu063.dbr.roche.com, -, dbr.roche.com) 
(dbduwdu062.dbr.roche.com, -, dbr.roche.com)

To the previous ldapsearch request:

[jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H 
ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
additional info: Entry permanently locked.

I am still scratching my head on this one...

Cheers,
Jason

If you look closely, the reason that your admin works is because it appears to 
be matching a sudo rule who has the "ALL" hosts value set.

When you run the non working user, it is attempting to match the 
hostname/hostgroup to the rule and fails to do so.

Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes 
there.

^ that command should return all of the hosts in your hostgroup. If it does 
not, then check /etc/nsswitch.conf and make sure that netgroup is set to use 
sss.

You will also need to make sure that the output of: domainname or nisdomainname 
matches your expected domain.

Let me know how things look after trying that.


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

Re: [Freeipa-users] Setting up sudo in FreeIPA v2.2

[Toasted Penguin]

On Tue, Oct 16, 2012 at 10:50 PM, JR Aquino  wrote:

> On the host in question Run the command: domainname
>
> That wants to match whatever your domain is. If it doesn't it will fail
> even if you have all the server rules configured correctly. This is a sudo
> + netgroups/hostgroups 'feature'
>
> ~
> Jr Aquino | Sr. Information Security Specialist
> GIAC Certified Incident Handler | GIAC WebApp Penetration Tester
> Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117
> T:  +1 805.690.3478
> C: +1 805.717.0365
> jr.aqu...@citrixonline.com
> http://www.citrixonline.com
>
> On Oct 16, 2012, at 2:26 PM, "Toasted Penguin" <
> toastedpenguini...@gmail.com> wrote:
>
> > I have the server setup to manage sudo and I configured a target client
> to use the IPA server for sudo.  When a user tries to use sudo (in this
> case "sudo su -") it fails and they get the error "user is not allowed to
> run sudo on client-host.  This incident will be reported." I verified via
> the log files that the client is making requests to the IPA server when the
> user is attemping to use sudo and it fails.  I temporarily disabled using
> the IPA server for sudo and I get the standard "User not in the sudoers
> file"
> >
> > Its starting to look like the server rules maybe the issue but I believe
> I have the sudo rule setup correctly.  I created a sudo command "/bin/su",
> created a sudo rule "Sudo to root" , added the group the user in question
> is a part of to the WHO-->User Groups; Added the Host Group the target
> client host is part of to Access This Host-->Host Groups and added the sudo
> command to the sudo rule via Allow-->Sudo Allow Commands.  When I delete
> the sudo rule I get the same result as I did when I temporarily disbled the
> client host using tghe IPA server for sudo verification.
> >
> > Any ideas why or where to look to figure out this issue?
> >
> > Thanks,
> > David
> > ___
> > Freeipa-users mailing list
> > Freeipa-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
>
Executing domainname results in the correct domain for theFreeIPA service.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Rich Megginson]

On 10/17/2012 07:26 AM, Macklin, Jason wrote:

Okay,

   Rule name: test4
   Enabled: TRUE
   Command category: all
   Users: asteinfeld
   Hosts: dbduwdu062.dbr.roche.com
   Host Groups: tempsudo

Client dbduwdu062 is matched in the rule by both the hosts and groups entry.

/etc/nsswitch.conf has:

Netgroups: files sss

Getent netgroup tempsudo returns:

[jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo
tempsudo  (dbduwdu063.dbr.roche.com, -, dbr.roche.com) 
(dbduwdu062.dbr.roche.com, -, dbr.roche.com)

To the previous ldapsearch request:

[jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H 
ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
additional info: Entry permanently locked.

I am still scratching my head on this one...


This means you cannot search using your kerberos ticket because the 
corresponding entry is locked.  Try using directory manager:


ldapsearch -x -D "cn=directory manager" -W -H 
ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"





Cheers,
Jason

If you look closely, the reason that your admin works is because it appears to be 
matching a sudo rule who has the "ALL" hosts value set.

When you run the non working user, it is attempting to match the 
hostname/hostgroup to the rule and fails to do so.

Try this. Type: getent netgroup hostgroupname<- your host's hostgroup goes 
there.

^ that command should return all of the hosts in your hostgroup. If it does 
not, then check /etc/nsswitch.conf and make sure that netgroup is set to use 
sss.

You will also need to make sure that the output of: domainname or nisdomainname 
matches your expected domain.

Let me know how things look after trying that.


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


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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Dmitri Pal]

On 10/17/2012 09:26 AM, Macklin, Jason wrote:
> Okay,
>
>   Rule name: test4
>   Enabled: TRUE
>   Command category: all
>   Users: asteinfeld
>   Hosts: dbduwdu062.dbr.roche.com
>   Host Groups: tempsudo
>
> Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
>
> /etc/nsswitch.conf has:
>
>   Netgroups: files sss
>
> Getent netgroup tempsudo returns:
>
>   [jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo
>   tempsudo  (dbduwdu063.dbr.roche.com, -, dbr.roche.com) 
> (dbduwdu062.dbr.roche.com, -, dbr.roche.com)
>
> To the previous ldapsearch request:
>
>   [jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H 
> ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
>   SASL/GSSAPI authentication started
>   ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
>   additional info: Entry permanently locked.

It seems that you tried the wrong password and the account is now
temporarily locked thus the server is unwilling to perform
authentication for this account.

>
> I am still scratching my head on this one...
>
> Cheers,
> Jason
>
> If you look closely, the reason that your admin works is because it appears 
> to be matching a sudo rule who has the "ALL" hosts value set.
>
> When you run the non working user, it is attempting to match the 
> hostname/hostgroup to the rule and fails to do so.
>
> Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes 
> there.
>
> ^ that command should return all of the hosts in your hostgroup. If it does 
> not, then check /etc/nsswitch.conf and make sure that netgroup is set to use 
> sss.
>
> You will also need to make sure that the output of: domainname or 
> nisdomainname matches your expected domain.
>
> Let me know how things look after trying that.
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Macklin, Jason]

ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com 
"ou=SUDOers,dc=dbr,dc=roche,dc=com"
SASL/GSSAPI authentication started
SASL username: ad...@dbr.roche.com
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: ou=SUDOers,dc=dbr,dc=roche,dc=com
# requesting: ALL
#

# search result
search: 4
result: 32 No such object

# numResponses: 1

Different response, but still no success with the non-working account.

Cheers,
Jason

-Original Message-
From: Dmitri Pal [mailto:d...@redhat.com] 
Sent: Wednesday, October 17, 2012 11:56 AM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
command or host level.

On 10/17/2012 09:26 AM, Macklin, Jason wrote:
> Okay,
>
>   Rule name: test4
>   Enabled: TRUE
>   Command category: all
>   Users: asteinfeld
>   Hosts: dbduwdu062.dbr.roche.com
>   Host Groups: tempsudo
>
> Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
>
> /etc/nsswitch.conf has:
>
>   Netgroups: files sss
>
> Getent netgroup tempsudo returns:
>
>   [jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo
>   tempsudo  (dbduwdu063.dbr.roche.com, -, dbr.roche.com) 
> (dbduwdu062.dbr.roche.com, -, dbr.roche.com)
>
> To the previous ldapsearch request:
>
>   [jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H 
> ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
>   SASL/GSSAPI authentication started
>   ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
>   additional info: Entry permanently locked.

It seems that you tried the wrong password and the account is now temporarily 
locked thus the server is unwilling to perform authentication for this account.

>
> I am still scratching my head on this one...
>
> Cheers,
> Jason
>
> If you look closely, the reason that your admin works is because it appears 
> to be matching a sudo rule who has the "ALL" hosts value set.
>
> When you run the non working user, it is attempting to match the 
> hostname/hostgroup to the rule and fails to do so.
>
> Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes 
> there.
>
> ^ that command should return all of the hosts in your hostgroup. If it does 
> not, then check /etc/nsswitch.conf and make sure that netgroup is set to use 
> sss.
>
> You will also need to make sure that the output of: domainname or 
> nisdomainname matches your expected domain.
>
> Let me know how things look after trying that.
>


--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio Red Hat Inc.


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




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

[Freeipa-users] Failed installation

[Bret Wortman]

I recently tried installing freeipa on a new server, but ipa-server-install
had problems around this point:

Configuring certificate server: Estimated time 3 minutes 30 seconds
  [1/18]: creating certificate server user
  [2/18]: creating pki-ca instance
  [3/18]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
fs1.wedgeofli.me-cs_port 9445 -client_certdb_dir /tmp/tmp-UvBMbL
-client_certdb_pwd
 -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin
-admin_email root@localhost -admin_  -agent_name
ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject
CN=ipa-ca-agent,O=WEDGEOFLI.ME -ldap_host fs1.wedgeofli.me -ldap_port 7389
-bind_dn cn=Directory Manager -bind_  -base_dn o=ipaca
-db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA
-save_p12 true -backup_pwd  -subsystem_name pki-cad -token_name
internal -ca_subsystem_cert_subject_name CN=CA
Subsystem,O=WEDGEOFLI.ME-ca_ocsp_cert_subject_name CN=OCSP
Subsystem,O=
WEDGEOFLI.ME -ca_server_cert_subject_name
CN=fs1.wedgeofli.me,O=WEDGEOFLI.ME-ca_audit_signing_cert_subject_name
CN=CA Audit,O=
WEDGEOFLI.ME -ca_sign_cert_subject_name CN=Certificate Authority,O=
WEDGEOFLI.ME -external false -clone false' returned non-zero exit status 255
Unexpected error - see ipaserver-install.log for details:
 Configuration of CA failed
[root@fs1 ~]#

The logfile revealed the following stack trace:

#
Attempting to connect to: fs1.wedgeofli.me:9445
Exception in LoginPanel(): java.lang.NullPointerException
ERROR: ConfigureCA: LoginPanel() failure
ERROR: unable to create CA

###

2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send
Request:java.net.ConnectException: Connection refused
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at java.net.Socket.(Socket.java:425)
at java.net.Socket.(Socket.java:241)
at HTTPClient.sslConnect(HTTPClient.java:326)
at ConfigureCA.LoginPanel(ConfigureCA.java:244)
at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157)
at ConfigureCA.main(ConfigureCA.java:1672)
java.lang.NullPointerException
at ConfigureCA.LoginPanel(ConfigureCA.java:245)
at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157)
at ConfigureCA.main(ConfigureCA.java:1672)

Now I seem to be stuck. I tried uninstalling the freeipa-server package
with # yum remove freeipa-server and then reinstalled it the same way, but
ipa-server-install won't run no matter what I attempt.

Any thoughts? I'm pretty new to IPA.

Thanks!


-- 
Bret Wortman
The Damascus Group
Fairfax, VA
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Simo Sorce]

On Wed, 2012-10-17 at 09:53 -0600, Rich Megginson wrote:
> On 10/17/2012 07:26 AM, Macklin, Jason wrote:
> > Okay,
> >
> >Rule name: test4
> >Enabled: TRUE
> >Command category: all
> >Users: asteinfeld
> >Hosts: dbduwdu062.dbr.roche.com
> >Host Groups: tempsudo
> >
> > Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
> >
> > /etc/nsswitch.conf has:
> >
> > Netgroups: files sss
> >
> > Getent netgroup tempsudo returns:
> >
> > [jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo
> > tempsudo  (dbduwdu063.dbr.roche.com, -, dbr.roche.com) 
> > (dbduwdu062.dbr.roche.com, -, dbr.roche.com)
> >
> > To the previous ldapsearch request:
> >
> > [jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H 
> > ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> > SASL/GSSAPI authentication started
> > ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
> > additional info: Entry permanently locked.
> >
> > I am still scratching my head on this one...
> 
> This means you cannot search using your kerberos ticket because the 
> corresponding entry is locked.  Try using directory manager:
> 
> ldapsearch -x -D "cn=directory manager" -W -H 
> ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> 

This sounds very wrong.

If the user had a kerberos ticket in the first place it meant it
successfully authenticated.

If no krb ticket was available GSSAPI would have not started at all.

This look like some odd error in directory server failing to recognize
valid users ?

Simo.

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

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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Rich Megginson]

On 10/17/2012 10:46 AM, Simo Sorce wrote:

On Wed, 2012-10-17 at 09:53 -0600, Rich Megginson wrote:

On 10/17/2012 07:26 AM, Macklin, Jason wrote:

Okay,

Rule name: test4
Enabled: TRUE
Command category: all
Users: asteinfeld
Hosts: dbduwdu062.dbr.roche.com
Host Groups: tempsudo

Client dbduwdu062 is matched in the rule by both the hosts and groups entry.

/etc/nsswitch.conf has:

Netgroups: files sss

Getent netgroup tempsudo returns:

[jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo
tempsudo  (dbduwdu063.dbr.roche.com, -, dbr.roche.com) 
(dbduwdu062.dbr.roche.com, -, dbr.roche.com)

To the previous ldapsearch request:

[jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H 
ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
additional info: Entry permanently locked.

I am still scratching my head on this one...

This means you cannot search using your kerberos ticket because the
corresponding entry is locked.  Try using directory manager:

ldapsearch -x -D "cn=directory manager" -W -H
ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"


This sounds very wrong.

If the user had a kerberos ticket in the first place it meant it
successfully authenticated.

If no krb ticket was available GSSAPI would have not started at all.

This look like some odd error in directory server failing to recognize
valid users ?

Not sure what's going on.  Looking at the code in ipa_lockout.c:
lockout_duration = slapi_entry_attr_get_uint(policy_entry, 
"krbPwdLockoutDuration");

if (lockout_duration == 0) {
errstr = "Entry permanently locked.\n";
ret = LDAP_UNWILLING_TO_PERFORM;
goto done;
}

This means either krbPwdLockoutDuration does not exist at all, or does 
exist and has a value of 0.


Can you do an ldapsearch of your entry like this:

ldapsearch -xLLL -D "cn=directory manager" -W uid=youruserid \* 
krbPwdLockoutDuration

?


Simo.



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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Dmitri Pal]

On 10/17/2012 12:33 PM, Macklin, Jason wrote:
> ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com 
> "ou=SUDOers,dc=dbr,dc=roche,dc=com"

You are missing -b

ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b
"ou=SUDOers,dc=dbr,dc=roche,dc=com"
Currently the command treats it as filter and thus returns no results.

I am asking you to run this command to see what LDAP data the server
presents to the client.
Running this would not cure the problem but rather might give more hints
of what the actual problem is.
> SASL/GSSAPI authentication started
> SASL username: ad...@dbr.roche.com
> SASL SSF: 56
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base <> (default) with scope subtree
> # filter: ou=SUDOers,dc=dbr,dc=roche,dc=com
> # requesting: ALL
> #
>
> # search result
> search: 4
> result: 32 No such object
>
> # numResponses: 1
>
> Different response, but still no success with the non-working account.
>
> Cheers,
> Jason
>
> -Original Message-
> From: Dmitri Pal [mailto:d...@redhat.com] 
> Sent: Wednesday, October 17, 2012 11:56 AM
> To: Macklin, Jason {DASB~Branford}
> Cc: jr.aqu...@citrix.com; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
> command or host level.
>
> On 10/17/2012 09:26 AM, Macklin, Jason wrote:
>> Okay,
>>
>>   Rule name: test4
>>   Enabled: TRUE
>>   Command category: all
>>   Users: asteinfeld
>>   Hosts: dbduwdu062.dbr.roche.com
>>   Host Groups: tempsudo
>>
>> Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
>>
>> /etc/nsswitch.conf has:
>>
>>  Netgroups: files sss
>>
>> Getent netgroup tempsudo returns:
>>
>>  [jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo
>>  tempsudo  (dbduwdu063.dbr.roche.com, -, dbr.roche.com) 
>> (dbduwdu062.dbr.roche.com, -, dbr.roche.com)
>>
>> To the previous ldapsearch request:
>>
>>  [jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H 
>> ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
>>  SASL/GSSAPI authentication started
>>  ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
>>  additional info: Entry permanently locked.
> It seems that you tried the wrong password and the account is now temporarily 
> locked thus the server is unwilling to perform authentication for this 
> account.
>
>> I am still scratching my head on this one...
>>
>> Cheers,
>> Jason
>>
>> If you look closely, the reason that your admin works is because it appears 
>> to be matching a sudo rule who has the "ALL" hosts value set.
>>
>> When you run the non working user, it is attempting to match the 
>> hostname/hostgroup to the rule and fails to do so.
>>
>> Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes 
>> there.
>>
>> ^ that command should return all of the hosts in your hostgroup. If it does 
>> not, then check /etc/nsswitch.conf and make sure that netgroup is set to use 
>> sss.
>>
>> You will also need to make sure that the output of: domainname or 
>> nisdomainname matches your expected domain.
>>
>> Let me know how things look after trying that.
>>
>
> --
> 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/



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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Rich Megginson]

On 10/17/2012 10:33 AM, Macklin, Jason wrote:

ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com 
"ou=SUDOers,dc=dbr,dc=roche,dc=com"
SASL/GSSAPI authentication started
SASL username: ad...@dbr.roche.com
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base<>  (default) with scope subtree
# filter: ou=SUDOers,dc=dbr,dc=roche,dc=com
# requesting: ALL
#

# search result
search: 4
result: 32 No such object

# numResponses: 1

Different response, but still no success with the non-working account.


Sorry - the ldapsearch command is wrong.  Try this:
ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b 
"ou=SUDOers,dc=dbr,dc=roche,dc=com"




Cheers,
Jason

-Original Message-
From: Dmitri Pal [mailto:d...@redhat.com]
Sent: Wednesday, October 17, 2012 11:56 AM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
command or host level.

On 10/17/2012 09:26 AM, Macklin, Jason wrote:

Okay,

   Rule name: test4
   Enabled: TRUE
   Command category: all
   Users: asteinfeld
   Hosts: dbduwdu062.dbr.roche.com
   Host Groups: tempsudo

Client dbduwdu062 is matched in the rule by both the hosts and groups entry.

/etc/nsswitch.conf has:

Netgroups: files sss

Getent netgroup tempsudo returns:

[jmacklin@dbduwdu062 Desktop]$ getent netgroup tempsudo
tempsudo  (dbduwdu063.dbr.roche.com, -, dbr.roche.com) 
(dbduwdu062.dbr.roche.com, -, dbr.roche.com)

To the previous ldapsearch request:

[jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H 
ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
additional info: Entry permanently locked.

It seems that you tried the wrong password and the account is now temporarily 
locked thus the server is unwilling to perform authentication for this account.


I am still scratching my head on this one...

Cheers,
Jason

If you look closely, the reason that your admin works is because it appears to be 
matching a sudo rule who has the "ALL" hosts value set.

When you run the non working user, it is attempting to match the 
hostname/hostgroup to the rule and fails to do so.

Try this. Type: getent netgroup hostgroupname<- your host's hostgroup goes 
there.

^ that command should return all of the hosts in your hostgroup. If it does 
not, then check /etc/nsswitch.conf and make sure that netgroup is set to use 
sss.

You will also need to make sure that the output of: domainname or nisdomainname 
matches your expected domain.

Let me know how things look after trying that.



--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio Red Hat Inc.


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




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


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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Macklin, Jason]

Thanks guys!  Adding the "-b" did make a world of difference though it still 
doesn't make anything too obvious... at least to me.

[jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H 
ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com"
SASL/GSSAPI authentication started
SASL username: ad...@dbr.roche.com
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# sudoers, dbr.roche.com
dn: ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: extensibleObject
ou: sudoers

# test4, sudoers, dbr.roche.com
dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: asteinfeld
sudoHost: dbduwdu062.dbr.roche.com
sudoHost: +tempsudo
sudoCommand: ALL
cn: test4

# switch, sudoers, dbr.roche.com
dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: oyilmaz
sudoHost: dbdusdu071.dbr.roche.com
sudoCommand: /bin/su
cn: switch

# jing144, sudoers, dbr.roche.com
dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: jli
sudoHost: dbduvdu144.dbr.roche.com
sudoCommand: ALL
cn: jing144

# Admin, sudoers, dbr.roche.com
dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com
objectClass: sudoRole
sudoUser: jmacklin
sudoUser: mrini
sudoUser: cgajare
sudoUser: parnold
sudoUser: hhebert
sudoUser: ckuecherer
sudoUser: gferreri
sudoHost: ALL
sudoCommand: ALL
cn: Admin

# search result
search: 4
result: 0 Success

# numResponses: 6
# numEntries: 5

I really appreciate all of the help!

Cheers,
Jason


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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Macklin, Jason]

None of my users have an LDAP password being requested by running that command 
(except the admin user).

Does each user account require an ldap account to go along with their login 
account?  I just get the following over and over no matter which account I 
switch in the command...

[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=admin \* krbPwdLockoutDuration ?
Enter LDAP Password: 
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password: 
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password: 
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Rich Megginson]

On 10/17/2012 11:13 AM, Macklin, Jason wrote:

None of my users have an LDAP password being requested by running that command 
(except the admin user).

Does each user account require an ldap account to go along with their login 
account?  I just get the following over and over no matter which account I 
switch in the command...

[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=admin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
You have to specify which server to talk to using the -H 
ldap://fqdn.of.host option.


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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Macklin, Jason]

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" 
-W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password: 
ldap_bind: Invalid credentials (49)

I know this user password because I reset it for the purpose of troubleshooting 
this issue with that account. I also get the same response when I use the admin 
account of my own account.

-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com] 
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: s...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
command or host level.

On 10/17/2012 11:13 AM, Macklin, Jason wrote:
> None of my users have an LDAP password being requested by running that 
> command (except the admin user).
>
> Does each user account require an ldap account to go along with their login 
> account?  I just get the following over and over no matter which account I 
> switch in the command...
>
> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
> uid=admin \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
> uid=asteinfeld \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
> uid=jmacklin \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
You have to specify which server to talk to using the -H ldap://fqdn.of.host 
option.

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

Re: [Freeipa-users] RHEL5 IPA client for RHEL6.3 IPA server?

[Rob Crittenden]

David Summers wrote:

On 10/17/2012 7:49 AM, Rob Crittenden wrote:

David Summers wrote:


I have looked back through the last year of mail archives for this list
and haven't yet found anything on this.

I spent a day or so trying to get a RHEL6.3 server set up with several
clients,

Clients:
RHEL 6.3 32-bit
RHEL 6.3 64-bit
RHEL 5.8 32-bit
RHEL 5.8 64-bit

So far I've been able to get the RHEL 6.3 clients to register and setup
up as a client for RHEL 6.3 IPA server but whenever I try to install the
ipa-client on RHEL 5.8 I just get the following error:

[root@rh5 ~]# ipa-client-install
Discovery was successful!
Hostname: rh5.summersoft
Realm: SUMMERSOFT
DNS Domain: summersoft
IPA Server: ipaserver.summersoft
BaseDN: dc=summersoft


Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Unable to sync time with IPA NTP server, assuming the time is in sync.
Password for admin@SUMMERSOFT:

Joining realm failed: SASL Bind failed Local error (-2) !
child exited with 9
Installation failed. Rolling back changes.
IPA client is not configured on this system.

In the install log:

2012-10-16 23:16:34,410 DEBUG stderr=
2012-10-16 23:16:35,032 DEBUG args=/usr/sbin/ipa-join -s
ipaserver.summersoft -b
  dc=summersoft
2012-10-16 23:16:35,032 DEBUG stdout=
2012-10-16 23:16:35,032 DEBUG stderr=SASL Bind failed Local error (-2) !
child exited with 9


Is RHEL 5.8 a supported client for RHEL 6.3 IPA server?

If so, what am I doing wrong?  I tried following both the RHEL 5.8 and
RHEL 6.3 install instructions but
nothing I have tried is working so far!

Thanks in advance for any help or pointers you can provide.

- David Summers


What is the version of the 5.8 ipa-client package? You want
ipa-client-2.1.3-2.el5_8

rob



Yes, I have ipa-client-2.1.3-2.el5_8 but I have not been able to get it
to join the IPA server.
I've turned off all firewalls.

I am running IPv6, does that make a difference?

Any ideas?

- Thanks
- David Summers


It is failing trying to get a keytab for the newly enrolled host.

Can you provide /var/log/ipaclient-install.log?

Can you look in the 389-ds error and access logs for the BIND request 
and/or other errors when the client enrollment happens 
(/var/log/dirsrv/slapd-REALM, access buffers for 30 seconds) and the KDC 
logs in /var/log/krb5kdc?


rob

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

Re: [Freeipa-users] RHEL5 IPA client for RHEL6.3 IPA server?

[David Summers]

On 10/17/2012 7:49 AM, Rob Crittenden wrote:

David Summers wrote:


I have looked back through the last year of mail archives for this list
and haven't yet found anything on this.

I spent a day or so trying to get a RHEL6.3 server set up with several
clients,

Clients:
RHEL 6.3 32-bit
RHEL 6.3 64-bit
RHEL 5.8 32-bit
RHEL 5.8 64-bit

So far I've been able to get the RHEL 6.3 clients to register and setup
up as a client for RHEL 6.3 IPA server but whenever I try to install the
ipa-client on RHEL 5.8 I just get the following error:

[root@rh5 ~]# ipa-client-install
Discovery was successful!
Hostname: rh5.summersoft
Realm: SUMMERSOFT
DNS Domain: summersoft
IPA Server: ipaserver.summersoft
BaseDN: dc=summersoft


Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Unable to sync time with IPA NTP server, assuming the time is in sync.
Password for admin@SUMMERSOFT:

Joining realm failed: SASL Bind failed Local error (-2) !
child exited with 9
Installation failed. Rolling back changes.
IPA client is not configured on this system.

In the install log:

2012-10-16 23:16:34,410 DEBUG stderr=
2012-10-16 23:16:35,032 DEBUG args=/usr/sbin/ipa-join -s
ipaserver.summersoft -b
  dc=summersoft
2012-10-16 23:16:35,032 DEBUG stdout=
2012-10-16 23:16:35,032 DEBUG stderr=SASL Bind failed Local error (-2) !
child exited with 9


Is RHEL 5.8 a supported client for RHEL 6.3 IPA server?

If so, what am I doing wrong?  I tried following both the RHEL 5.8 and
RHEL 6.3 install instructions but
nothing I have tried is working so far!

Thanks in advance for any help or pointers you can provide.

- David Summers


What is the version of the 5.8 ipa-client package? You want 
ipa-client-2.1.3-2.el5_8


rob



Yes, I have ipa-client-2.1.3-2.el5_8 but I have not been able to get it 
to join the IPA server.

I've turned off all firewalls.

I am running IPv6, does that make a difference?

Any ideas?

   - Thanks
   - David Summers

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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Rob Crittenden]

Macklin, Jason wrote:

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" 
-W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

I know this user password because I reset it for the purpose of troubleshooting 
this issue with that account. I also get the same response when I use the admin 
account of my own account.


You use the password of the user you are binding as, in this case the 
directory manager.


rob



-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: s...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
command or host level.

On 10/17/2012 11:13 AM, Macklin, Jason wrote:

None of my users have an LDAP password being requested by running that command 
(except the admin user).

Does each user account require an ldap account to go along with their login 
account?  I just get the following over and over no matter which account I 
switch in the command...

[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=admin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

You have to specify which server to talk to using the -H ldap://fqdn.of.host 
option.

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



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

Re: [Freeipa-users] Failed installation

[Dmitri Pal]

On 10/17/2012 12:40 PM, Bret Wortman wrote:
> I recently tried installing freeipa on a new server, but
> ipa-server-install had problems around this point:
>
> Configuring certificate server: Estimated time 3 minutes 30 seconds
>   [1/18]: creating certificate server user
>   [2/18]: creating pki-ca instance
>   [3/18]: configuring certificate server instance
> ipa : CRITICAL failed to configure ca instance Command
> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
> fs1.wedgeofli.me  -cs_port 9445
> -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd 
> -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin
> -admin_email root@localhost -admin_  -agent_name
> ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa
> -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME
>  -ldap_host fs1.wedgeofli.me
>  -ldap_port 7389 -bind_dn cn=Directory
> Manager -bind_  -base_dn o=ipaca -db_name ipaca
> -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12
> true -backup_pwd  -subsystem_name pki-cad -token_name internal
> -ca_subsystem_cert_subject_name CN=CA Subsystem,O=WEDGEOFLI.ME
>  -ca_ocsp_cert_subject_name CN=OCSP
> Subsystem,O=WEDGEOFLI.ME 
> -ca_server_cert_subject_name CN=fs1.wedgeofli.me
> ,O=WEDGEOFLI.ME 
> -ca_audit_signing_cert_subject_name CN=CA Audit,O=WEDGEOFLI.ME
>  -ca_sign_cert_subject_name CN=Certificate
> Authority,O=WEDGEOFLI.ME  -external false -clone
> false' returned non-zero exit status 255
> Unexpected error - see ipaserver-install.log for details:
>  Configuration of CA failed
> [root@fs1 ~]# 
>
> The logfile revealed the following stack trace:
>
> #
> Attempting to connect to: fs1.wedgeofli.me:9445
> 
> Exception in LoginPanel(): java.lang.NullPointerException
> ERROR: ConfigureCA: LoginPanel() failure
> ERROR: unable to create CA
>
> ###
>
> 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send
> Request:java.net.ConnectException: Connection refused
> java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
> at java.net.Socket.connect(Socket.java:579)
> at java.net.Socket.connect(Socket.java:528)
> at java.net.Socket.(Socket.java:425)
> at java.net.Socket.(Socket.java:241)
> at HTTPClient.sslConnect(HTTPClient.java:326)
> at ConfigureCA.LoginPanel(ConfigureCA.java:244)
> at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157)
> at ConfigureCA.main(ConfigureCA.java:1672)
> java.lang.NullPointerException
> at ConfigureCA.LoginPanel(ConfigureCA.java:245)
> at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157)
> at ConfigureCA.main(ConfigureCA.java:1672)
>
> Now I seem to be stuck. I tried uninstalling the freeipa-server
> package with # yum remove freeipa-server and then reinstalled it the
> same way, but ipa-server-install won't run no matter what I attempt.
>
> Any thoughts? I'm pretty new to IPA.
>

Make sure you have packages installed
Run the uninstall command several times (5 for example)

 ipa-server-install --uninstall -U

In case of failed installation and other steps you made the installtion might 
be in the corrupted state.
Running severl times might help as it might detect and remove/unconfigure 
different things at different moments.

Before trying to reinstall again make sure you have latest SELinux policies.

If it explodes again let us know.
 



> Thanks!
>
>
> -- 
> Bret Wortman
> The Damascus Group
> Fairfax, VA
>
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



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

Re: [Freeipa-users] Failed installation

[John Dennis]

On 10/17/2012 12:40 PM, Bret Wortman wrote:

I recently tried installing freeipa on a new server, but
ipa-server-install had problems around this point:

Configuring certificate server: Estimated time 3 minutes 30 seconds
   [1/18]: creating certificate server user
   [2/18]: creating pki-ca instance
   [3/18]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
fs1.wedgeofli.me  -cs_port 9445
-client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd 
-preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin
-admin_email root@localhost -admin_  -agent_name
ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa
-agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME 
-ldap_host fs1.wedgeofli.me  -ldap_port 7389
-bind_dn cn=Directory Manager -bind_  -base_dn o=ipaca
-db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA
-save_p12 true -backup_pwd  -subsystem_name pki-cad -token_name
internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=WEDGEOFLI.ME
 -ca_ocsp_cert_subject_name CN=OCSP
Subsystem,O=WEDGEOFLI.ME 
-ca_server_cert_subject_name CN=fs1.wedgeofli.me
,O=WEDGEOFLI.ME 
-ca_audit_signing_cert_subject_name CN=CA Audit,O=WEDGEOFLI.ME
 -ca_sign_cert_subject_name CN=Certificate
Authority,O=WEDGEOFLI.ME  -external false -clone
false' returned non-zero exit status 255
Unexpected error - see ipaserver-install.log for details:
  Configuration of CA failed
[root@fs1 ~]#

The logfile revealed the following stack trace:

#
Attempting to connect to: fs1.wedgeofli.me:9445

Exception in LoginPanel(): java.lang.NullPointerException
ERROR: ConfigureCA: LoginPanel() failure
ERROR: unable to create CA

###

2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send
Request:java.net.ConnectException: Connection refused
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at java.net.Socket.(Socket.java:425)
at java.net.Socket.(Socket.java:241)
at HTTPClient.sslConnect(HTTPClient.java:326)
at ConfigureCA.LoginPanel(ConfigureCA.java:244)
at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157)
at ConfigureCA.main(ConfigureCA.java:1672)
java.lang.NullPointerException
at ConfigureCA.LoginPanel(ConfigureCA.java:245)
at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157)
at ConfigureCA.main(ConfigureCA.java:1672)

Now I seem to be stuck. I tried uninstalling the freeipa-server package
with # yum remove freeipa-server and then reinstalled it the same way,
but ipa-server-install won't run no matter what I attempt.

Any thoughts? I'm pretty new to IPA.


There is a good chance this is due to a version mismatch between the IPA 
packages and the dogtag packages. You didn't mention which OS you're 
using nor the versions of the relevant packages, that would have been 
helpful. In any event I would make sure all your packages are up to date.



--
John Dennis 

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

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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Macklin, Jason]

I assume that this iteration was with the correct credentials as it responds 
with something other then "Invalid Credentials"

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" 
-W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password: 
No such object (32)

Working account returns same thing...

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" 
-W uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password: 
No such object (32)

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Wednesday, October 17, 2012 1:37 PM
To: Macklin, Jason {DASB~Branford}
Cc: rmegg...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
command or host level.

Macklin, Jason wrote:
> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" 
> -W uid=asteinfeld \* krbPwdLockoutDuration ?
> Enter LDAP Password:
> ldap_bind: Invalid credentials (49)
>
> I know this user password because I reset it for the purpose of 
> troubleshooting this issue with that account. I also get the same response 
> when I use the admin account of my own account.

You use the password of the user you are binding as, in this case the directory 
manager.

rob

>
> -Original Message-
> From: Rich Megginson [mailto:rmegg...@redhat.com]
> Sent: Wednesday, October 17, 2012 1:15 PM
> To: Macklin, Jason {DASB~Branford}
> Cc: s...@redhat.com; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
> command or host level.
>
> On 10/17/2012 11:13 AM, Macklin, Jason wrote:
>> None of my users have an LDAP password being requested by running that 
>> command (except the admin user).
>>
>> Does each user account require an ldap account to go along with their login 
>> account?  I just get the following over and over no matter which account I 
>> switch in the command...
>>
>> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
>> uid=admin \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
>> uid=asteinfeld \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
>> uid=jmacklin \* krbPwdLockoutDuration ?
>> Enter LDAP Password:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> You have to specify which server to talk to using the -H ldap://fqdn.of.host 
> option.
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>


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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Rich Megginson]

On 10/17/2012 11:21 AM, Macklin, Jason wrote:

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" 
-W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

I know this user password

user password?  It's asking you for the directory manager password.

because I reset it for the purpose of troubleshooting this issue with that 
account. I also get the same response when I use the admin account of my own 
account.

You get Invalid credentials (49)?


-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: s...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
command or host level.

On 10/17/2012 11:13 AM, Macklin, Jason wrote:

None of my users have an LDAP password being requested by running that command 
(except the admin user).

Does each user account require an ldap account to go along with their login 
account?  I just get the following over and over no matter which account I 
switch in the command...

[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=admin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

You have to specify which server to talk to using the -H ldap://fqdn.of.host 
option.


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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Rich Megginson]

On 10/17/2012 11:51 AM, Macklin, Jason wrote:

I assume that this iteration was with the correct credentials as it responds with 
something other then "Invalid Credentials"

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" 
-W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
No such object (32)

Working account returns same thing...

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" 
-W uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
No such object (32)


Sorry, I though ipa would have configured your /etc/openldap/ldap.conf 
with your base dn.  Try this:


ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory 
manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \*


-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Wednesday, October 17, 2012 1:37 PM
To: Macklin, Jason {DASB~Branford}
Cc: rmegg...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
command or host level.

Macklin, Jason wrote:

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" 
-W uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

I know this user password because I reset it for the purpose of troubleshooting 
this issue with that account. I also get the same response when I use the admin 
account of my own account.

You use the password of the user you are binding as, in this case the directory 
manager.

rob


-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 1:15 PM
To: Macklin, Jason {DASB~Branford}
Cc: s...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
command or host level.

On 10/17/2012 11:13 AM, Macklin, Jason wrote:

None of my users have an LDAP password being requested by running that command 
(except the admin user).

Does each user account require an ldap account to go along with their login 
account?  I just get the following over and over no matter which account I 
switch in the command...

[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=admin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=asteinfeld \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W 
uid=jmacklin \* krbPwdLockoutDuration ?
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

You have to specify which server to talk to using the -H ldap://fqdn.of.host 
option.

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



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

Re: [Freeipa-users] Failed installation

[Bret Wortman]

Now it appears that whatever is supposed to be running on port 9445 (looks
like mindarray-ca) isn't running, and I'm not sure how it gets started,
exactly. I ran lsof -i:9445 on this server and on a FreeIPA test box I
first set up, and it's running on the test box but not the new one. Where
should I look next?

On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman
wrote:

> Spot on. It was a fresh install of F17 and I neglected to # yum update
> first. I've done so, rebooted, and am trying again with better results.
>
>
> On Wed, Oct 17, 2012 at 1:45 PM, John Dennis  wrote:
>
>> On 10/17/2012 12:40 PM, Bret Wortman wrote:
>>
>>> I recently tried installing freeipa on a new server, but
>>> ipa-server-install had problems around this point:
>>>
>>> Configuring certificate server: Estimated time 3 minutes 30 seconds
>>>[1/18]: creating certificate server user
>>>[2/18]: creating pki-ca instance
>>>[3/18]: configuring certificate server instance
>>> ipa : CRITICAL failed to configure ca instance Command
>>> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
>>> fs1.wedgeofli.me  -cs_port 9445
>>>
>>> -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd 
>>> -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin
>>> -admin_email root@localhost -admin_  -agent_name
>>> ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa
>>> -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME 
>>> -ldap_host fs1.wedgeofli.me  -ldap_port 7389
>>>
>>> -bind_dn cn=Directory Manager -bind_  -base_dn o=ipaca
>>> -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA
>>> -save_p12 true -backup_pwd  -subsystem_name pki-cad -token_name
>>> internal -ca_subsystem_cert_subject_**name CN=CA Subsystem,O=
>>> WEDGEOFLI.ME
>>>  -ca_ocsp_cert_subject_name CN=OCSP
>>> Subsystem,O=WEDGEOFLI.ME 
>>> -ca_server_cert_subject_name CN=fs1.wedgeofli.me
>>> ,O=WE**DGEOFLI.ME  <
>>> http://WEDGEOFLI.ME>
>>> -ca_audit_signing_cert_**subject_name CN=CA Audit,O=WEDGEOFLI.ME
>>>  -ca_sign_cert_subject_name CN=Certificate
>>> Authority,O=WEDGEOFLI.ME  -external false -clone
>>>
>>> false' returned non-zero exit status 255
>>> Unexpected error - see ipaserver-install.log for details:
>>>   Configuration of CA failed
>>> [root@fs1 ~]#
>>>
>>> The logfile revealed the following stack trace:
>>>
>>> ##**###
>>> Attempting to connect to: fs1.wedgeofli.me:9445
>>> 
>>>
>>> Exception in LoginPanel(): java.lang.NullPointerException
>>> ERROR: ConfigureCA: LoginPanel() failure
>>> ERROR: unable to create CA
>>>
>>> ##**##**
>>> ###
>>>
>>> 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send
>>> Request:java.net.**ConnectException: Connection refused
>>> java.net.ConnectException: Connection refused
>>> at java.net.PlainSocketImpl.**socketConnect(Native Method)
>>> at
>>> java.net.**AbstractPlainSocketImpl.**doConnect(**
>>> AbstractPlainSocketImpl.java:**339)
>>> at
>>> java.net.**AbstractPlainSocketImpl.**connectToAddress(**
>>> AbstractPlainSocketImpl.java:**200)
>>> at
>>> java.net.**AbstractPlainSocketImpl.**connect(**
>>> AbstractPlainSocketImpl.java:**182)
>>> at java.net.SocksSocketImpl.**connect(SocksSocketImpl.java:**391)
>>> at java.net.Socket.connect(**Socket.java:579)
>>> at java.net.Socket.connect(**Socket.java:528)
>>> at java.net.Socket.(Socket.**java:425)
>>> at java.net.Socket.(Socket.**java:241)
>>> at HTTPClient.sslConnect(**HTTPClient.java:326)
>>> at ConfigureCA.LoginPanel(**ConfigureCA.java:244)
>>> at ConfigureCA.**ConfigureCAInstance(**ConfigureCA.java:1157)
>>> at ConfigureCA.main(ConfigureCA.**java:1672)
>>> java.lang.NullPointerException
>>> at ConfigureCA.LoginPanel(**ConfigureCA.java:245)
>>> at ConfigureCA.**ConfigureCAInstance(**ConfigureCA.java:1157)
>>> at ConfigureCA.main(ConfigureCA.**java:1672)
>>>
>>> Now I seem to be stuck. I tried uninstalling the freeipa-server package
>>> with # yum remove freeipa-server and then reinstalled it the same way,
>>> but ipa-server-install won't run no matter what I attempt.
>>>
>>> Any thoughts? I'm pretty new to IPA.
>>>
>>
>> There is a good chance this is due to a version mismatch between the IPA
>> packages and the dogtag packages. You didn't mention which OS you're using
>> nor the versions of the relevant packages, that would have been helpful. In
>> any event I would make sure all your packages are up to date.
>>
>>
>> --
>> John Dennis 
>>
>>
>> Looking to carve out IT costs?
>> www.redhat.com/carveoutcosts/
>>
>
>
>
> --
> Bret Wortman
> The Damascus Group
> Fairfax, VA
> http://bretwortman.com/
> http://twitter.com/BretWortman
>
>


-- 
Bret Wortman
The 

Re: [Freeipa-users] Failed installation

[Dmitri Pal]

On 10/17/2012 02:31 PM, Bret Wortman wrote:
> Now it appears that whatever is supposed to be running on port 9445
> (looks like mindarray-ca) isn't running, and I'm not sure how it gets
> started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA
> test box I first set up, and it's running on the test box but not the
> new one. Where should I look next?

You cert system component failed to start because its DS instance failed
to start.

Did the install fail again after cleanup?
If not it is better to start over with cleanup and if the install fails
we will help you to troubleshoot.


>
> On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman
> mailto:bret.wort...@damascusgrp.com>>
> wrote:
>
> Spot on. It was a fresh install of F17 and I neglected to # yum
> update first. I've done so, rebooted, and am trying again with
> better results.
>
>
> On Wed, Oct 17, 2012 at 1:45 PM, John Dennis  > wrote:
>
> On 10/17/2012 12:40 PM, Bret Wortman wrote:
>
> I recently tried installing freeipa on a new server, but
> ipa-server-install had problems around this point:
>
> Configuring certificate server: Estimated time 3 minutes
> 30 seconds
>[1/18]: creating certificate server user
>[2/18]: creating pki-ca instance
>[3/18]: configuring certificate server instance
> ipa : CRITICAL failed to configure ca instance Command
> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
> fs1.wedgeofli.me 
>  -cs_port 9445
>
> -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd 
> -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA
> -admin_user admin
> -admin_email root@localhost -admin_ 
> -agent_name
> ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa
> -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME
>  
> -ldap_host fs1.wedgeofli.me 
>  -ldap_port 7389
>
> -bind_dn cn=Directory Manager -bind_ 
> -base_dn o=ipaca
> -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm
> SHA256withRSA
> -save_p12 true -backup_pwd  -subsystem_name
> pki-cad -token_name
> internal -ca_subsystem_cert_subject_name CN=CA
> Subsystem,O=WEDGEOFLI.ME 
>  -ca_ocsp_cert_subject_name CN=OCSP
> Subsystem,O=WEDGEOFLI.ME 
> 
> -ca_server_cert_subject_name CN=fs1.wedgeofli.me
> 
> ,O=WEDGEOFLI.ME
>  
> -ca_audit_signing_cert_subject_name CN=CA
> Audit,O=WEDGEOFLI.ME 
>  -ca_sign_cert_subject_name
> CN=Certificate
> Authority,O=WEDGEOFLI.ME 
>  -external false -clone
>
> false' returned non-zero exit status 255
> Unexpected error - see ipaserver-install.log for details:
>   Configuration of CA failed
> [root@fs1 ~]#
>
> The logfile revealed the following stack trace:
>
> #
> Attempting to connect to: fs1.wedgeofli.me:9445
> 
> 
>
> Exception in LoginPanel(): java.lang.NullPointerException
> ERROR: ConfigureCA: LoginPanel() failure
> ERROR: unable to create CA
>
> 
> ###
>
> 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send
> Request:java.net .ConnectException:
> Connection refused
> java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net
> 
> .AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
> at
> java.net
> 
> .AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
> at
> java.net
> 
> .AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
> at java.net.Socket.connect(So

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Macklin, Jason]

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" 
-W -b "dc=dbr,dc=roche,dc=com" uid=asteinfeld \*
Enter LDAP Password: 
dn: uid=asteinfeld,cn=users,cn=compat,dc=dbr,dc=roche,dc=com
objectClass: posixAccount
objectClass: top
gecos: Axel Steinfeld
cn: Axel Steinfeld
uidNumber: 2011
gidNumber: 2011
loginShell: /bin/bash
homeDirectory: /home2/asteinfeld
uid: asteinfeld

dn: uid=asteinfeld,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
displayName: Axel Steinfeld
cn: Axel Steinfeld
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: mepOriginEntry
loginShell: /bin/bash
sn: Steinfeld
uidNumber: 2011
gidNumber: 2011
gecos: Axel Steinfeld
homeDirectory: /home2/asteinfeld
krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc
 =roche,dc=com
krbPrincipalName: asteinf...@dbr.roche.com
givenName: Axel
uid: asteinfeld
initials: AS
userPassword:: e1NTSEF9OGpRZ09pazNWbGV0QlRTdm9DSjQ5b0VwaDhIQzZ5aHJ6Z2Foanc9PQ=
 =
ipaUniqueID: e582ea10-9e89-11e1-a7db-005056bb0010
krbPrincipalKey:: MIIC7qADAgEBoQMCAQGiAwIBA6MDAgEBpIIC1jCCAtIwb6AiMCCgAwIBAKEZ
 BBdEQlIuUk9DSEUuQ09NYXN0ZWluZmVsZKFJMEegAwIBEqFABD4gAKO2YZ6bzFkcvDQUQR1R0AEFO
 o+oNDP7NlR75fVLZ0932O8fxrDnbKL90Ti3N6AQJpaZzvUrDozy70LSbjBfoCIwIKADAgEAoRkEF0
 RCUi5ST0NIRS5DT01hc3RlaW5mZWxkoTkwN6ADAgERoTAELhAAIROPMbj/O/5yV9gynI1rc2CtckV
 mu7PczKYvb0O/Wk8D8QwBQyFSryrwMQAwZ6AiMCCgAwIBAKEZBBdEQlIuUk9DSEUuQ09NYXN0ZWlu
 ZmVsZKFBMD+gAwIBEKE4BDYYANU+Z6tmBZfUx5d7gf6NazwtXIlJsxZQZ8ntFigMGQxTjk4W/hDiz
 ECD0a6hskJuhmi8OjAwX6AiMCCgAwIBAKEZBBdEQlIuUk9DSEUuQ09NYXN0ZWluZmVsZKE5MDegAw
 IBF6EwBC4QADS3VnBvucc3YHvX0sL9YiASCYV7Iq5UV2seIw4bYlWt0b5RpLR5/fpbPyA5MFegIjA
 goAMCAQChGQQXREJSLlJPQ0hFLkNPTWFzdGVpbmZlbGShMTAvoAMCAQihKAQmCADwSRXiuHorXYmh
 UNvxq+HX/4j/dVSqr5vJ02anMGlZZnduCZcwV6AiMCCgAwIBAKEZBBdEQlIuUk9DSEUuQ09NYXN0Z
 WluZmVsZKExMC+gAwIBA6EoBCYIANEhS6vyfY9cpethqr64UZcf4XWMQFPYmvkrU6+qlWCnCqfKiD
 AzoTEwL6ADAgEBoSgEJggA6TGpzIElqIiEN+bgeZYSUJm5G/o3nORRyg1oAp8C1H35cyyVME2gGDA
 WoAMCAQWhDwQNREJSLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIACSVJDR+FFTCMrmWMcwwT4F47jxL
 LaAac0/gncsxU5+VR+jgfg==
krbPasswordExpiration: 20130324201805Z
krbLastPwdChange: 20120925201805Z
krbExtraData:: AAJ9EWJQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA==
mepManagedEntry: cn=asteinfeld,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: ipaUniqueID=be53ab18-0820-11e2-9b0a-005056bb0010,cn=sudorules,cn=sud
 o,dc=dbr,dc=roche,dc=com
memberOf: cn=tempsudo,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: ipaUniqueID=00544f1a-17a6-11e2-8dde-005056bb0010,cn=sudorules,cn=sud
 o,dc=dbr,dc=roche,dc=com
memberOf: ipaUniqueID=9a7ec120-185e-11e2-891c-005056bb0010,cn=hbac,dc=dbr,dc=r
 oche,dc=com
krbLoginFailedCount: 0
krbLastSuccessfulAuth: 20121017184614Z
krbTicketFlags: 128
krbLastFailedAuth: 20121015143818Z

[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -H 
ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b 
"dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP Password: 
dn: uid=jmacklin,cn=users,cn=compat,dc=dbr,dc=roche,dc=com
objectClass: posixAccount
objectClass: top
gecos: Jason Macklin
cn: Jason Macklin
uidNumber: 2084
gidNumber: 2084
loginShell: /bin/bash
homeDirectory: /home2/jmacklin
uid: jmacklin

dn: uid=jmacklin,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
displayName: Jason Macklin
cn: Jason Macklin
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: mepOriginEntry
loginShell: /bin/bash
sn: Macklin
gecos: Jason Macklin
homeDirectory: /home2/jmacklin
krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc
 =roche,dc=com
krbPrincipalName: jmack...@dbr.roche.com
givenName: Jason
uid: jmacklin
initials: JM
uidNumber: 2084
gidNumber: 2084
ipaUniqueID: 045652b4-8e3c-11e1-831f-005056bb0010
mepManagedEntry: cn=jmacklin,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=admins,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=Replication Administrators,cn=privileges,cn=pbac,dc=dbr,dc=roche,
 dc=com
memberOf: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=roche
 ,dc=com
memberOf: cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
 che,dc=com
memberOf: cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
 che,dc=com
memberOf: cn=Host Enrollment,cn=privileges,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Manage host keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Enroll a host,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=dbr,dc=r
 oche,dc=com
memberOf: cn=Unlock user accounts,cn=permiss

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Dmitri Pal]

On 10/17/2012 01:05 PM, Macklin, Jason wrote:
> Thanks guys!  Adding the "-b" did make a world of difference though it still 
> doesn't make anything too obvious... at least to me.
>
> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H 
> ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> SASL/GSSAPI authentication started
> SASL username: ad...@dbr.roche.com
> SASL SSF: 56
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base  with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # sudoers, dbr.roche.com
> dn: ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: extensibleObject
> ou: sudoers
>
> # test4, sudoers, dbr.roche.com
> dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: asteinfeld
> sudoHost: dbduwdu062.dbr.roche.com
> sudoHost: +tempsudo
> sudoCommand: ALL
> cn: test4

This means that user "asteinfeld" should be allowed to execute any
command on host "dbduwdu062.dbr.roche.com" or any host that is a member
of the "tempsudo" host group.
Is this the user you making tests with?

Keep in mind the other general per-requisits: If you use netgroups the
domain should be correct and the netgroups should be configured.
Also HBAC should allow this user to authenticate via sudo on this host.
AFAIR your HBAC is now wide open but when you start changing things to
narrow access you need to make HBAC rules for SUDO too. 
>
> # switch, sudoers, dbr.roche.com
> dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: oyilmaz
> sudoHost: dbdusdu071.dbr.roche.com
> sudoCommand: /bin/su
> cn: switch

This rule allows "oyilmaz" to execute one command "/bin/su" on host
"dbdusdu071.dbr.roche.com"
>
> # jing144, sudoers, dbr.roche.com
> dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: jli
> sudoHost: dbduvdu144.dbr.roche.com
> sudoCommand: ALL
> cn: jing144

I hope you can now deduce the meaning of this one :-)

>
> # Admin, sudoers, dbr.roche.com
> dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: jmacklin
> sudoUser: mrini
> sudoUser: cgajare
> sudoUser: parnold
> sudoUser: hhebert
> sudoUser: ckuecherer
> sudoUser: gferreri
> sudoHost: ALL
> sudoCommand: ALL
> cn: Admin

given users ALL commands on any host.

> # search result
> search: 4
> result: 0 Success
>
> # numResponses: 6
> # numEntries: 5
>
> I really appreciate all of the help!
>
> Cheers,
> Jason
>

So with this knowledge can you try different combinations of users and
hosts and provide the results?
You might want to remove the Admin for now to get it out of picture.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Macklin, Jason]

Yes Dmitri, this is the user I'm doing the tests with on that client.  Though I 
would expect this user to have sudo capabilities on this host he does not.  I 
first came across the idea that maybe domainname/nisdomainname/dnsdomainname 
did not match and that was causing the problem.  I have since fixed all of 
those to match my system domain which is the same domain that the client was 
enrolled with and it did not change any of the sudo behaviors for this user.  I 
currently have no specific HBAC rule configured besides the "wide open" rule.  
Do I need one more specific for allowing users to run sudo?

-Original Message-
From: Dmitri Pal [mailto:d...@redhat.com] 
Sent: Wednesday, October 17, 2012 2:57 PM
To: Macklin, Jason {DASB~Branford}
Cc: jr.aqu...@citrix.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
command or host level.

On 10/17/2012 01:05 PM, Macklin, Jason wrote:
> Thanks guys!  Adding the "-b" did make a world of difference though it still 
> doesn't make anything too obvious... at least to me.
>
> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H 
> ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> SASL/GSSAPI authentication started
> SASL username: ad...@dbr.roche.com
> SASL SSF: 56
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base  with scope subtree # 
> filter: (objectclass=*) # requesting: ALL #
>
> # sudoers, dbr.roche.com
> dn: ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: extensibleObject
> ou: sudoers
>
> # test4, sudoers, dbr.roche.com
> dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: asteinfeld
> sudoHost: dbduwdu062.dbr.roche.com
> sudoHost: +tempsudo
> sudoCommand: ALL
> cn: test4

This means that user "asteinfeld" should be allowed to execute any command on 
host "dbduwdu062.dbr.roche.com" or any host that is a member of the "tempsudo" 
host group.
Is this the user you making tests with?

Keep in mind the other general per-requisits: If you use netgroups the domain 
should be correct and the netgroups should be configured.
Also HBAC should allow this user to authenticate via sudo on this host.
AFAIR your HBAC is now wide open but when you start changing things to narrow 
access you need to make HBAC rules for SUDO too. 
>
> # switch, sudoers, dbr.roche.com
> dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: oyilmaz
> sudoHost: dbdusdu071.dbr.roche.com
> sudoCommand: /bin/su
> cn: switch

This rule allows "oyilmaz" to execute one command "/bin/su" on host 
"dbdusdu071.dbr.roche.com"
>
> # jing144, sudoers, dbr.roche.com
> dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: jli
> sudoHost: dbduvdu144.dbr.roche.com
> sudoCommand: ALL
> cn: jing144

I hope you can now deduce the meaning of this one :-)

>
> # Admin, sudoers, dbr.roche.com
> dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com
> objectClass: sudoRole
> sudoUser: jmacklin
> sudoUser: mrini
> sudoUser: cgajare
> sudoUser: parnold
> sudoUser: hhebert
> sudoUser: ckuecherer
> sudoUser: gferreri
> sudoHost: ALL
> sudoCommand: ALL
> cn: Admin

given users ALL commands on any host.

> # search result
> search: 4
> result: 0 Success
>
> # numResponses: 6
> # numEntries: 5
>
> I really appreciate all of the help!
>
> Cheers,
> Jason
>

So with this knowledge can you try different combinations of users and hosts 
and provide the results?
You might want to remove the Admin for now to get it out of picture.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio Red Hat Inc.


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




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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Rich Megginson]

On 10/17/2012 12:49 PM, Macklin, Jason wrote:

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b 
"dc=dbr,dc=roche,dc=com" uid=asteinfeld \*




dn: uid=asteinfeld,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com

...snip...

krbPrincipalName: asteinf...@dbr.roche.com
krbPasswordExpiration: 20130324201805Z
krbLastPwdChange: 20120925201805Z
krbLoginFailedCount: 0
krbLastSuccessfulAuth: 20121017184614Z
krbTicketFlags: 128
krbLastFailedAuth: 20121015143818Z


No krbPwdLockoutDuration attribute - so according to ipalockout_preop() 
this means the "Entry permanently locked".  Not sure why.


[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D 
"cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP 
Password:
dn: uid=jmacklin,cn=users,cn=compat,dc=dbr,dc=roche,dc=com
objectClass: posixAccount
objectClass: top
gecos: Jason Macklin
cn: Jason Macklin
uidNumber: 2084
gidNumber: 2084
loginShell: /bin/bash
homeDirectory: /home2/jmacklin
uid: jmacklin

dn: uid=jmacklin,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
displayName: Jason Macklin
cn: Jason Macklin
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: mepOriginEntry
loginShell: /bin/bash
sn: Macklin
gecos: Jason Macklin
homeDirectory: /home2/jmacklin
krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc
  =roche,dc=com
krbPrincipalName: jmack...@dbr.roche.com
givenName: Jason
uid: jmacklin
initials: JM
uidNumber: 2084
gidNumber: 2084
ipaUniqueID: 045652b4-8e3c-11e1-831f-005056bb0010
mepManagedEntry: cn=jmacklin,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=admins,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=Replication Administrators,cn=privileges,cn=pbac,dc=dbr,dc=roche,
  dc=com
memberOf: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=roche
  ,dc=com
memberOf: cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
  che,dc=com
memberOf: cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
  che,dc=com
memberOf: cn=Host Enrollment,cn=privileges,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Manage host keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Enroll a host,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=dbr,dc=r
  oche,dc=com
memberOf: cn=Unlock user accounts,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=co
  m
memberOf: cn=Manage service keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=c
  om
memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: ipaUniqueID=23216c12-9934-11e1-bd4c-005056bb0010,cn=sudorules,cn=sud
  o,dc=dbr,dc=roche,dc=com
krbLastFailedAuth: 20121017164159Z
krbPrincipalKey:: MIIC4qADAgEBoQMCAQGiAwIBBaMDAgEBpIICyjCCAsYwbaAgMB6gAwIBAKEX
  BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hSTBHoAMCARKhQAQ+IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a
  sC2QJFL/lnbaFO1DYG15WjJYXnJ7k3m0LN0aTyjvz7FN4OWMF4tvvowXaAgMB6gAwIBAKEXBBVEQl
  IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARGhMAQuEAD6UdNSe/mp8qqi4OuT7HOqIs80DFQDRny
  37aZaD4lYrFsnQiBtpnpMnNSxADBloCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqFB
  MD+gAwIBEKE4BDYYADAQZLDW61U+4aEZT4b+/X/OpiQLHTQlyIUolm9EjVG4wXu+8Mn4lMYMZyR/F
  Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARehMAQuEA
  CiWDGd28XkiaDAwpGyK0MqSawLCXs+jKOFAA5BoSpayVTJJqjzAwSEitSu5zBVoCAwHqADAgEAoRc
  EFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gAwIBCKEoBCYIAKL5bzV4nQide/+6/2FE5LxYGULv
  8Ws/Uu0RXrwAnR8/ZuUh0TBVoCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gA
  wIBA6EoBCYIANgV0agxRmfBwY2Cb7gPlm1oWDY5qhZidd8a0KmeIlBG56XLZjAzoTEwL6ADAgEBoS
  gEJggAo/BQC7g4SWQY0UkU7rvoOAXwobVlAZn8mesgQEznRDr2+bxjME2gGDAWoAMCAQWhDwQNREJ
  SLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+Lzs0Ulxgf4FDEnTRXTjfJBqXIJb
  R5aBPg==
krbLastPwdChange: 20120809140419Z
krbPasswordExpiration: 20130205140419Z
userPassword:: e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVVF4VTdJLzh1TXREVnBWZjlnMWRxa0E9PQ=
  =
krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA==
krbLastSuccessfulAuth: 2012101718Z
krbLoginFailedCount: 0
krbTicketFlags: 128

So with all of that output, I would like to mention the discrepancy with ldap.conf.  Just 
trying to get any "sudo" working on RHEL 6.3 was problematic until I stumbled 
upon a post that mentioned creating/editing /etc/sudo-ldap.conf rather then 
/etc/ldap.conf or /etc/openldap/ldap.conf.  If I remove the /etc/sudo-ldap.conf then I 
have no sudo capabilities at all.

-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 2:06 PM
To: Macklin, Jason {DASB~Branford}
Cc: rcrit...@redhat.com; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
command or host level.

On 10/17/2012 11:51 AM, Macklin, Jason

Re: [Freeipa-users] Failed installation

[Rob Crittenden]

Bret Wortman wrote:

Now it appears that whatever is supposed to be running on port 9445
(looks like mindarray-ca) isn't running, and I'm not sure how it gets
started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA
test box I first set up, and it's running on the test box but not the
new one. Where should I look next?


See if there are any SELinux denials: ausearch -m AVC

It looks like tomcat failed to start. The logs are in /var/log/pki-ca.

rob



On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman
mailto:bret.wort...@damascusgrp.com>> wrote:

Spot on. It was a fresh install of F17 and I neglected to # yum
update first. I've done so, rebooted, and am trying again with
better results.


On Wed, Oct 17, 2012 at 1:45 PM, John Dennis mailto:jden...@redhat.com>> wrote:

On 10/17/2012 12:40 PM, Bret Wortman wrote:

I recently tried installing freeipa on a new server, but
ipa-server-install had problems around this point:

Configuring certificate server: Estimated time 3 minutes 30
seconds
[1/18]: creating certificate server user
[2/18]: creating pki-ca instance
[3/18]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
fs1.wedgeofli.me 
 -cs_port 9445

-client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd 
-preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user
admin
-admin_email root@localhost -admin_  -agent_name
ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa
-agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME
 
-ldap_host fs1.wedgeofli.me 
 -ldap_port 7389

-bind_dn cn=Directory Manager -bind_ 
-base_dn o=ipaca
-db_name ipaca -key_size 2048 -key_type rsa -key_algorithm
SHA256withRSA
-save_p12 true -backup_pwd  -subsystem_name pki-cad
-token_name
internal -ca_subsystem_cert_subject___name CN=CA
Subsystem,O=WEDGEOFLI.ME 
 -ca_ocsp_cert_subject_name CN=OCSP
Subsystem,O=WEDGEOFLI.ME 

-ca_server_cert_subject_name CN=fs1.wedgeofli.me

,O=WE__DGEOFLI.ME
 
-ca_audit_signing_cert___subject_name CN=CA
Audit,O=WEDGEOFLI.ME 
 -ca_sign_cert_subject_name CN=Certificate
Authority,O=WEDGEOFLI.ME 
 -external false -clone

false' returned non-zero exit status 255
Unexpected error - see ipaserver-install.log for details:
   Configuration of CA failed
[root@fs1 ~]#

The logfile revealed the following stack trace:

##__###
Attempting to connect to: fs1.wedgeofli.me:9445



Exception in LoginPanel(): java.lang.NullPointerException
ERROR: ConfigureCA: LoginPanel() failure
ERROR: unable to create CA


##__##__###

2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send
Request:java.net .__ConnectException:
Connection refused
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.__socketConnect(Native Method)
at
java.net

.__AbstractPlainSocketImpl.__doConnect(__AbstractPlainSocketImpl.java:__339)
at
java.net

.__AbstractPlainSocketImpl.__connectToAddress(__AbstractPlainSocketImpl.java:__200)
at
java.net

.__AbstractPlainSocketImpl.__connect(__AbstractPlainSocketImpl.java:__182)
at
java.net.SocksSocketImpl.__connect(SocksSocketImpl.java:__391)
at java.net.Socket.connect(__Socket.java:579)
at java.net.Socket.connect(__Socket.java:528)
at java.net.Socket.(Socket.__java:425)
at java.net.Socket.(Socket.__java:241)
at HTTPClient.sslConnect(__HTTPClient.java:326)
at ConfigureCA.LoginPanel(__Config

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Dmitri Pal]

On 10/17/2012 03:05 PM, Macklin, Jason wrote:
> Yes Dmitri, this is the user I'm doing the tests with on that client.  Though 
> I would expect this user to have sudo capabilities on this host he does not.  
> I first came across the idea that maybe 
> domainname/nisdomainname/dnsdomainname did not match and that was causing the 
> problem.  I have since fixed all of those to match my system domain which is 
> the same domain that the client was enrolled with and it did not change any 
> of the sudo behaviors for this user.  I currently have no specific HBAC rule 
> configured besides the "wide open" rule.  Do I need one more specific for 
> allowing users to run sudo?

No. It should just work then. It definitely connects and matches the
Admin rule but not the other rules so I was not sure if you are testing
the right rule on the right machine with the right user.

We can start dealing with the problems step by step.
We know Admin rule works.
If you add all hosts to a hostgroup and use it in the Admin rule instead
of just all would it continue to work?
Then you can start removing hosts from the group one by one.

After testing with group you can replace the group with individual host
and see whether it works and so on.
May be there is a bug somewhere but so far we have not narrowed it done
well enough.

I am traveling next day so I hope someone else will pickup the thread.

>
> -Original Message-
> From: Dmitri Pal [mailto:d...@redhat.com] 
> Sent: Wednesday, October 17, 2012 2:57 PM
> To: Macklin, Jason {DASB~Branford}
> Cc: jr.aqu...@citrix.com; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
> command or host level.
>
> On 10/17/2012 01:05 PM, Macklin, Jason wrote:
>> Thanks guys!  Adding the "-b" did make a world of difference though it still 
>> doesn't make anything too obvious... at least to me.
>>
>> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H 
>> ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com"
>> SASL/GSSAPI authentication started
>> SASL username: ad...@dbr.roche.com
>> SASL SSF: 56
>> SASL data security layer installed.
>> # extended LDIF
>> #
>> # LDAPv3
>> # base  with scope subtree # 
>> filter: (objectclass=*) # requesting: ALL #
>>
>> # sudoers, dbr.roche.com
>> dn: ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: extensibleObject
>> ou: sudoers
>>
>> # test4, sudoers, dbr.roche.com
>> dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: sudoRole
>> sudoUser: asteinfeld
>> sudoHost: dbduwdu062.dbr.roche.com
>> sudoHost: +tempsudo
>> sudoCommand: ALL
>> cn: test4
> This means that user "asteinfeld" should be allowed to execute any command on 
> host "dbduwdu062.dbr.roche.com" or any host that is a member of the 
> "tempsudo" host group.
> Is this the user you making tests with?
>
> Keep in mind the other general per-requisits: If you use netgroups the domain 
> should be correct and the netgroups should be configured.
> Also HBAC should allow this user to authenticate via sudo on this host.
> AFAIR your HBAC is now wide open but when you start changing things to narrow 
> access you need to make HBAC rules for SUDO too. 
>> # switch, sudoers, dbr.roche.com
>> dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: sudoRole
>> sudoUser: oyilmaz
>> sudoHost: dbdusdu071.dbr.roche.com
>> sudoCommand: /bin/su
>> cn: switch
> This rule allows "oyilmaz" to execute one command "/bin/su" on host 
> "dbdusdu071.dbr.roche.com"
>> # jing144, sudoers, dbr.roche.com
>> dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: sudoRole
>> sudoUser: jli
>> sudoHost: dbduvdu144.dbr.roche.com
>> sudoCommand: ALL
>> cn: jing144
> I hope you can now deduce the meaning of this one :-)
>
>> # Admin, sudoers, dbr.roche.com
>> dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: sudoRole
>> sudoUser: jmacklin
>> sudoUser: mrini
>> sudoUser: cgajare
>> sudoUser: parnold
>> sudoUser: hhebert
>> sudoUser: ckuecherer
>> sudoUser: gferreri
>> sudoHost: ALL
>> sudoCommand: ALL
>> cn: Admin
> given users ALL commands on any host.
>
>> # search result
>> search: 4
>> result: 0 Success
>>
>> # numResponses: 6
>> # numEntries: 5
>>
>> I really appreciate all of the help!
>>
>> Cheers,
>> Jason
>>
> So with this knowledge can you try different combinations of users and hosts 
> and provide the results?
> You might want to remove the Admin for now to get it out of picture.
>
> --
> 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/



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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Rob Crittenden]

Rich Megginson wrote:

On 10/17/2012 12:49 PM, Macklin, Jason wrote:

ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory
manager" -W -b "dc=dbr,dc=roche,dc=com" uid=asteinfeld \*




dn: uid=asteinfeld,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com

...snip...

krbPrincipalName: asteinf...@dbr.roche.com
krbPasswordExpiration: 20130324201805Z
krbLastPwdChange: 20120925201805Z
krbLoginFailedCount: 0
krbLastSuccessfulAuth: 20121017184614Z
krbTicketFlags: 128
krbLastFailedAuth: 20121015143818Z


No krbPwdLockoutDuration attribute - so according to ipalockout_preop()
this means the "Entry permanently locked".  Not sure why.


I don't believe this applies if the attribute doesn't exist. It doesn't 
for any of my test users and it works fine.




[jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -H
ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b
"dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP Password:
dn: uid=jmacklin,cn=users,cn=compat,dc=dbr,dc=roche,dc=com
objectClass: posixAccount
objectClass: top
gecos: Jason Macklin
cn: Jason Macklin
uidNumber: 2084
gidNumber: 2084
loginShell: /bin/bash
homeDirectory: /home2/jmacklin
uid: jmacklin

dn: uid=jmacklin,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com
displayName: Jason Macklin
cn: Jason Macklin
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: mepOriginEntry
loginShell: /bin/bash
sn: Macklin
gecos: Jason Macklin
homeDirectory: /home2/jmacklin
krbPwdPolicyReference:
cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc
  =roche,dc=com
krbPrincipalName: jmack...@dbr.roche.com
givenName: Jason
uid: jmacklin
initials: JM
uidNumber: 2084
gidNumber: 2084
ipaUniqueID: 045652b4-8e3c-11e1-831f-005056bb0010
mepManagedEntry: cn=jmacklin,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=admins,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf: cn=Replication
Administrators,cn=privileges,cn=pbac,dc=dbr,dc=roche,
  dc=com
memberOf: cn=Add Replication
Agreements,cn=permissions,cn=pbac,dc=dbr,dc=roche
  ,dc=com
memberOf: cn=Modify Replication
Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
  che,dc=com
memberOf: cn=Remove Replication
Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro
  che,dc=com
memberOf: cn=Host Enrollment,cn=privileges,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Manage host
keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Enroll a host,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com
memberOf: cn=Add krbPrincipalName to a
host,cn=permissions,cn=pbac,dc=dbr,dc=r
  oche,dc=com
memberOf: cn=Unlock user
accounts,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=co
  m
memberOf: cn=Manage service
keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=c
  om
memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com
memberOf:
ipaUniqueID=23216c12-9934-11e1-bd4c-005056bb0010,cn=sudorules,cn=sud
  o,dc=dbr,dc=roche,dc=com
krbLastFailedAuth: 20121017164159Z
krbPrincipalKey::
MIIC4qADAgEBoQMCAQGiAwIBBaMDAgEBpIICyjCCAsYwbaAgMB6gAwIBAKEX

BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hSTBHoAMCARKhQAQ+IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a


sC2QJFL/lnbaFO1DYG15WjJYXnJ7k3m0LN0aTyjvz7FN4OWMF4tvvowXaAgMB6gAwIBAKEXBBVEQl


IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARGhMAQuEAD6UdNSe/mp8qqi4OuT7HOqIs80DFQDRny


37aZaD4lYrFsnQiBtpnpMnNSxADBloCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqFB


MD+gAwIBEKE4BDYYADAQZLDW61U+4aEZT4b+/X/OpiQLHTQlyIUolm9EjVG4wXu+8Mn4lMYMZyR/F


Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARehMAQuEA


CiWDGd28XkiaDAwpGyK0MqSawLCXs+jKOFAA5BoSpayVTJJqjzAwSEitSu5zBVoCAwHqADAgEAoRc


EFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gAwIBCKEoBCYIAKL5bzV4nQide/+6/2FE5LxYGULv


8Ws/Uu0RXrwAnR8/ZuUh0TBVoCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gA


wIBA6EoBCYIANgV0agxRmfBwY2Cb7gPlm1oWDY5qhZidd8a0KmeIlBG56XLZjAzoTEwL6ADAgEBoS


gEJggAo/BQC7g4SWQY0UkU7rvoOAXwobVlAZn8mesgQEznRDr2+bxjME2gGDAWoAMCAQWhDwQNREJ


SLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+Lzs0Ulxgf4FDEnTRXTjfJBqXIJb

  R5aBPg==
krbLastPwdChange: 20120809140419Z
krbPasswordExpiration: 20130205140419Z
userPassword::
e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVVF4VTdJLzh1TXREVnBWZjlnMWRxa0E9PQ=
  =
krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA==
krbLastSuccessfulAuth: 2012101718Z
krbLoginFailedCount: 0
krbTicketFlags: 128

So with all of that output, I would like to mention the discrepancy
with ldap.conf.  Just trying to get any "sudo" working on RHEL 6.3 was
problematic until I stumbled upon a post that mentioned
creating/editing /etc/sudo-ldap.conf rather then /etc/ldap.conf or
/etc/openldap/ldap.conf.  If I remove the /etc/sudo-ldap.conf then I
have no sudo capabilities at all.

-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, October 17, 2012 2:06 PM
To: Macklin, Jason {DASB~Branford}
Cc: rcrit...@redhat.com; freeipa-users@redhat.com
S

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Rob Crittenden]

Can you confirm that you have sudoer_debug set to 2?

If I gather correctly, this is on RHEL 6.3? What version of sudo?

I'm seeing different output. Mine includes the number of candidate 
results for sudoUser are found.


If you watch /var/log/dirsrv/slapd-REALM/access on your IPA server 
you'll be able to see the LDAP searches the sudo client is making. The 
log is buffered so you won't see them immediately. Can you send us the 
queries that are being made?


thanks

rob

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

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Toasted Penguin]

On Wed, Oct 17, 2012 at 2:26 PM, Rob Crittenden  wrote:

> Rich Megginson wrote:
>
>> On 10/17/2012 12:49 PM, Macklin, Jason wrote:
>>
>>> ldapsearch -xLLL -H 
>>> ldap://dbduvdu145.dbr.roche.**com-D 
>>> "cn=directory
>>> manager" -W -b "dc=dbr,dc=roche,dc=com" uid=asteinfeld \*
>>>
>> 
>>
>>>
>>> dn: uid=asteinfeld,cn=users,cn=**accounts,dc=dbr,dc=roche,dc=**com
>>>
>> ...snip...
>>
>>> krbPrincipalName: asteinf...@dbr.roche.com
>>> krbPasswordExpiration: 20130324201805Z
>>> krbLastPwdChange: 20120925201805Z
>>> krbLoginFailedCount: 0
>>> krbLastSuccessfulAuth: 20121017184614Z
>>> krbTicketFlags: 128
>>> krbLastFailedAuth: 20121015143818Z
>>>
>>
>> No krbPwdLockoutDuration attribute - so according to ipalockout_preop()
>> this means the "Entry permanently locked".  Not sure why.
>>
>
> I don't believe this applies if the attribute doesn't exist. It doesn't
> for any of my test users and it works fine.
>
>
>
>>> [jmacklin@dbduwdu062 Desktop]$ ldapsearch -xLLL -H
>>> ldap://dbduvdu145.dbr.roche.**com  -D
>>> "cn=directory manager" -W -b
>>> "dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP Password:
>>> dn: uid=jmacklin,cn=users,cn=**compat,dc=dbr,dc=roche,dc=com
>>> objectClass: posixAccount
>>> objectClass: top
>>> gecos: Jason Macklin
>>> cn: Jason Macklin
>>> uidNumber: 2084
>>> gidNumber: 2084
>>> loginShell: /bin/bash
>>> homeDirectory: /home2/jmacklin
>>> uid: jmacklin
>>>
>>> dn: uid=jmacklin,cn=users,cn=**accounts,dc=dbr,dc=roche,dc=**com
>>> displayName: Jason Macklin
>>> cn: Jason Macklin
>>> objectClass: top
>>> objectClass: person
>>> objectClass: organizationalperson
>>> objectClass: inetorgperson
>>> objectClass: inetuser
>>> objectClass: posixaccount
>>> objectClass: krbprincipalaux
>>> objectClass: krbticketpolicyaux
>>> objectClass: ipaobject
>>> objectClass: mepOriginEntry
>>> loginShell: /bin/bash
>>> sn: Macklin
>>> gecos: Jason Macklin
>>> homeDirectory: /home2/jmacklin
>>> krbPwdPolicyReference:
>>> cn=global_policy,cn=DBR.ROCHE.**COM 
>>> ,cn=kerberos,dc=dbr,dc
>>>   =roche,dc=com
>>> krbPrincipalName: jmack...@dbr.roche.com
>>> givenName: Jason
>>> uid: jmacklin
>>> initials: JM
>>> uidNumber: 2084
>>> gidNumber: 2084
>>> ipaUniqueID: 045652b4-8e3c-11e1-831f-**005056bb0010
>>> mepManagedEntry: cn=jmacklin,cn=groups,cn=**accounts,dc=dbr,dc=roche,dc=
>>> **com
>>> memberOf: cn=admins,cn=groups,cn=**accounts,dc=dbr,dc=roche,dc=**com
>>> memberOf: cn=Replication
>>> Administrators,cn=privileges,**cn=pbac,dc=dbr,dc=roche,
>>>   dc=com
>>> memberOf: cn=Add Replication
>>> Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=roche
>>>   ,dc=com
>>> memberOf: cn=Modify Replication
>>> Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=ro
>>>   che,dc=com
>>> memberOf: cn=Remove Replication
>>> Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=ro
>>>   che,dc=com
>>> memberOf: cn=Host Enrollment,cn=privileges,cn=**
>>> pbac,dc=dbr,dc=roche,dc=com
>>> memberOf: cn=Manage host
>>> keytab,cn=permissions,cn=pbac,**dc=dbr,dc=roche,dc=com
>>> memberOf: cn=Enroll a host,cn=permissions,cn=pbac,**
>>> dc=dbr,dc=roche,dc=com
>>> memberOf: cn=Add krbPrincipalName to a
>>> host,cn=permissions,cn=pbac,**dc=dbr,dc=r
>>>   oche,dc=com
>>> memberOf: cn=Unlock user
>>> accounts,cn=permissions,cn=**pbac,dc=dbr,dc=roche,dc=co
>>>   m
>>> memberOf: cn=Manage service
>>> keytab,cn=permissions,cn=pbac,**dc=dbr,dc=roche,dc=c
>>>   om
>>> memberOf: cn=dbr,cn=groups,cn=accounts,**dc=dbr,dc=roche,dc=com
>>> memberOf:
>>> ipaUniqueID=23216c12-9934-**11e1-bd4c-005056bb0010,cn=**sudorules,cn=sud
>>>   o,dc=dbr,dc=roche,dc=com
>>> krbLastFailedAuth: 20121017164159Z
>>> krbPrincipalKey::
>>> MIIC4qADAgEBoQMCAQGiAwIBBaMDAg**EBpIICyjCCAsYwbaAgMB6gAwIBAKEX
>>>
>>> BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW**6hSTBHoAMCARKhQAQ+**
>>> IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a
>>>
>>>
>>> sC2QJFL/**lnbaFO1DYG15WjJYXnJ7k3m0LN0aTy**jvz7FN4OWMF4tvvowXaAgMB6gAwIBA
>>> **KEXBBVEQl
>>>
>>>
>>> IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3**oAMCARGhMAQuEAD6UdNSe/**
>>> mp8qqi4OuT7HOqIs80DFQDRny
>>>
>>>
>>> 37aZaD4lYrFsnQiBtpnpMnNSxADBlo**CAwHqADAgEAoRcEFURCUi5ST0NIRS5**
>>> DT01qbWFja2xpbqFB
>>>
>>>
>>> MD+gAwIBEKE4BDYYADAQZLDW61U+**4aEZT4b+/X/**OpiQLHTQlyIUolm9EjVG4wXu+**
>>> 8Mn4lMYMZyR/F
>>>
>>>
>>> Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBV**EQlIuUk9DSEUuQ09Nam1hY2tsaW6hO**
>>> TA3oAMCARehMAQuEA
>>>
>>>
>>> CiWDGd28XkiaDAwpGyK0MqSawLCXs+**jKOFAA5BoSpayVTJJqjzAwSEitSu5z**
>>> BVoCAwHqADAgEAoRc
>>>
>>>
>>> EFURCUi5ST0NIRS5DT01qbWFja2xpb**qExMC+**gAwIBCKEoBCYIAKL5bzV4nQide/+6/**
>>> 2FE5LxYGULv
>>>
>>>
>>> 8Ws/Uu0RXrwAnR8/**ZuUh0TBVoCAwHqADAgEAoRcEFURCUi**
>>> 5ST0NIRS5DT01qbWFja2xpbqExMC+**gA
>>>
>>>
>>> wIBA6EoBCYIANgV0agxRmfBwY2Cb7g**Plm1oWDY5qhZidd8a0KmeIlBG56XLZ**
>>> jAzoTEwL6ADAgEBoS
>>>
>>>
>>> gEJggAo/**BQC7g4SWQY0UkU7rvoOAXwobVlAZn8**mesgQEznRDr2+**
>>> bxjME2gGDAWoAMCAQWhDwQNREJ
>>>
>>>
>>> SLlJPQ0hFLkNPTaExMC+**gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+**
>>> Lzs0Ulxgf4FDEnTRXTjfJBqXIJb
>>>
>>>   R5aBPg==
>>> kr

Re: [Freeipa-users] Failed installation

[Bret Wortman]

I think I have SELinux turned off but will double-check in the morning. And 
reply to the list 


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


On Wednesday, October 17, 2012 at 3:17 PM, Rob Crittenden wrote:

> Bret Wortman wrote:
> > Now it appears that whatever is supposed to be running on port 9445
> > (looks like mindarray-ca) isn't running, and I'm not sure how it gets
> > started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA
> > test box I first set up, and it's running on the test box but not the
> > new one. Where should I look next?
> > 
> 
> 
> See if there are any SELinux denials: ausearch -m AVC
> 
> It looks like tomcat failed to start. The logs are in /var/log/pki-ca.
> 
> rob
> 
> > 
> > On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman
> > mailto:bret.wort...@damascusgrp.com>> wrote:
> > 
> > Spot on. It was a fresh install of F17 and I neglected to # yum
> > update first. I've done so, rebooted, and am trying again with
> > better results.
> > 
> > 
> > On Wed, Oct 17, 2012 at 1:45 PM, John Dennis  > > wrote:
> > 
> > On 10/17/2012 12:40 PM, Bret Wortman wrote:
> > 
> > I recently tried installing freeipa on a new server, but
> > ipa-server-install had problems around this point:
> > 
> > Configuring certificate server: Estimated time 3 minutes 30
> > seconds
> > [1/18]: creating certificate server user
> > [2/18]: creating pki-ca instance
> > [3/18]: configuring certificate server instance
> > ipa : CRITICAL failed to configure ca instance Command
> > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
> > fs1.wedgeofli.me 
> >  -cs_port 9445
> > 
> > -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd 
> > -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user
> > admin
> > -admin_email root@localhost -admin_  -agent_name
> > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa
> > -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME
> >  
> > -ldap_host fs1.wedgeofli.me 
> >  -ldap_port 7389
> > 
> > -bind_dn cn=Directory Manager -bind_ 
> > -base_dn o=ipaca
> > -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm
> > SHA256withRSA
> > -save_p12 true -backup_pwd  -subsystem_name pki-cad
> > -token_name
> > internal -ca_subsystem_cert_subject___name CN=CA
> > Subsystem,O=WEDGEOFLI.ME 
> >  -ca_ocsp_cert_subject_name CN=OCSP
> > Subsystem,O=WEDGEOFLI.ME 
> > 
> > -ca_server_cert_subject_name CN=fs1.wedgeofli.me
> > 
> > ,O=WE__DGEOFLI.ME
> >  
> > -ca_audit_signing_cert___subject_name CN=CA
> > Audit,O=WEDGEOFLI.ME 
> >  -ca_sign_cert_subject_name CN=Certificate
> > Authority,O=WEDGEOFLI.ME 
> >  -external false -clone
> > 
> > false' returned non-zero exit status 255
> > Unexpected error - see ipaserver-install.log for details:
> > Configuration of CA failed
> > [root@fs1 ~]#
> > 
> > The logfile revealed the following stack trace:
> > 
> > ##__###
> > Attempting to connect to: fs1.wedgeofli.me:9445
> > 
> > 
> > 
> > Exception in LoginPanel(): java.lang.NullPointerException
> > ERROR: ConfigureCA: LoginPanel() failure
> > ERROR: unable to create CA
> > 
> > ##__##__###
> > 
> > 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send
> > Request:java.net .__ConnectException:
> > Connection refused
> > java.net.ConnectException: Connection refused
> > at java.net.PlainSocketImpl.__socketConnect(Native Method)
> > at
> > java.net
> > .__AbstractPlainSocketImpl.__doConnect(__AbstractPlainSocketImpl.java:__339)
> > at
> > java.net
> > .__AbstractPlainSocketImpl.__connectToAddress(__AbstractPlainSocketImpl.java:__200)
> > at
> > java.net
> > .__AbstractPlainSocketImpl.__connect(__AbstractPlainSocketImpl.java:__182)
> > at
> > java.net.SocksSocketImpl.__connect(SocksSocketImpl.java:__391)
> > at java.net.Socket.connect(__Socket.java:579)
> > at java.net.Socket.connect(__Socket.java:528)
> > at java.net.Socket.(Socket.__java:425)
> > at java.net.Socket.(Socket.__java:241)
> > at HTTPClient.sslConnect(__HTTPClient.java:326)
> > at ConfigureCA.LoginPanel(__ConfigureCA.java:244)
> > at ConfigureCA.__ConfigureCAInstance(__ConfigureCA.java:1157)
> > at ConfigureCA.main(ConfigureCA.__java:1672)
> > java.lang.NullPointerException
> > at ConfigureCA.LoginPanel(__ConfigureCA.java:245)
> > at ConfigureCA.__ConfigureCAInstance(__ConfigureCA.ja