Re: [Freeipa-users] Certificate profiles and CA ACLs for service principals

[Fraser Tweedale]

On Wed, Mar 23, 2016 at 04:37:43PM +1100, a.fed...@earsdown.com
wrote:
> Some excellent points, and thank you for being open to having the
> conversation - I know you don't have to, and it is appreciated.
> 
> > Profiles which are allowed for a host principal (representing
> > physical or virtual machines) are not necessarily the same
> > profiles that should be used for service principals.  This is
> > why CA ACLs must be executed against the issuee principal.
> 
> 
> Certmonger uses the host credential (from the host keytab) to make
> all requests on behalf of all service principals of a given
> machine, right?
>
That's correct.

> So if that machine is compromised then so too are
> all keys/certificates issued to that machine. If I think a machine
> is more likely to become compromised, I'd want to lock down the
> Certificate Profiles available to that whole machine.
>
Protecting keys is a separate issue from the the CA being able to
answer the question "can I issue certs to principal P using profile
X?".

> Even if I
> end up using different profiles for different services on the same
> machine, I'm still forced to trust certmonger to use the right
> profile for each request.
> 
CA ACLs are stored and evaluated on the IPA server.  If Certmonger
uses the "wrong profile for a request", the worst that will happen
is CA ACL enforcement will deny the request.  I do not see how any
special trust resides in Certmonger in this scenario.

> So, even with future sub-CAs (this excites me btw), I'm just not
> sure I understand the security benefit of evaluating CA ACLs
> against the subject/issuee of the request, when (as you say)
> directory ACIs are already doing this.
> 
Directory ACIs govern which principals can request a certificate on
behalf of a subject principal.  CA ACLs govern which profile(s) are
valid for such a request.  These are quite different things, and
both are important.

(I'm glad you're excited about sub-CA support; I am too!)

> Lets look at this from another angle. Suppose I obtain a service
> keytab for my unprivileged web application (say
> HTTP/myapp01.example.com), which is needed to authenticate web
> clients via kerberos/gssapi. The app also needs x509 certificates
> for TLS, which is handled by certmonger. Given the current
> approach of CA ACLs, it would be possible for my unprivileged
> web-app (if it were to become compromised) to use its service
> keytab to request certificates from IPA directly, which is
> undesirable, but I'd have no way of stopping it.
> 
The same is true for rogue user or host credentials.  The scope is
even bigger for compromised host credentials, since a host principal
can request certificates both for itself and for any services it
manages.

> I'm even more curious about how I'd explain and justify this
> behaviour to clients. It's confusing, you know?
> 
I am open to any ideas about how to explain this more clearly.  The
best approach I can think of is to explain that CA ACLs are about
answering, "what kinds of certificate can the CA issue to subject
principal 'P'?", and emphasising that that is a very different
question from, "who can request a certificate on behalf of subject
principal 'P'?".

Thanks,
Fraser

> Cheers
> 
> > On 23 Mar 2016, at 09:48, Fraser Tweedale 
> > wrote:
> > 
> >> On Tue, Mar 22, 2016 at 10:57:37PM +1100, earsdown wrote: Hi
> >> Fraser, Martin and Alexander,
> >> 
> >> Thanks for looking into this! For what it's worth, I think for
> >> this particular use case, I'm leaning more towards Alexander
> >> when he said:
> >> 
> >>> I don't think you need to group services this way. For
> >>> managing services, and this means being able to issue
> >>> certificates/keytabs for them, we have hosts. By default a
> >>> host that a service belongs to is capable to modify
> >>> userCertificate attribute of the service already, so I would
> >>> expect it to be able to issue certificates with subject
> >>> principal corresponding to the service.
> >> 
> >>> If CAACL would follow the same logic by allowing hosts that
> >>> manage services to issue certificates with subject principals
> >>> corresponding to these services, that should be enough
> >>> because, after all, these host objects already have write
> >>> permissions and can upload whatever certificates they like to
> >>> the service objects.  -- / Alexander Bokovoy
> >> 
> >> Personally, I was very surprised when I discovered that, even
> >> though a host principal may manage a service principal, it is
> >> currently unable to request a certificate for that service
> >> principal if the service principal doesn't have specific access
> >> to the certificate profile, even though the host principal may
> >> have access to the same certificate profile. In my mind the CA
> >> ACL should be evaluated against the identity of the requestor,
> >> not the issuee. As long as the requestor is allowed to request
> >> on behalf of the issuee (achieved via the managedby attribute),
> >> then it should 

Re: [Freeipa-users] sudo with OTP

[Brad Bendy]

Just updated to the testing on F23 and sudo does work, but it prompts
for a single password and the single user password work, OTP is not
needed or prompted.

I still need OTP when I login as my user just not on sudo, is that the
correct behavior and if so can that be changed to always require OTP?

Thanks


On Wed, Mar 23, 2016 at 2:55 PM, Brad Bendy  wrote:
> Ignore what I said earlier :)
>
> The issue is when I run sudo the lookup appears to still be wanting
> OTP (even though RADIUS is the only box checked for that user), no
> matter what I enter it won't go past that first prompt, the request
> never makes it over to my RADIUS server at all. Standard logins work
> just fine but soon as you try to sudo it wants the "first factor" but
> request never make it to the RADIUS server. Im going to play around
> with some settings, but am I missing something or is there no way to
> forward the sudo request to the same RADIUS server as well?
>
> Thanks
>
>
> On Wed, Mar 23, 2016 at 2:41 PM, Brad Bendy  wrote:
>> I will upgrade a few machines and test this out, I just got done
>> making a script for RADIUS to handle OTP, I didn't see this e-mail
>> till now!
>>
>> If Password + RADIUS are turned on for the user it looks like it's
>> still doing the first factor prompt, if I don't enable the password
>> option then a LDAP (have not tested Kerberos yet) lookup will fail,
>> haven't dug into to see if the account is disabled or what is causing
>> that. Does that sound correct though? My idea was to have FreeIPA
>> proxy to RADIUS and let RADIUS to the LDAP/Kerberos+OTP and then auth
>> that way, I take it that's not going to work?
>>
>> Thanks
>>
>>
>> On Wed, Mar 23, 2016 at 12:09 AM, Lukas Slebodnik  
>> wrote:
>>> On (22/03/16 10:06), Brad Bendy wrote:
Im having some issues applying these patches with dependencies. But on
a side note, this needs to be applied to the client machines as well
the IPA server itself, correct?

>>> I pushed related sudo patches to fedora yesterday.
>>> They are in updates-testing ATM.
>>>
>>> If you want to test packages on el6 or el7
>>> Then backported version of fedora packages are available in
>>> our sssd group copr repo.
>>> https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/
>>>
>>> Please report any bugs here or to sssd-users.
>>>
>>> LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo with OTP

[Brad Bendy]

Ignore what I said earlier :)

The issue is when I run sudo the lookup appears to still be wanting
OTP (even though RADIUS is the only box checked for that user), no
matter what I enter it won't go past that first prompt, the request
never makes it over to my RADIUS server at all. Standard logins work
just fine but soon as you try to sudo it wants the "first factor" but
request never make it to the RADIUS server. Im going to play around
with some settings, but am I missing something or is there no way to
forward the sudo request to the same RADIUS server as well?

Thanks


On Wed, Mar 23, 2016 at 2:41 PM, Brad Bendy  wrote:
> I will upgrade a few machines and test this out, I just got done
> making a script for RADIUS to handle OTP, I didn't see this e-mail
> till now!
>
> If Password + RADIUS are turned on for the user it looks like it's
> still doing the first factor prompt, if I don't enable the password
> option then a LDAP (have not tested Kerberos yet) lookup will fail,
> haven't dug into to see if the account is disabled or what is causing
> that. Does that sound correct though? My idea was to have FreeIPA
> proxy to RADIUS and let RADIUS to the LDAP/Kerberos+OTP and then auth
> that way, I take it that's not going to work?
>
> Thanks
>
>
> On Wed, Mar 23, 2016 at 12:09 AM, Lukas Slebodnik  wrote:
>> On (22/03/16 10:06), Brad Bendy wrote:
>>>Im having some issues applying these patches with dependencies. But on
>>>a side note, this needs to be applied to the client machines as well
>>>the IPA server itself, correct?
>>>
>> I pushed related sudo patches to fedora yesterday.
>> They are in updates-testing ATM.
>>
>> If you want to test packages on el6 or el7
>> Then backported version of fedora packages are available in
>> our sssd group copr repo.
>> https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/
>>
>> Please report any bugs here or to sssd-users.
>>
>> LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo with OTP

[Brad Bendy]

I will upgrade a few machines and test this out, I just got done
making a script for RADIUS to handle OTP, I didn't see this e-mail
till now!

If Password + RADIUS are turned on for the user it looks like it's
still doing the first factor prompt, if I don't enable the password
option then a LDAP (have not tested Kerberos yet) lookup will fail,
haven't dug into to see if the account is disabled or what is causing
that. Does that sound correct though? My idea was to have FreeIPA
proxy to RADIUS and let RADIUS to the LDAP/Kerberos+OTP and then auth
that way, I take it that's not going to work?

Thanks


On Wed, Mar 23, 2016 at 12:09 AM, Lukas Slebodnik  wrote:
> On (22/03/16 10:06), Brad Bendy wrote:
>>Im having some issues applying these patches with dependencies. But on
>>a side note, this needs to be applied to the client machines as well
>>the IPA server itself, correct?
>>
> I pushed related sudo patches to fedora yesterday.
> They are in updates-testing ATM.
>
> If you want to test packages on el6 or el7
> Then backported version of fedora packages are available in
> our sssd group copr repo.
> https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/
>
> Please report any bugs here or to sssd-users.
>
> LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-replica-install IPA startup timing issue

[Daryl Fonseca-Holt]

Forgot to CC the ML. Sorry.

 --
 Daryl Fonseca-Holt
 IST/CNS/Unix Server Team
 University of Manitoba
 204.480.1079

On Wed, 23 Mar 2016, Daryl Fonseca-Holt wrote:


Hi Thierry,

I have not filed a support request with RedHat for two reasons. First, it 
seems that the NIS priming may not be a problem in the post 4.2.0 release. 
Second, I am able to work around the problem by modifying the code where it 
uses the number of krb5kdc daemons to start thus alleviating the crush of 64 
daemons starting. As suggested by Alexander I'm patching 
ipaserver/install/krbinstance.py.


# diff -c ipaserver/install/krbinstance.py.df 
ipaserver/install/krbinstance.py
*** ipaserver/install/krbinstance.py.df2015-06-18 07:54:49.0 
-0500

--- ipaserver/install/krbinstance.py2016-03-22 13:37:16.056210609 -0500
***
*** 355,360 
--- 355,362 

 MIN_KRB5KDC_WITH_WORKERS = "1.9"
 cpus = os.sysconf('SC_NPROCESSORS_ONLN')
+ #XXX
+ cpus = 1
 workers = False
 (stdout, stderr, rc) = ipautil.run(['klist', '-V'], 
raiseonerr=False)

 if rc == 0:


With this patch the constant in /etc/sysconfig/krb5kdc is lower. After the 
ipa-replica-install completes I will increase this manually to the original 
value.


This has allowed the building phase of the project to continue.

Thanks, Daryl

On 03/23/16 04:40, thierry bordaz wrote:

Hi Daryl,

Me again... :-)
As a follow up of this issue I would like to know if you already open a 
case to RH support ?


Also, have you identified a workaround to make ipa-replica-install 
successful or are you still suffering from this issue ?


best regards
thierry

On 03/16/2016 04:24 PM, thierry bordaz wrote:

Hello Daryl,

I can reproduce locally the slow DS startup (due to slapi-nis
priming). In fact the version I was using had not the slapi-nis
fix to differ the priming.

I failed to reproduce the intensive load on DS when krb5kdc startup.
Looking at yours logs, we can see that krb5kdc startup triggers a
set of requests during 3s up to 8s. The logs are looking like
(note the etime can go up to 2s):

[10/Mar/2016:14:20:35 -0600] conn=40 fd=87 slot=87 connection
from local to /var/run/slapd-UOFMT1.socket
[10/Mar/2016:14:20:36 -0600] conn=40 AUTOBIND dn="cn=Directory
Manager"
[10/Mar/2016:14:20:36 -0600] conn=40 op=0 BIND dn="cn=Directory
Manager" method=sasl version=3 mech=EXTERNAL
[10/Mar/2016:14:20:36 -0600] conn=40 op=0 RESULT err=0 tag=97
nentries=0 *etime=1* dn="cn=Directory Manager"
[10/Mar/2016:14:20:36 -0600] conn=40 op=1 SRCH
base="cn=UOFMT1,cn=kerberos,dc=uofmt1" scope=0
filter="(objectClass=*)" attrs=ALL
[10/Mar/2016:14:20:36 -0600] conn=40 op=1 RESULT err=0 tag=101
nentries=1 etime=0
[10/Mar/2016:14:20:36 -0600] conn=40 op=2 SRCH
base="cn=ipaConfig,cn=etc,dc=uofmt1" scope=0
filter="(objectClass=*)" attrs="ipaConfigString ipaKrbAuthzData
ipaUserAuthType"
[10/Mar/2016:14:20:36 -0600] conn=40 op=2 RESULT err=0 tag=101
nentries=1 etime=0
[10/Mar/2016:14:20:36 -0600] conn=40 op=3 SRCH base="dc=uofmt1"
scope=2 filter="(objectClass=ipaNTDomainAttrs)"
attrs="ipaNTFlatName ipaNTFallbackPrimaryGroup
ipaNTSecurityIdentifier"
[10/Mar/2016:14:20:37 -0600] conn=40 op=3 RESULT err=0 tag=101
nentries=0 *etime=1*
[10/Mar/2016:14:20:37 -0600] conn=40 op=4 SRCH
base="cn=UOFMT1,cn=kerberos,dc=uofmt1" scope=0
filter="(krbMKey=*)" attrs="krbMKey"
[10/Mar/2016:14:20:37 -0600] conn=40 op=4 RESULT err=0 tag=101
nentries=1 etime=0
[10/Mar/2016:14:20:37 -0600] conn=40 op=5 SRCH base="dc=uofmt1"
scope=2

filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=K/M@UOFMT1))"
attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias
krbUPEnabled krbPrincipalKey krbTicketPolicyReference
krbPrincipalExpiration krbPasswordExpiration
krbPwdPolicyReference krbPrincipalType krbPwdHistory
krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth
krbLastFailedAuth krbLoginFailedCount krbExtraData
krbLastAdminUnlock krbObjectReferences krbTicketFlags
krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory
ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass"
[10/Mar/2016:14:20:38 -0600] conn=40 op=5 RESULT err=0 tag=101
nentries=1 *etime=1*
[10/Mar/2016:14:20:39 -0600] conn=40 op=6 UNBIND
[10/Mar/2016:14:20:39 -0600] conn=40 op=6 fd=87 closed - U1


I think the request op=3 (SRCH base="dc=uofmt1" scope=2
filter="(objectClass=ipaNTDomainAttrs)") is slow also because of
slapi-nis. In fact it is indexed and returns 0 entry. So only
plugins can create this high etime.
An improvement in slapi-nis makes its search callback noop when
it comes from krb and I am running this improvement.

In conclusion I think both slow DS startup and KRB5 startup are
fixed in RHE

Re: [Freeipa-users] PKI Authentication Issues

[Sam James]

Yes the cert is correct.  The userCertificate field matches the output of
"certutil -L -d /etc/httpd/alias/ -n ipaCert -a" with the header and footer
removed, and the serial number matches as well albeit in decimal instead of
hex.

# ipara, people, ipaca
dn: uid=ipara,ou=people,o=ipaca
description: 2;4886718345;CN=Certificate Authority,O=DOMAIN.COM;
 CN=IPA RA, O=DOMAIN.COM
userCertificate:: 
userstate: 1
uid: ipara
sn: ipara
usertype: agentType
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: cmsuser
cn: ipara


On Wed, Mar 23, 2016 at 4:31 PM, Petr Vobornik  wrote:

> On 03/23/2016 03:50 PM, Sam James wrote:
>
>> Hello everyone,
>>
>> I've been banging my head against the wall for a few days now trying to
>> resolve
>> an issue with PKI and I'm hoping I might get some help.  First some
>> context.
>>
>> About a week ago I was alerted that all of our replicas were offline due
>> to
>> pki-tomcatd not starting.  Futher investigation determined that all of
>> the pki
>> certs had expired two days earlier.  I turned back time and successfully
>> updated
>> the certs and certmonger updated the rest of the replicas.
>>
>> Now I'm seeing the following symptoms:
>> 1.  Searching certificates via the web UI will display certificate info.
>> 2.  Attemping to view certificate details results in an "IPA Error 4301:
>> CertificateOperationError" the exception being "Invalid Credential.".
>> 3.  Issuing the ipa cert-show command results in the same "Invalid
>> Credential."
>> exception.
>> 4.  PKI debug log shows:  SignedAuditEventFactory: create()
>>
>> message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA
>> RA,O=DOMAIN.COM ] authentication failure
>> 5.  PKI system log shows: Cannot authenticate agent with certificate
>> Serial
>> 0x123456789 Subject DN CN=IPA RA,O=DOMAIN.COM .
>> Error: User
>> not found.
>>
>
> PKI has some build-in accounts which uses certificates for authentication.
> It matches a user by a certificate. The error above means that it cannot
> find any user for cert with serial no 0x123456789
>
> So the possible cause is the user you checked
> (uid=ipara,ou=people,o=ipaca) has still old cert. I.e. you've updated
> description, but is the cert correct?
>
>
>
>> In trolling this list I've done the following things troubleshooting:
>>
>> 1.  Ensured the certs being monitored by certmonger are correct.
>> 2.  Ensured the certs in the http and pki-tomcat NSS databases are as
>> expected.
>> 3.  Ensured the uid=ipara,ou=people,o=ipaca object has the correct
>> description
>> and cert (it had the wrong serialnumber in the description but i've
>> updated that).
>> 4.  Ensured the CS.cfg has the correct certs (it did).
>>
>> Any suggestions or assistance would be apprecitated.
>>
>> Thanks!
>> Sam
>>
>> --
> Petr Vobornik
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Lock screen when Smart Card is removed.

[Michael Rainey (Contractor)]

Hi Sumit,

I've trying to download the rpm via the Koji client and have been unable 
to locate package.  Are there any extra steps I need to complete before 
I can find the package, such as, create an account in Fedora Build 
System.  Performing a general search for SSSD only returns a list of 
packages from Fedora Projects and nothing from the EL repo.


Thanks,

*Michael Rainey*
NRL 7320
Computer Support Group
Building 1009, Room C156
Stennis Space Center, MS 39529
On 03/22/2016 07:25 AM, Sumit Bose wrote:

On Fri, Mar 18, 2016 at 10:53:08AM -0500, Michael Rainey (Contractor) wrote:

Hi Sumit,

It has been a week and I am following up with you on the lock screen issue.
Have you had any progress?  If so, I am hoping implementing the fix will be
quick and easy.

Thank you for your patience. Please find a test build for RHEL/CentOS
7.2 at https://koji.fedoraproject.org/koji/taskinfo?taskID=13412048 .

Besides the updated version of SSSD you should replace
/etc/pam.d/smartcard-auth with

 /etc/pam.d/smartcard-auth =
authrequired  pam_env.so
authsufficientpam_sss.so allow_missing_name
authrequired  pam_deny.so

account required  pam_unix.so
account sufficientpam_localuser.so
account sufficientpam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required  pam_permit.so


session optional  pam_keyinit.so revoke
session required  pam_limits.so
-session optional  pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet 
use_uid
session required  pam_unix.so
session optional  pam_sss.so
===

and /etc/dconf/db/distro.d/10-authconfig

= /etc/dconf/db/distro.d/10-authconfig =
[org/gnome/login-screen]
enable-fingerprint-authentication=false

[org/gnome/settings-daemon/peripherals/smartcard]
removal-action='lock-screen'
===

and /etc/dconf/db/distro.d/locks/10-authconfig-locks

== /etc/dconf/db/distro.d/locks/10-authconfig-locks ===
/org/gnome/login-screen/enable-fingerprint-authentication
/org/gnome/settings-daemon/peripherals/smartcard
===

and call 'dconf update' to get the new setting loaded. Finally it might
be a good idea to restart gdm to make sure the new setting and PAM
configuration is really active although I would expect that gdm is able
to pick up the changes at run-time.

Any feedback, good or bad, is welcome.

bye,
Sumit


Thanks,

*Michael Rainey*

On 03/11/2016 02:32 AM, Sumit Bose wrote:

On Thu, Mar 10, 2016 at 01:36:15PM -0600, Michael Rainey (Contractor) wrote:

Greetings,

I have been adding systems to my new domain and utilizing the smart card
login feature.  To date the smart card login feature is working very well.
However, my group has been trying to implement locking the screen when the
smart card is removed, but have not been successful at making it work.  Does
anyone have any suggestions as to what it would take to enable locking the
screen when the smart card is removed.

This requires a better integration with gdm which is currently WIP
(https://fedorahosted.org/sssd/ticket/2941). If you don't mind please
ping me in about a week about this again, then I might have done some
more testing.

bye,
Sumit


Thank you in advance.
--
*Michael Rainey*
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Can't Search For Users

[Garrett Hyde]

I'm currently running ipa-server version 4.2.0, release 15.el7_2.6 on a
RHEL 7.2 server.

When a user **not** in the "admins" group tries searching for a user, they
receive "No entries." In the WebUI, this happens on the "Active users" page
or when trying to add a user to a group, role, etc. It also happens when a
user uses the CLI (e.g., `ipa user-find ...`). I've tried adding a user to
all of the available roles listed under "Role Based Access Control", but
they still can't search for users.

Currently, only users in the "admins" group can search for users. Is there
a permission or privilege I'm missing? How can I grant users the ability to
search for other users?

-- Garrett Hyde
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] PKI Authentication Issues

[Petr Vobornik]

On 03/23/2016 03:50 PM, Sam James wrote:

Hello everyone,

I've been banging my head against the wall for a few days now trying to resolve
an issue with PKI and I'm hoping I might get some help.  First some context.

About a week ago I was alerted that all of our replicas were offline due to
pki-tomcatd not starting.  Futher investigation determined that all of the pki
certs had expired two days earlier.  I turned back time and successfully updated
the certs and certmonger updated the rest of the replicas.

Now I'm seeing the following symptoms:
1.  Searching certificates via the web UI will display certificate info.
2.  Attemping to view certificate details results in an "IPA Error 4301:
CertificateOperationError" the exception being "Invalid Credential.".
3.  Issuing the ipa cert-show command results in the same "Invalid Credential."
exception.
4.  PKI debug log shows:  SignedAuditEventFactory: create()
message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA
RA,O=DOMAIN.COM ] authentication failure
5.  PKI system log shows: Cannot authenticate agent with certificate Serial
0x123456789 Subject DN CN=IPA RA,O=DOMAIN.COM . Error: User
not found.


PKI has some build-in accounts which uses certificates for 
authentication. It matches a user by a certificate. The error above 
means that it cannot find any user for cert with serial no 0x123456789


So the possible cause is the user you checked 
(uid=ipara,ou=people,o=ipaca) has still old cert. I.e. you've updated 
description, but is the cert correct?




In trolling this list I've done the following things troubleshooting:

1.  Ensured the certs being monitored by certmonger are correct.
2.  Ensured the certs in the http and pki-tomcat NSS databases are as expected.
3.  Ensured the uid=ipara,ou=people,o=ipaca object has the correct description
and cert (it had the wrong serialnumber in the description but i've updated 
that).
4.  Ensured the CS.cfg has the correct certs (it did).

Any suggestions or assistance would be apprecitated.

Thanks!
Sam


--
Petr Vobornik

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] PKI Authentication Issues

[Sam James]

Hello everyone,

I've been banging my head against the wall for a few days now trying to
resolve an issue with PKI and I'm hoping I might get some help.  First some
context.

About a week ago I was alerted that all of our replicas were offline due to
pki-tomcatd not starting.  Futher investigation determined that all of the
pki certs had expired two days earlier.  I turned back time and
successfully updated the certs and certmonger updated the rest of the
replicas.

Now I'm seeing the following symptoms:
1.  Searching certificates via the web UI will display certificate info.
2.  Attemping to view certificate details results in an "IPA Error 4301:
CertificateOperationError" the exception being "Invalid Credential.".
3.  Issuing the ipa cert-show command results in the same "Invalid
Credential." exception.
4.  PKI debug log shows:  SignedAuditEventFactory: create()
message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA
RA,O=DOMAIN.COM] authentication failure
5.  PKI system log shows: Cannot authenticate agent with certificate Serial
0x123456789 Subject DN CN=IPA RA,O=DOMAIN.COM. Error: User not found.


In trolling this list I've done the following things troubleshooting:

1.  Ensured the certs being monitored by certmonger are correct.
2.  Ensured the certs in the http and pki-tomcat NSS databases are as
expected.
3.  Ensured the uid=ipara,ou=people,o=ipaca object has the correct
description and cert (it had the wrong serialnumber in the description but
i've updated that).
4.  Ensured the CS.cfg has the correct certs (it did).

Any suggestions or assistance would be apprecitated.

Thanks!
Sam
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certificate profiles and CA ACLs for service principals

[a . fedora]

Some excellent points, and thank you for being open to having the conversation 
- I know you don't have to, and it is appreciated.

> Profiles which are allowed for a host principal (representing
> physical or virtual machines) are not necessarily the same profiles
> that should be used for service principals.  This is why CA ACLs
> must be executed against the issuee principal.


Certmonger uses the host credential (from the host keytab) to make all requests 
on behalf of all service principals of a given machine, right? So if that 
machine is compromised then so too are all keys/certificates issued to that 
machine. If I think a machine is more likely to become compromised, I'd want to 
lock down the Certificate Profiles available to that whole machine. Even if I 
end up using different profiles for different services on the same machine, I'm 
still forced to trust certmonger to use the right profile for each request.

So, even with future sub-CAs (this excites me btw), I'm just not sure I 
understand the security benefit of evaluating CA ACLs against the 
subject/issuee of the request, when (as you say) directory ACIs are already 
doing this.

Lets look at this from another angle. Suppose I obtain a service keytab for my 
unprivileged web application (say HTTP/myapp01.example.com), which is needed to 
authenticate web clients via kerberos/gssapi. The app also needs x509 
certificates for TLS, which is handled by certmonger. Given the current 
approach of CA ACLs, it would be possible for my unprivileged web-app (if it 
were to become compromised) to use its service keytab to request certificates 
from IPA directly, which is undesirable, but I'd have no way of stopping it.

I'm even more curious about how I'd explain and justify this behaviour to 
clients. It's confusing, you know?

Cheers

> On 23 Mar 2016, at 09:48, Fraser Tweedale  wrote:
> 
>> On Tue, Mar 22, 2016 at 10:57:37PM +1100, earsdown wrote:
>> Hi Fraser, Martin and Alexander,
>> 
>> Thanks for looking into this! For what it's worth, I think for this
>> particular use case, I'm leaning more towards Alexander when he said:
>> 
>>> I don't think you need to group services this way. For managing
>>> services, and this means being able to issue certificates/keytabs for
>>> them, we have hosts. By default a host that a service belongs to is
>>> capable to modify userCertificate attribute of the service already, so I
>>> would expect it to be able to issue certificates with subject principal
>>> corresponding to the service.
>> 
>>> If CAACL would follow the same logic by allowing hosts that manage
>>> services to issue certificates with subject principals corresponding to
>>> these services, that should be enough because, after all, these host
>>> objects already have write permissions and can upload whatever
>>> certificates they like to the service objects.
>>> --
>>> / Alexander Bokovoy
>> 
>> Personally, I was very surprised when I discovered that, even though a host
>> principal may manage a service principal, it is currently unable to request
>> a certificate for that service principal if the service principal doesn't
>> have specific access to the certificate profile, even though the host
>> principal may have access to the same certificate profile. In my mind the CA
>> ACL should be evaluated against the identity of the requestor, not the
>> issuee. As long as the requestor is allowed to request on behalf of the
>> issuee (achieved via the managedby attribute), then it should work. Now, if
>> I used the credentials of the service principal directly (say, with a
>> service keytab) to make the request (supposing the service principal wasn't
>> listed in the CA ACL), then denying the request would be the expected
>> behaviour (imo of course).
>> 
>> Okay, so even though Alexander's suggestion might be more intuitive,
>> implementing service groups might be more feasible from a technical
>> standpoint, and I'm fairly sure this use case would also be solved by
>> implementing service groups. But, it would be painful without automember
>> regexp rules, so please don't forget this :D
>> 
>> Cheers!
> The CA ACLs solve a different part of the authorisation puzzle for
> certificates: what profiles (or, in the future, (sub-)CAs) may be
> used to issue certs to a given subject is a different question from
> which entities can request certificates on behalf of the subject.
> Profiles which are allowed for a host principal (representing
> physical or virtual machines) are not necessarily the same profiles
> that should be used for service principals.  This is why CA ACLs
> must be executed against the issuee principal.
> 
> It is best to implement service groups then support them in CA ACLs.
> 
> Final note: directory ACIs allow hosts to request certificates for
> services they manage.  The overall authorisation for cert issuance
> depends on *both* the directory ACIs and CA ACLs.
> 
> Cheers,
> Fraser
> 
>>> On 2016-03-22 20:50, Fraser Tweedale wrote

Re: [Freeipa-users] Samba Integration with AD Trust

[Baird, Josh]

Actually - it looks like this is working.  I think I had something cached on 
the Windows client that I was testing from.

Thanks for the help.

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Baird, Josh
> Sent: Wednesday, March 23, 2016 9:11 AM
> To: 'freeipa-users@redhat.com'
> Subject: Re: [Freeipa-users] Samba Integration with AD Trust
> 
> Justin,
> 
> @ad_admins is an AD group, correct (not a POSIX group), correct?  I still
> cannot get this working.  Home directory shares are working fine.
> 
> (apologies for the broken threading - I don't think I received your message
> for some reason)
> 
> Thanks,
> 
> Josh
> 
> > -Original Message-
> From: Justin Stephenson 
> To: "Baird, Josh" ,   "'freeipa-users redhat com'"
> 
> Subject: Re: [Freeipa-users] Samba Integration with AD Trust
> Date: Tue, 22 Mar 2016 15:09:50 -0400
> I have used the following successfully in the past:
> 
> [shared]
> path = /home/shared
> valid users = @ad_admins
> read only = No
> guest ok = Yes
> 
> This requires the sssd-libwbclient rpm which may be installed already as a
> dependency.
> 
> -Justin
> 
> > -Original Message-
> > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> > boun...@redhat.com] On Behalf Of Baird, Josh
> > Sent: Tuesday, March 22, 2016 2:50 PM
> > To: 'freeipa-users@redhat.com'
> > Subject: [Freeipa-users] Samba Integration with AD Trust
> >
> > Hi all,
> >
> > I'm attempting to integrate Samba 4.2.3 with IPA 4.2 (RHEL7).  I have
> > a kerberos trust established between IPA and AD.  I have followed the
> > instructions on the wiki [1], but had some questions and problems
> > specifically related to share permissions:
> >
> > I'm having trouble with shares where I need to grant access to a
> > specific AD user/group.  I have tried this and other variations with no
> success:
> >
> > [shared]
> > path = /home/shared
> > writable = yes
> > browsable = yes
> > valid users = testsa...@ad.domain.lan
> >
> > I have also tried:
> >
> > valid users = ad\testsamba
> > vaild users= @ad\testsamba
> > valid users= @testsa...@ad.domain.lan
> >
> >
> > What is the proper way to allow specific AD groups access to the Samba
> > share?  I also tried nesting an external group in a POSIX group with
> > no success.  Should I be using something other than 'valid users'?
> >
> >  [1]
> >
> http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_Wi
> > th_IPA
> >
> > Thanks,
> >
> > Josh
> >
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
> 
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Samba Integration with AD Trust

[Baird, Josh]

Justin,

@ad_admins is an AD group, correct (not a POSIX group), correct?  I still 
cannot get this working.  Home directory shares are working fine.

(apologies for the broken threading - I don't think I received your message for 
some reason)

Thanks,

Josh

> -Original Message-
From: Justin Stephenson 
To: "Baird, Josh" , "'freeipa-users redhat com'" 

Subject: Re: [Freeipa-users] Samba Integration with AD Trust
Date: Tue, 22 Mar 2016 15:09:50 -0400
I have used the following successfully in the past:

[shared]
path = /home/shared
valid users = @ad_admins
read only = No
guest ok = Yes

This requires the sssd-libwbclient rpm which may be installed already as a 
dependency.

-Justin

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Baird, Josh
> Sent: Tuesday, March 22, 2016 2:50 PM
> To: 'freeipa-users@redhat.com'
> Subject: [Freeipa-users] Samba Integration with AD Trust
> 
> Hi all,
> 
> I'm attempting to integrate Samba 4.2.3 with IPA 4.2 (RHEL7).  I have a
> kerberos trust established between IPA and AD.  I have followed the
> instructions on the wiki [1], but had some questions and problems specifically
> related to share permissions:
> 
> I'm having trouble with shares where I need to grant access to a specific AD
> user/group.  I have tried this and other variations with no success:
> 
> [shared]
>   path = /home/shared
>   writable = yes
>   browsable = yes
>   valid users = testsa...@ad.domain.lan
> 
> I have also tried:
> 
>   valid users = ad\testsamba
>   vaild users= @ad\testsamba
>   valid users= @testsa...@ad.domain.lan
> 
> 
> What is the proper way to allow specific AD groups access to the Samba
> share?  I also tried nesting an external group in a POSIX group with no
> success.  Should I be using something other than 'valid users'?
> 
>  [1]
> http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_Wi
> th_IPA
> 
> Thanks,
> 
> Josh
> 
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Problem migrating from openldap using groups in a group

[Alexander Bokovoy]

On Wed, 23 Mar 2016, Sotiris Tsimbonis wrote:

Hi all,

I'm trying to migrate into freeipa some users and groups from an old
ldap server I've inherited. But migrate-ds fails to import groups inside
usergroups, is believes they are users and imports them wrongly..

trying to migrate with command:
ipa migrate-ds --bind-dn="cn=root,dc=staff,dc=forthnet" \
--base-dn="ou=Forthnet,dc=staff,dc=forthnet" \
--user-container=ou=users \
--group-container=ou=groups \
--group-objectclass=posixgroup \
--schema=RFC2307 \
ldap://devldap01.forthnet.prv:389

(version is ipa-server-4.2.0-15.0.1.el7.centos.6.x86_64)

here is part of the ldif from devldap01
---
dn: cn=security-tech,ou=groups,ou=Forthnet,dc=staff,dc=forthnet
cn: security-tech
objectClass: posixGroup
structuralObjectClass: posixGroup
entryUUID: 5723476e-bad4-102c-8fe3-0bb2ba42f62f
creatorsName: cn=root,dc=staff,dc=forthnet
createTimestamp: 20080520162000Z
memberUid: dimitria
gidNumber: 1730
entryCSN: 20100107135233Z#00#00#00
modifiersName: cn=root,dc=staff,dc=forthnet
modifyTimestamp: 20100107135233Z

dn: cn=abusewg,ou=groups,ou=Forthnet,dc=staff,dc=forthnet
cn: abusewg
objectClass: posixGroup
structuralObjectClass: posixGroup
entryUUID: f90113dc-bad3-102c-8d13-0bb2ba42f62f
creatorsName: cn=root,dc=staff,dc=forthnet
createTimestamp: 20080520161722Z
memberUid: ccha
memberUid: dzer
memberUid: gmouz
memberUid: isek
memberUid: kavaklis
memberUid: nasl
memberUid: pmav
memberUid: stsimb
memberUid: cn=security-tech,ou=groups,ou=Forthnet,dc=staff,dc=forthnet
gidNumber: 1010
entryCSN: 20151203143609Z#00#00#00
modifiersName: cn=root,dc=staff,dc=forthnet
modifyTimestamp: 20151203143609Z


migrate-ds completes with no failures.

The usergroup "security-tech" is correctly imported in freeipa, it
contains user "dimitria" who is also imported correctly.

But usergroup "abusewg" contains 9 users and reports an error
"user not found:
cn=security-tech,ou=groups,ou=Forthnet,dc=staff,dc=forthnet".

I would expect it to migrate the "security-tech" as a usergroup, not as
a user.

migrate-ds did everything right because memberUid attribute in RFC2307
schema is the uid of a user, not a group. RFC2307 schema does not allow
to have nested groups.

memberUid syntax is 
( nisSchema.1.12 NAME 'memberUid'

 EQUALITY caseExactIA5Match
 SUBSTRINGS caseExactIA5SubstringsMatch
 SYNTAX 'IA5String' )

i.e. this is IA5String, not a DN.

This doesn't help you much because your LDAP server use was already
violating RFC2307 so I'd suggest to fix these violations and group
membership manually.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Problem migrating from openldap using groups in a group

[Sotiris Tsimbonis]

Hi all,

I'm trying to migrate into freeipa some users and groups from an old
ldap server I've inherited. But migrate-ds fails to import groups inside
usergroups, is believes they are users and imports them wrongly..

trying to migrate with command:
ipa migrate-ds --bind-dn="cn=root,dc=staff,dc=forthnet" \
 --base-dn="ou=Forthnet,dc=staff,dc=forthnet" \
 --user-container=ou=users \
 --group-container=ou=groups \
 --group-objectclass=posixgroup \
 --schema=RFC2307 \
 ldap://devldap01.forthnet.prv:389

(version is ipa-server-4.2.0-15.0.1.el7.centos.6.x86_64)

here is part of the ldif from devldap01
---
dn: cn=security-tech,ou=groups,ou=Forthnet,dc=staff,dc=forthnet
cn: security-tech
objectClass: posixGroup
structuralObjectClass: posixGroup
entryUUID: 5723476e-bad4-102c-8fe3-0bb2ba42f62f
creatorsName: cn=root,dc=staff,dc=forthnet
createTimestamp: 20080520162000Z
memberUid: dimitria
gidNumber: 1730
entryCSN: 20100107135233Z#00#00#00
modifiersName: cn=root,dc=staff,dc=forthnet
modifyTimestamp: 20100107135233Z

dn: cn=abusewg,ou=groups,ou=Forthnet,dc=staff,dc=forthnet
cn: abusewg
objectClass: posixGroup
structuralObjectClass: posixGroup
entryUUID: f90113dc-bad3-102c-8d13-0bb2ba42f62f
creatorsName: cn=root,dc=staff,dc=forthnet
createTimestamp: 20080520161722Z
memberUid: ccha
memberUid: dzer
memberUid: gmouz
memberUid: isek
memberUid: kavaklis
memberUid: nasl
memberUid: pmav
memberUid: stsimb
memberUid: cn=security-tech,ou=groups,ou=Forthnet,dc=staff,dc=forthnet
gidNumber: 1010
entryCSN: 20151203143609Z#00#00#00
modifiersName: cn=root,dc=staff,dc=forthnet
modifyTimestamp: 20151203143609Z


migrate-ds completes with no failures.

The usergroup "security-tech" is correctly imported in freeipa, it
contains user "dimitria" who is also imported correctly.

But usergroup "abusewg" contains 9 users and reports an error
"user not found:
cn=security-tech,ou=groups,ou=Forthnet,dc=staff,dc=forthnet".

I would expect it to migrate the "security-tech" as a usergroup, not as
a user.

Any suggestions please?

Thanks,
Sot.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Tracking Login Times

[Martin Kosek]

On 03/21/2016 06:56 PM, Rob Crittenden wrote:
> Bob wrote:
>> If each IPA server tracks time of last auth independently, then one ipa
>> server might disable an inactive account. But that account might be
>> active on another servers. In a fail over case where the server that
>> that account normally uses is down, the user would not have a usable
>> account.
>>
>> Is it possible to use the account policy plugin?  Or is there a way to
>> track time of last auth that is replicated.  I need to have accounts
>> that have been inactive for 90 days automatically disabled.
> 
> You can't use the account policy plugin but it isn't aware of Kerberos so it
> would miss potentially a lot of authentications.
> 
> You could modify replication agreements to not ignore this attribute but you
> potentially create a replication "storm", particularly early morning when
> everyone logs in at the same time.
> 
> In any case IPA password policy doesn't currently handle inactivity. There is 
> a
> ticket open: https://fedorahosted.org/freeipa/ticket/4975 (with a potential
> short-term workaround).

JFTR, this is the ticket with failed login replication RFE:
https://fedorahosted.org/freeipa/ticket/3700

Martin

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Error in IPA webinterface then DNS name contains \032 ()

[Petr Spacek]

On 23.3.2016 10:50, Troels Hansen wrote:
>  
>>
>> # LIFX Bulb, casalogic.lan, dns, casalogic.lan
>> dn: idnsName=LIFX Bulb,idnsname=casalogic.lan,cn=dns,dc=casalogic,dc=lan
>> dNSTTL: 1800
>> tXTRecord: "009143ca16c9890339c7ec33825e0da5ce"
>> aRecord: 192.168.20.252
>> objectClass: idnsRecord
>> objectClass: top
>> idnsName: LIFX Bulb
> 
> Which actually starts to make sence.
> 
> # ipa dnsrecord-show casalogic.lan. 'LIFX Bulb'
> ipa: ERROR: LIFX\032Bulb: DNS resource record not found
> 
> So.   dhcp inserts the DNS record in LDAP with space, and IPA converts 
>  to \032 on querying.

Oh yes, this problem is caused by
https://fedorahosted.org/freeipa/ticket/3972
aka
https://fedorahosted.org/bind-dyndb-ldap/ticket/12
aka
https://fedorahosted.org/389/ticket/47564

FreeIPA is using string manipulations for DNS data but DNS data are generally
not strings, so weird things happen (sometimes).


Did you find a way to modify the record using CLI? (e.g. using space instead
of \032)?

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Error in IPA webinterface then DNS name contains \032 ()

[Troels Hansen]

 
> 
> # LIFX Bulb, casalogic.lan, dns, casalogic.lan
> dn: idnsName=LIFX Bulb,idnsname=casalogic.lan,cn=dns,dc=casalogic,dc=lan
> dNSTTL: 1800
> tXTRecord: "009143ca16c9890339c7ec33825e0da5ce"
> aRecord: 192.168.20.252
> objectClass: idnsRecord
> objectClass: top
> idnsName: LIFX Bulb

Which actually starts to make sence.

# ipa dnsrecord-show casalogic.lan. 'LIFX Bulb'
ipa: ERROR: LIFX\032Bulb: DNS resource record not found

So.   dhcp inserts the DNS record in LDAP with space, and IPA converts 
 to \032 on querying.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Error in IPA webinterface then DNS name contains \032 ()

[Troels Hansen]

- On Mar 23, 2016, at 10:37 AM, Petr Spacek pspa...@redhat.com wrote:

> 
> Interesting, I'm curious how the data in LDAP look like.
> 
> Please run ldapsearch command similar to this:
> 
> $ ldapsearch -Y GSSAPI -b 'cn=dns,dc=example,dc=com' '(idnsName=*LIFX*)'
> 


# LIFX Bulb, casalogic.lan, dns, casalogic.lan
dn: idnsName=LIFX Bulb,idnsname=casalogic.lan,cn=dns,dc=casalogic,dc=lan
dNSTTL: 1800
tXTRecord: "009143ca16c9890339c7ec33825e0da5ce"
aRecord: 192.168.20.252
objectClass: idnsRecord
objectClass: top
idnsName: LIFX Bulb

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Error in IPA webinterface then DNS name contains \032 ()

[Petr Spacek]

On 22.3.2016 13:04, Troels Hansen wrote:
> - On Mar 22, 2016, at 12:34 PM, Petr Spacek pspa...@redhat.com wrote:
> 
>>
>> Have you tried
>> # ipa dnsrecord-show casalogic.lan. 'LIFX\032Bulb'
>> ?
>>
>> I suspect that Bash is playing escaping game with you.
>>
> 
> Same result..
> 
> ipa dnsrecord-show casalogic.lan. 'LIFX\032Bulb'
> ipa: ERROR: LIFX\032Bulb: DNS resource record not found

Interesting, I'm curious how the data in LDAP look like.

Please run ldapsearch command similar to this:

$ ldapsearch -Y GSSAPI -b 'cn=dns,dc=example,dc=com' '(idnsName=*LIFX*)'

Do not forget to change 'dc=example,dc=com' to match your realm name.

Thank you.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Removing the requirement to add domain to users login

[Sumit Bose]

On Wed, Mar 23, 2016 at 01:44:13AM +, Redmond, Stacy wrote:
> I have been tasked with setting up an IPA AD trust.  I have my ipa server 
> setup, the trust is setup, and appears to be working for the most part.  I 
> have two problems.  I would like for users to login with userid only.  Right 
> now I can only login using userid@ad_domain   I am hoping there is some way 
> to just have it search that domain as well as the default ipa domain
> 
> I will add my other problem, but am willing to send a second email to the 
> group if needed.  When I login to my linux client and type id, I see lots of 
> groups but they don't all match the member of list I pull using an ldap 
> search of AD.

This is expected because the list in the user entry is not complete.
E.g. it is possible to created nested groups in AD and the memberships
due to group nesting are not see in the LDAP entry. Cross-domain group
membership are not covered here as well.

HTH

bye,
Sumit

> 
> IPA Server:  RHEL 7.2  ipa 4.2
> Client:  RHEL 7.2

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo with OTP

[Lukas Slebodnik]

On (22/03/16 10:06), Brad Bendy wrote:
>Im having some issues applying these patches with dependencies. But on
>a side note, this needs to be applied to the client machines as well
>the IPA server itself, correct?
>
I pushed related sudo patches to fedora yesterday.
They are in updates-testing ATM.

If you want to test packages on el6 or el7
Then backported version of fedora packages are available in
our sssd group copr repo.
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/

Please report any bugs here or to sssd-users.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project