Hi,
In order to diagnose the DuplicateEntry issue, you can have a look at 389ds
log files in /var/log/dirsrv/slapd-<DOMAIN>. The *access* file contains the
access log and you should see an ADD operation with the dn of the user
you're trying to create. For instance, when I create a new user with *ipa
user-add mynewuser --first mynew --last user*:
[08/Mar/2022:07:30:13.165989458 +0000] conn=4080 op=5 ADD dn="
*uid=mynewuser*,cn=users,cn=accounts,dc=ipa,dc=test"
Once you have located the line, note the conn=xx number as well as the
op=yy number and look for the result of this operation, with the same conn=
and op= values:
[08/Mar/2022:07:30:13.203893370 +0000] *conn=4080 op=5 RESULT* err=0
tag=105 nentries=0 wtime=0.000234620 optime=0.037910373 etime=0.038138603
In my case the RESULT was successful (err=0) but in your case you will see
a different value, likely err=68. The result codes are described in RFC2251
<
https://datatracker.ietf.org/doc/html/rfc2251#section-4.1.10>.
In case of error, you can also check the content of the error log in
*/var/log/dirsrv/slapd-<DOMAIN>/errors*. Look for any message at the same
timestamp, there may be more information here.
If the log file doesn't contain enough details, there are also additional
steps that can help:
- increase the error log level as described in
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
- enable the audit log as described in
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
With the audit log enabled you will be able to see the whole entry that
you're trying to add and may spot errors. The audit log is located in
*/var/log/dirsrv/slapd-<DOMAIN>/audit*. For instance when I add *mynewuser*,
the audit log contains 2 operations, one for the user entry creation, and
one for the addition of the new user to the group *ipausers*:
time: 20220308073013
dn: uid=mynewuser,cn=users,cn=accounts,dc=ipa,dc=test
result: 0
changetype: add
givenName: mynew
sn: user
uid: mynewuser
cn: mynew user
displayName: mynew user
initials: mu
gecos: mynew user
krbPrincipalName: mynewuser(a)IPA.TEST
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys
uidNumber: -1
loginShell: /bin/sh
homeDirectory: /home/mynewuser
gidNumber: -1
mail: mynewuser(a)ipa.test
krbCanonicalName: mynewuser(a)IPA.TEST
creatorsName: uid=admin,cn=users,cn=accounts,dc=ipa,dc=test
modifiersName: uid=admin,cn=users,cn=accounts,dc=ipa,dc=test
createTimestamp: 20220308073013Z
modifyTimestamp: 20220308073013Z
ipaUniqueID: 979c8c9c-9eb1-11ec-9edd-fa163eaf69aa
time: 20220308073013
dn: cn=ipausers,cn=groups,cn=accounts,dc=ipa,dc=test
result: 0
changetype: modify
add: member
member: uid=mynewuser,cn=users,cn=accounts,dc=ipa,dc=test
-
replace: modifiersname
modifiersname: uid=admin,cn=users,cn=accounts,dc=ipa,dc=test
-
replace: modifytimestamp
modifytimestamp: 20220308073013Z
-
replace: entryusn
entryusn: 6526
-
HTH,
flo
On Tue, Mar 8, 2022 at 2:53 AM Charles P via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org> wrote:
Hi Folks, I'm new here so please kindly let me know if I go
wrong...
I'm hoping someone can help me with diagnosing this problem. I recently
installed FreeIPA on a CentOS 8 LXC container. Everything was working quite
well, I had a few users set up and my first objective was to set up
Postfix/Dovecot for virtual user/mailbox support using LDAP against FreeIPA.
Background:
Following the excellent instructions here
https://www.vennedey.net/resources/2-LDAP-managed-mail-server-with-Postfi...
was mostly straight forward. I'm fairly familiar with Postfix but the
instructions called for extending the LDAP schema to add a new class with
two attributes (At least i think that's how it's correctly described) for
*maildrop* and *mailacceptinggeneralid*. The article doesn't specifically
relate to FreeIPA or 389Dir so to work out how to extend the schema I had
to cross reference other material and this may be where I have gone wrong -
it took a couple of goes.
However I eventually added an ldif file to /etc/dirsrv/slapd-PILLARAMA-NET/schema/
and restarted FreeIPA without error.
I also wrote and installed a js plugin for the webUI to /usr/share/ipa/ui/js/plugins/
which was based closely on a NextCloud Quota plugin found here
https://github.com/radiorabe/freeipa-extending-ldap-schema-and-ui/issues/2
Here is the content of my LDIF:
*dn: cn=schema cn: postfix attributetypes: (1.3.6.1.4.1.4203.666.1.200
NAME 'mailacceptinggeneralid' DESC 'Postfix mail local address alias
attribute' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{1024}) attributetypes:
(1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Postfix mail final
destination attribute' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{1024}) objectclasses:
(1.3.6.1.4.1.4203.666.1.100 NAME 'postfixuser' DESC 'Postfix mail
user class' SUP top AUXILIARY MAY(mailacceptinggeneralid $
maildrop))*
I can supply the web UI plugin code as well if anyone thinks it's related
but it's probably a bit long to paste in here.
This mostly seems to work (I have one issue where only the Directory Admin
can read those attributes not the new PostFix bind user I created, but
that's not what concerned about fixing yet unless it's somehow related).
The Problem:
After successfully getting Postfix and Dovecot up and running with virtual
user accounts I momentarily celebrated... until I tried to create another
new user in FreeIPA to discover that every single user account I try to
create complains that it's a duplicate user - no matter what random and
definitely unique username I choose. Here is the error in the webinterface:
IPA Error 4002: DuplicateEntry
*user with name "newuserthatsdefinitelyunique" already exists*
I have looked for logs but not found much that was helpful. The most
relevant I found was actually /var/log/httpd/error_log which says:
*[Tue Mar 08 12:08:19.420195 2022] [wsgi:error] [pid 28301:tid
139989980104448] [remote 192.168.100.26:49712
<
http://192.168.100.26:49712>] ipa: INFO: [jsonserver_session]
admin(a)PILLARAMA.NET <n(a)PILLARAMA.NET>:
user_add('newuserthatsdefinitelyunique', givenname='New',
sn='User',
version='2.245'): DuplicateEntry *
But again - not much to go on.
I have tried to remove the schema extension but when I remove the class
from IPAServer->Configuration>Default user objectclasses in the web
interface I get this error:
IPA Error 3009: ValidationError
*invalid 'ipauserobjectclasses': user default attribute
postfixmailacceptinggeneralid would not be allowed!*
Which I could guess what that means - I suppose because those attributes
are now in use the class can't be safely removed? Either way I don't know
how to proceed and don't even know if the schema extension is the problem
or not trying hard to removine it straight after I got it working doesn't
seem that appealing.
I really don't know where to look from here - I've been Googling for days
but being new to the whole LDAP/FreeIPA stack I may not be searching well.
I don't know if this is a FreeIPA issue or a 389Dir issue nor if I created
the problem with the schema extension or something else I did trying to
install that extension, or if it's unrelated. Please can someone give me
some direction about where to look? I would rather try to learn from my
mistakes and fix this install than scrap it and just blindly start from
scratch, possibly repeating the same mistake again.
Thanks in advance!
Pillarama
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure