On 06/04/2015 04:33 PM, Rob Crittenden wrote:
Thomas Sailer wrote:
I have now managed to upgrade the replica as well.

I stumbled over a few additional problems:

1) whenever a user becomes member of a group with +nsuniqueid= in its
name, the user can no longer login. The reason is that ldb_dn_validate
doesn't like the + character, thus returns false, which causes
get_ipa_groupname to return EINVAL, which causes the loop in
hbac_eval_user_element to abort and return an error.

This seems to be quite draconian. Does it have to be like this? If so it
would be nice if a clearer error message would be left somewhere more
obvious than sssd -d 0xffff...

An entry with nsuniqueid is a replication conflict entry. You want to resolve this.

See https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html

Yes I know, and I have already fixed that.

The question is is it justified if the presence of such a group breaks login. If yes, shouldn't there be a more obvious error message than ssh telling you that login failed for UNKNOWN reasons...

If login would still work, it would buy you time for fixing the problem. The way it is now, you have people filling your office complaining login doesn't work anymore while you frantically try to figure out why.

My biggest wish for IPA is for it to become more robust. It consists of many software components with complex interdependencies, so some fragility is to be expected. But still, it would be nice if it was as robust as possible and if it fails that it fails in more obvious ways...



2) I cannot change ssh keys, neither in the web gui nor on the cli.

# ipa -vv user-mod myuserid --sshpubkey= --all
ipa: INFO: trying https://xxxxxserver.xxxxx.com/ipa/json
ipa: INFO: Request: {
     "id": 0,
     "method": "ping",
     "params": [
         [],
         {}
     ]
}
ipa: INFO: Response: {
     "error": null,
     "id": 0,
     "principal": "ad...@xxxxx.com",
     "result": {
         "messages": [
             {
                 "code": 13001,
                 "message": "API Version number was not sent, forward
compatibility not guaranteed. Assuming server's API version, 2.114",
                 "name": "VersionMissing",
                 "type": "warning"
             }
         ],
         "summary": "IPA server version 4.1.4. API version 2.114"
     },
     "version": "4.1.4"
}
ipa: INFO: Forwarding 'user_mod' to json server
'https://xxxxxserver.xxxxx.com/ipa/json'
ipa: INFO: Request: {
     "id": 0,
     "method": "user_mod",
     "params": [
         [
             "t.sailer"
         ],
         {
             "all": true,
             "ipasshpubkey": null,
             "no_members": false,
             "random": false,
             "raw": false,
             "rights": false,
             "version": "2.114"
         }
     ]
}
ipa: INFO: Response: {
     "error": {
         "code": 4203,
         "message": "Type or value exists: ",
         "name": "DatabaseError"
     },
     "id": 0,
     "principal": "ad...@xxxxx.com",
     "result": null,
     "version": "4.1.4"
}
ipa: ERROR: Type or value exists:

I cannot find any more information in /var/log/httpd/error_log. But I
can change the SSH keys directly talking to slapd...

Hmm, curious. What is the current state of the entry? The 389-ds access log might have more details (though I'm stretching here).

[04/Jun/2015:17:43:21 +0200] conn=3391 fd=70 slot=70 connection from a.b.c.d to a.b.c.d [04/Jun/2015:17:43:21 +0200] conn=3391 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [04/Jun/2015:17:43:21 +0200] conn=3391 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [04/Jun/2015:17:43:21 +0200] conn=3391 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [04/Jun/2015:17:43:21 +0200] conn=3391 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [04/Jun/2015:17:43:21 +0200] conn=3391 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [04/Jun/2015:17:43:21 +0200] conn=3391 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=t.sailer,cn=users,cn=accounts,dc=xxxxx,dc=com" [04/Jun/2015:17:43:21 +0200] conn=3391 op=3 SRCH base="cn=ipaconfig,cn=etc,dc=xxxxx,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [04/Jun/2015:17:43:21 +0200] conn=3391 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [04/Jun/2015:17:43:21 +0200] conn=3391 op=4 SRCH base="uid=t.sailer,cn=users,cn=accounts,dc=xxxxx,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass" [04/Jun/2015:17:43:21 +0200] conn=3391 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [04/Jun/2015:17:43:21 +0200] conn=3391 op=5 SRCH base="uid=t.sailer,cn=users,cn=accounts,dc=xxxxx,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass ipaSshPubKey" [04/Jun/2015:17:43:21 +0200] conn=3391 op=5 RESULT err=0 tag=101 nentries=1 etime=0 [04/Jun/2015:17:43:21 +0200] conn=3391 op=6 MOD dn="uid=t.sailer,cn=users,cn=accounts,dc=xxxxx,dc=com" [04/Jun/2015:17:43:22 +0200] conn=3391 op=6 RESULT err=20 tag=103 nentries=0 etime=1 csn=557072af000100040000
[04/Jun/2015:17:43:22 +0200] conn=3391 op=7 UNBIND
[04/Jun/2015:17:43:22 +0200] conn=3391 op=7 fd=70 closed - U1

Thanks!
Thomas

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

Reply via email to