[Freeipa-users] Re: Need help with confusing query results

[Florence Blanc-Renaud via FreeIPA-users]

Hi,
the issue with "dsconf  plugin entryuuid fixup" is a known
issue, see *Bug 2036672*
 - Based on 1944494
(RFC 4530 entryUUID attribute) - plugin entryuuid failing

HTH,
flo

On Thu, Jan 27, 2022 at 5:53 AM Edward Valley via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi,
>
> I realized that only users created after certain date has an entryUUID
> attribute, so query results are not confusing anymore, and as I can see it
> now, in the process of hiding private information, my first post is somehow
> misleading. Sorry about that.
>
> From the dnf logs on my system, I can see that date matches the date
> 389-ds-base was upgraded from 389-ds-base-1.4.3.16-16 to
> 389-ds-base-1.4.3.16-19, so I can guess the entryUUID plugin was included
> in Rocky Linux 8.4, and probably RHEL 8.4, around that time, although RHEL
> specify it as a new feature for release 8.5.
>
> RHEL 8.5 release notes, say we must run the following command to manualy
> add it to existing entries:
> # dsconf  plugin entryuuid fixup
> But it doesn't currently work on my system.
> I'll provide feedback once I figure it out.
>
> Thanks
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Need help with confusing query results

[Edward Valley via FreeIPA-users]

Hi,

I realized that only users created after certain date has an entryUUID 
attribute, so query results are not confusing anymore, and as I can see it now, 
in the process of hiding private information, my first post is somehow 
misleading. Sorry about that.

From the dnf logs on my system, I can see that date matches the date 
389-ds-base was upgraded from 389-ds-base-1.4.3.16-16 to 
389-ds-base-1.4.3.16-19, so I can guess the entryUUID plugin was included in 
Rocky Linux 8.4, and probably RHEL 8.4, around that time, although RHEL specify 
it as a new feature for release 8.5.

RHEL 8.5 release notes, say we must run the following command to manualy add it 
to existing entries:
# dsconf  plugin entryuuid fixup
But it doesn't currently work on my system.
I'll provide feedback once I figure it out.

Thanks
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: parse the audit logs

[Kathy Zhu via FreeIPA-users]

Digging a bit more, if match the time stamp, *where* (IP address) and *who* are
in /var/log/httpd/access_log, for example:

10.10.0.6 - ka...@example.com [26/Jan/2022:13:54:42 -0800] "POST
/ipa/session/json HTTP/1.1" 200 582


On Wed, Jan 26, 2022 at 6:11 PM Mark Reynolds  wrote:

>
> On 1/26/22 8:51 PM, Kathy Zhu via FreeIPA-users wrote:
>
> Thanks both Rob and Mark for your replies! Take user creation as an
> example:
>
> in /var/log/httpd/error_log:
>
> via GUI -  what, when and who
> via CLI - what, when and admin (since admin privilege is needed)
>
> in /var/log/dirsrv/slapd-EXAMPLE-COM/audit:
>
> via GUI - what, when and who (dn of creatorsName and modifiersName)
> via CLI - what, when and admin (dn of creatorsName and modifiersName)
>
> Above example shows that if the user is created via GUI, the audit
> information is good. If via CLI, "who" is admin instead.
>
> Inside audit log, the values of modifiersname are "Directory Manager",
> admin, "krbprincipalname=ldap/..." and so on, while I am looking for a
> particular user.
>
> in /var/log/dirsrv/slapd-EXAMPLE-COM/access log, there is a "conn" number
> associated with each line, I'd love to get the instruction how to enable
> "conn" number in audit log, I can use it find out "from where".
>
> Sorry there is no way to do it yet.  It would be an RFE, and probably a
> new config attribute nsslapd-auditlog-level in Directory Server.  I can not
> promise how soon the feature will be implemented, but file the RFE here:
> https://github.com/389ds/389-ds-base/issues/new/choose
>
> Thanks,
>
> Mark
>
>
> Thanks.
>
> Kathy.
>
> On Wed, Jan 26, 2022 at 12:10 PM Mark Reynolds 
> wrote:
>
>>
>> On 1/26/22 1:02 PM, Kathy Zhu via FreeIPA-users wrote:
>>
>> Thanks Mark and Florence for your replies!
>>
>> I will check directory389 list to see if there is any useful information.
>>
>> By turning on audit logging, we'd like to have a record of what was
>> changed, when and by whom. For example, we should be able to answer when
>> and who added the user XYZ.  Unfortunately, IPA's audit logging isn't great
>> to serve that purpose, it provides information of what and when, not by
>> whom (modifiersname field is useless).
>>
>> Why is modifiersname useless?  It would be the Bind DN that performed the
>> operation -> the "Who".  The LDAP server only knows of "who" by it's LDAP
>> DN and there is no other value it could use.  The "What" is the "dn", and
>> the "When" is the "time" stamp in the audit log entry.
>>
>> For the "Where", you would need to know the connection ID.  Then the
>> access log could be parsed to find the IP address of the client.
>> Technically the conn ID could be added to the audit log, but changing the
>> logging format is problematic as people are already parsing our logs and
>> every time we change the format we get complaints.
>>
>> Sorry I guess I still don't understand what is missing.  From my
>> standpoint we already provide the Who, What, and When in the audit log
>> (from the DS perspective).  Perhaps the specific info you want is not
>> available in the LDAP server?
>>
>> Mark
>>
>>
>> For others facing similar situations, I found filebeat does the track, it
>> can combine multiple lines of logs to a single line before forwarding the
>> logs, which is searchable.
>>
>> Thanks.
>>
>> Kathy.
>>
>> On Wed, Jan 26, 2022 at 10:40 AM Rob Crittenden 
> wrote:
> Kathy Zhu via FreeIPA-users wrote:
> > Thanks Mark and Florence for your replies!
> >
> > I will check directory389 list to see if there is any useful
> information.
> >
> > By turning on audit logging, we'd like to have a record of what was
> > changed, when and by whom. For example, we should be able to answer when
> > and who added the user XYZ.  Unfortunately, IPA's audit logging isn't
> > great to serve that purpose, it provides information of what and when,
> > not by whom (modifiersname field is useless).
>
> The IPA audit log is the apache error log.
>
> Adding a user you'll see something like:
>
> [Wed Jan 26 13:38:57.762988 2022] [wsgi:error] [pid 1475984:tid 1476323]
> [remote 192.168.166.203:46788] ipa: INFO: [jsonserver_session]
> tu...@example.test: user_add/1('suser', givenname='some', sn='user',
> version='2.245'): SUCCESS
>
> So user tuser added user suser successfully today at 1:30pm.
>
> rob
> >
> > For others facing similar situations, I found filebeat does the track,
> > it can combine multiple lines of logs to a single line before forwarding
> > the logs, which is searchable.
> >
> > Thanks.
> >
> > Kathy.
> >
>
>>
>> On Wed, Jan 26, 2022 at 8:21 AM Mark Reynolds 
>> wrote:
>>
>>> The audit log is essentially just a list of LDIF commands.  If you
>>> remove the "time" and "result" lines you can redirect the log straight to
>>> ldapmodify:
>>>
>>>
>>> time: 20220126111500
>>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
>>> result: 0
>>> changetype: modify
>>> replace: nsslapd-lookthroughlimit
>>> nsslapd-lookthroughlimit: 5001
>>> -
>>> replace: modifiersname

[Freeipa-users] Re: parse the audit logs

[Kathy Zhu via FreeIPA-users]

Thank you, Mark!

Change a topic, though still audit logging related - where to find audit
information of successful and failure user authentication by IPA? Take
"kinit admin" as an example, I gave a wrong password, the auth failed. I
searched /var/log/krb5kdb.log but could not find this event. Is it
recorded? If yes, where should I look for it?

Thanks.

Kathy.


On Wed, Jan 26, 2022 at 6:11 PM Mark Reynolds  wrote:

>
> On 1/26/22 8:51 PM, Kathy Zhu via FreeIPA-users wrote:
>
> Thanks both Rob and Mark for your replies! Take user creation as an
> example:
>
> in /var/log/httpd/error_log:
>
> via GUI -  what, when and who
> via CLI - what, when and admin (since admin privilege is needed)
>
> in /var/log/dirsrv/slapd-EXAMPLE-COM/audit:
>
> via GUI - what, when and who (dn of creatorsName and modifiersName)
> via CLI - what, when and admin (dn of creatorsName and modifiersName)
>
> Above example shows that if the user is created via GUI, the audit
> information is good. If via CLI, "who" is admin instead.
>
> Inside audit log, the values of modifiersname are "Directory Manager",
> admin, "krbprincipalname=ldap/..." and so on, while I am looking for a
> particular user.
>
> in /var/log/dirsrv/slapd-EXAMPLE-COM/access log, there is a "conn" number
> associated with each line, I'd love to get the instruction how to enable
> "conn" number in audit log, I can use it find out "from where".
>
> Sorry there is no way to do it yet.  It would be an RFE, and probably a
> new config attribute nsslapd-auditlog-level in Directory Server.  I can not
> promise how soon the feature will be implemented, but file the RFE here:
> https://github.com/389ds/389-ds-base/issues/new/choose
>
> Thanks,
>
> Mark
>
>
> Thanks.
>
> Kathy.
>
> On Wed, Jan 26, 2022 at 12:10 PM Mark Reynolds 
> wrote:
>
>>
>> On 1/26/22 1:02 PM, Kathy Zhu via FreeIPA-users wrote:
>>
>> Thanks Mark and Florence for your replies!
>>
>> I will check directory389 list to see if there is any useful information.
>>
>> By turning on audit logging, we'd like to have a record of what was
>> changed, when and by whom. For example, we should be able to answer when
>> and who added the user XYZ.  Unfortunately, IPA's audit logging isn't great
>> to serve that purpose, it provides information of what and when, not by
>> whom (modifiersname field is useless).
>>
>> Why is modifiersname useless?  It would be the Bind DN that performed the
>> operation -> the "Who".  The LDAP server only knows of "who" by it's LDAP
>> DN and there is no other value it could use.  The "What" is the "dn", and
>> the "When" is the "time" stamp in the audit log entry.
>>
>> For the "Where", you would need to know the connection ID.  Then the
>> access log could be parsed to find the IP address of the client.
>> Technically the conn ID could be added to the audit log, but changing the
>> logging format is problematic as people are already parsing our logs and
>> every time we change the format we get complaints.
>>
>> Sorry I guess I still don't understand what is missing.  From my
>> standpoint we already provide the Who, What, and When in the audit log
>> (from the DS perspective).  Perhaps the specific info you want is not
>> available in the LDAP server?
>>
>> Mark
>>
>>
>> For others facing similar situations, I found filebeat does the track, it
>> can combine multiple lines of logs to a single line before forwarding the
>> logs, which is searchable.
>>
>> Thanks.
>>
>> Kathy.
>>
>> On Wed, Jan 26, 2022 at 10:40 AM Rob Crittenden 
> wrote:
> Kathy Zhu via FreeIPA-users wrote:
> > Thanks Mark and Florence for your replies!
> >
> > I will check directory389 list to see if there is any useful
> information.
> >
> > By turning on audit logging, we'd like to have a record of what was
> > changed, when and by whom. For example, we should be able to answer when
> > and who added the user XYZ.  Unfortunately, IPA's audit logging isn't
> > great to serve that purpose, it provides information of what and when,
> > not by whom (modifiersname field is useless).
>
> The IPA audit log is the apache error log.
>
> Adding a user you'll see something like:
>
> [Wed Jan 26 13:38:57.762988 2022] [wsgi:error] [pid 1475984:tid 1476323]
> [remote 192.168.166.203:46788] ipa: INFO: [jsonserver_session]
> tu...@example.test: user_add/1('suser', givenname='some', sn='user',
> version='2.245'): SUCCESS
>
> So user tuser added user suser successfully today at 1:30pm.
>
> rob
> >
> > For others facing similar situations, I found filebeat does the track,
> > it can combine multiple lines of logs to a single line before forwarding
> > the logs, which is searchable.
> >
> > Thanks.
> >
> > Kathy.
> >
>
>>
>> On Wed, Jan 26, 2022 at 8:21 AM Mark Reynolds 
>> wrote:
>>
>>> The audit log is essentially just a list of LDIF commands.  If you
>>> remove the "time" and "result" lines you can redirect the log straight to
>>> ldapmodify:
>>>
>>>
>>> time: 20220126111500
>>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config

[Freeipa-users] Re: parse the audit logs

[Mark Reynolds via FreeIPA-users]

On 1/26/22 8:51 PM, Kathy Zhu via FreeIPA-users wrote:
Thanks both Rob and Mark for your replies! Take user creation as an 
example:


in /var/log/httpd/error_log:

via GUI -  what, when and who
via CLI - what, when and admin (since admin privilege is needed)

in /var/log/dirsrv/slapd-EXAMPLE-COM/audit:

via GUI - what, when and who (dn of creatorsName and modifiersName)
via CLI - what, when and admin (dn of creatorsName and modifiersName)

Above example shows that if the user is created via GUI, the audit 
information is good. If via CLI, "who" is admin instead.


Inside audit log, the values of modifiersname are "Directory Manager", 
admin, "krbprincipalname=ldap/..." and so on, while I am looking for a 
particular user.


in /var/log/dirsrv/slapd-EXAMPLE-COM/access log, there is a "conn" 
number associated with each line, I'd love to get the instruction how 
to enable "conn" number in audit log, I can use it find out "from where".


Sorry there is no way to do it yet.  It would be an RFE, and probably a 
new config attribute nsslapd-auditlog-level in Directory Server.  I can 
not promise how soon the feature will be implemented, but file the RFE 
here: https://github.com/389ds/389-ds-base/issues/new/choose


Thanks,

Mark



Thanks.

Kathy.

On Wed, Jan 26, 2022 at 12:10 PM Mark Reynolds  
wrote:



On 1/26/22 1:02 PM, Kathy Zhu via FreeIPA-users wrote:

Thanks Mark and Florence for your replies!

I will check directory389 list to see if there is any useful
information.

By turning on audit logging, we'd like to have a record of what
was changed, when and by whom. For example, we should be able to
answer when and who added the user XYZ.  Unfortunately, IPA's
audit logging isn't great to serve that purpose, it provides
information of what and when, not by whom (modifiersname field is
useless).


Why is modifiersname useless?  It would be the Bind DN that
performed the operation -> the "Who".  The LDAP server only knows
of "who" by it's LDAP DN and there is no other value it could
use.  The "What" is the "dn", and the "When" is the "time" stamp
in the audit log entry.

For the "Where", you would need to know the connection ID.  Then
the access log could be parsed to find the IP address of the
client.  Technically the conn ID could be added to the audit log,
but changing the logging format is problematic as people are
already parsing our logs and every time we change the format we
get complaints.

Sorry I guess I still don't understand what is missing.  From my
standpoint we already provide the Who, What, and When in the audit
log (from the DS perspective).  Perhaps the specific info you want
is not available in the LDAP server?

Mark



For others facing similar situations, I found filebeat does the
track, it can combine multiple lines of logs to a single line
before forwarding the logs, which is searchable.

Thanks.

Kathy.


On Wed, Jan 26, 2022 at 10:40 AM Rob Crittenden  
wrote:

Kathy Zhu via FreeIPA-users wrote:
> Thanks Mark and Florence for your replies!
>
> I will check directory389 list to see if there is any useful 
information.

>
> By turning on audit logging, we'd like to have a record of what was
> changed, when and by whom. For example, we should be able to answer when
> and who added the user XYZ.  Unfortunately, IPA's audit logging isn't
> great to serve that purpose, it provides information of what and when,
> not by whom (modifiersname field is useless).

The IPA audit log is the apache error log.

Adding a user you'll see something like:

[Wed Jan 26 13:38:57.762988 2022] [wsgi:error] [pid 1475984:tid 1476323]
[remote 192.168.166.203:46788 ] ipa: 
INFO: [jsonserver_session]

tu...@example.test: user_add/1('suser', givenname='some', sn='user',
version='2.245'): SUCCESS

So user tuser added user suser successfully today at 1:30pm.

rob
>
> For others facing similar situations, I found filebeat does the track,
> it can combine multiple lines of logs to a single line before forwarding
> the logs, which is searchable.
>
> Thanks.
>
> Kathy.
>



On Wed, Jan 26, 2022 at 8:21 AM Mark Reynolds
 wrote:

The audit log is essentially just a list of LDIF commands. 
If you remove the "time" and "result" lines you can redirect
the log straight to ldapmodify:


time: 20220126111500
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
result: 0
changetype: modify
replace: nsslapd-lookthroughlimit
nsslapd-lookthroughlimit: 5001
-
replace: modifiersname
modifiersname: cn=dm
-
replace: modifytimestamp
modifytimestamp: 20220126161500Z
-


I'm not sure this log is worth "parsing" since it's just
describing the exact changes made to the server, and I'm not
sure there are that many any useful 

[Freeipa-users] Re: parse the audit logs

[Kathy Zhu via FreeIPA-users]

Thanks both Rob and Mark for your replies! Take user creation as an
example:

in /var/log/httpd/error_log:

via GUI -  what, when and who
via CLI - what, when and admin (since admin privilege is needed)

in /var/log/dirsrv/slapd-EXAMPLE-COM/audit:

via GUI - what, when and who (dn of creatorsName and modifiersName)
via CLI - what, when and admin (dn of creatorsName and modifiersName)

Above example shows that if the user is created via GUI, the audit
information is good. If via CLI, "who" is admin instead.

Inside audit log, the values of modifiersname are "Directory Manager",
admin, "krbprincipalname=ldap/..." and so on, while I am looking for a
particular user.

in /var/log/dirsrv/slapd-EXAMPLE-COM/access log, there is a "conn" number
associated with each line, I'd love to get the instruction how to enable
"conn" number in audit log, I can use it find out "from where". Could you
help please?

Thanks.

Kathy.

On Wed, Jan 26, 2022 at 12:10 PM Mark Reynolds  wrote:

>
> On 1/26/22 1:02 PM, Kathy Zhu via FreeIPA-users wrote:
>
> Thanks Mark and Florence for your replies!
>
> I will check directory389 list to see if there is any useful information.
>
> By turning on audit logging, we'd like to have a record of what was
> changed, when and by whom. For example, we should be able to answer when
> and who added the user XYZ.  Unfortunately, IPA's audit logging isn't great
> to serve that purpose, it provides information of what and when, not by
> whom (modifiersname field is useless).
>
> Why is modifiersname useless?  It would be the Bind DN that performed the
> operation -> the "Who".  The LDAP server only knows of "who" by it's LDAP
> DN and there is no other value it could use.  The "What" is the "dn", and
> the "When" is the "time" stamp in the audit log entry.
>
> For the "Where", you would need to know the connection ID.  Then the
> access log could be parsed to find the IP address of the client.
> Technically the conn ID could be added to the audit log, but changing the
> logging format is problematic as people are already parsing our logs and
> every time we change the format we get complaints.
>
> Sorry I guess I still don't understand what is missing.  From my
> standpoint we already provide the Who, What, and When in the audit log
> (from the DS perspective).  Perhaps the specific info you want is not
> available in the LDAP server?
>
> Mark
>
>
> For others facing similar situations, I found filebeat does the track, it
> can combine multiple lines of logs to a single line before forwarding the
> logs, which is searchable.
>
> Thanks.
>
> Kathy.
>
> On Wed, Jan 26, 2022 at 10:40 AM Rob Crittenden 
wrote:
Kathy Zhu via FreeIPA-users wrote:
> Thanks Mark and Florence for your replies!
>
> I will check directory389 list to see if there is any useful information.
>
> By turning on audit logging, we'd like to have a record of what was
> changed, when and by whom. For example, we should be able to answer when
> and who added the user XYZ.  Unfortunately, IPA's audit logging isn't
> great to serve that purpose, it provides information of what and when,
> not by whom (modifiersname field is useless).

The IPA audit log is the apache error log.

Adding a user you'll see something like:

[Wed Jan 26 13:38:57.762988 2022] [wsgi:error] [pid 1475984:tid 1476323]
[remote 192.168.166.203:46788] ipa: INFO: [jsonserver_session]
tu...@example.test: user_add/1('suser', givenname='some', sn='user',
version='2.245'): SUCCESS

So user tuser added user suser successfully today at 1:30pm.

rob
>
> For others facing similar situations, I found filebeat does the track,
> it can combine multiple lines of logs to a single line before forwarding
> the logs, which is searchable.
>
> Thanks.
>
> Kathy.
>

>
> On Wed, Jan 26, 2022 at 8:21 AM Mark Reynolds  wrote:
>
>> The audit log is essentially just a list of LDIF commands.  If you remove
>> the "time" and "result" lines you can redirect the log straight to
>> ldapmodify:
>>
>>
>> time: 20220126111500
>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
>> result: 0
>> changetype: modify
>> replace: nsslapd-lookthroughlimit
>> nsslapd-lookthroughlimit: 5001
>> -
>> replace: modifiersname
>> modifiersname: cn=dm
>> -
>> replace: modifytimestamp
>> modifytimestamp: 20220126161500Z
>> -
>>
>>
>> I'm not sure this log is worth "parsing" since it's just describing the
>> exact changes made to the server, and I'm not sure there are that many any
>> useful "stats" that could be gained by parsing it.  What exactly are you
>> hoping to get out of it?
>>
>> Mark
>> On 1/26/22 11:05 AM, Florence Blanc-Renaud via FreeIPA-users wrote:
>>
>> Hi,
>> You should try with 389-us...@lists.fedoraproject.org
>> ,
>> other users may have found a solution to your problem.
>> flo
>>
>> On Fri, Jan 21, 2022 at 6:45 PM Kathy Zhu  wrote:
>>
>>> Yes, correct, Florence.
>>>
>>> BTW, Florence, I'd like to take this opportunity 

[Freeipa-users] Re: parse the audit logs

[Mark Reynolds via FreeIPA-users]

On 1/26/22 1:02 PM, Kathy Zhu via FreeIPA-users wrote:

Thanks Mark and Florence for your replies!

I will check directory389 list to see if there is any useful information.

By turning on audit logging, we'd like to have a record of what was 
changed, when and by whom. For example, we should be able to answer 
when and who added the user XYZ.  Unfortunately, IPA's audit logging 
isn't great to serve that purpose, it provides information of what and 
when, not by whom (modifiersname field is useless).


Why is modifiersname useless?  It would be the Bind DN that performed 
the operation -> the "Who".  The LDAP server only knows of "who" by it's 
LDAP DN and there is no other value it could use.  The "What" is the 
"dn", and the "When" is the "time" stamp in the audit log entry.


For the "Where", you would need to know the connection ID.  Then the 
access log could be parsed to find the IP address of the client.  
Technically the conn ID could be added to the audit log, but changing 
the logging format is problematic as people are already parsing our logs 
and every time we change the format we get complaints.


Sorry I guess I still don't understand what is missing.  From my 
standpoint we already provide the Who, What, and When in the audit log 
(from the DS perspective).  Perhaps the specific info you want is not 
available in the LDAP server?


Mark



For others facing similar situations, I found filebeat does the track, 
it can combine multiple lines of logs to a single line before 
forwarding the logs, which is searchable.


Thanks.

Kathy.

On Wed, Jan 26, 2022 at 8:21 AM Mark Reynolds  wrote:

The audit log is essentially just a list of LDIF commands.  If you
remove the "time" and "result" lines you can redirect the log
straight to ldapmodify:


time: 20220126111500
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
result: 0
changetype: modify
replace: nsslapd-lookthroughlimit
nsslapd-lookthroughlimit: 5001
-
replace: modifiersname
modifiersname: cn=dm
-
replace: modifytimestamp
modifytimestamp: 20220126161500Z
-


I'm not sure this log is worth "parsing" since it's just
describing the exact changes made to the server, and I'm not sure
there are that many any useful "stats" that could be gained by
parsing it.  What exactly are you hoping to get out of it?

Mark

On 1/26/22 11:05 AM, Florence Blanc-Renaud via FreeIPA-users wrote:

Hi,
You should try with 389-us...@lists.fedoraproject.org

,
other users may have found a solution to your problem.
flo

On Fri, Jan 21, 2022 at 6:45 PM Kathy Zhu  wrote:

Yes, correct, Florence.

BTW, Florence, I'd like to take this opportunity to let you
know that I benefit from your blog, especially the one about
certificates.

Thanks!

Kathy.

On Fri, Jan 21, 2022 at 1:17 AM Florence Blanc-Renaud
 wrote:

Hi Kathy,
which log file are you referring to? 389-ds audit log in
/var/log/dirsrv/slapd-xxx/audit?

flo

On Thu, Jan 20, 2022 at 6:43 PM Kathy Zhu via
FreeIPA-users  wrote:

Hello list,

I had FreeIPA audit log on. I feed audit logs to
Graylog. Since there are multiple lines of logs for
each event, I could not find a suitable extractor to
parse the logs. Therefore, the logs are very hard to
read. Could anyone in the list share how you process
the logs if you are in a similar situation?

Thanks!

Kathy.



___
FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure


___
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org
To unsubscribe send an email tofreeipa-users-le...@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.fedorahosted.org
Do not 

[Freeipa-users] Re: first replica master - Internal error testing KRA clone

[Rob Crittenden via FreeIPA-users]

lejeczek via FreeIPA-users wrote:
> Hi guys.
> 
> I believe that is reproducible every time - clean deployment, first
> master's ipa-healthcheck no problems, replica added still no problems,
> then on that first replica 'ipa-kra-install' and immediately:
> 
> -> $ ipa-healthcheck
> Internal error testing KRA clone. KRA clone problem detected Host:
> swir.mine.private Port: 443
> Unhandler rdtype 256
> Unhandler rdtype 256
> Unhandler rdtype 256
> Unhandler rdtype 256
> Unhandler rdtype 256
> Unhandler rdtype 256
> Unhandler rdtype 256
> Unhandler rdtype 256
> [
>   {
>     "source": "pki.server.healthcheck.clones.connectivity_and_data",
>     "check": "ClonesConnectivyAndDataCheck",
>     "result": "ERROR",
>     "uuid": "eed4f41f-27fe-4f37-aa01-d47602f2c58f",
>     "when": "20220126174106Z",
>     "duration": "1.207738",
>     "kw": {
>   "status": "ERROR:  pki-tomcat : Internal error testing KRA clone.
> Host: swir.mine.private Port: 443"
>     }
>   }
> ]
> 
> How critical is that and what to do to fix it?

I believe this is a false positive. The pki healthcheck maintainer is
working on it.

The "Unhandler" errors are the newish DNS URI records that are currently
unhandled by healthcheck. Support has been added in the tip but I have a
few more things to merge before doing another full release (which of
course will take a while to trickle down, if ever, into existing
distribution releases).

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: parse the audit logs

[Rob Crittenden via FreeIPA-users]

Kathy Zhu via FreeIPA-users wrote:
> Thanks Mark and Florence for your replies! 
> 
> I will check directory389 list to see if there is any useful information. 
> 
> By turning on audit logging, we'd like to have a record of what was
> changed, when and by whom. For example, we should be able to answer when
> and who added the user XYZ.  Unfortunately, IPA's audit logging isn't
> great to serve that purpose, it provides information of what and when,
> not by whom (modifiersname field is useless). 

The IPA audit log is the apache error log.

Adding a user you'll see something like:

[Wed Jan 26 13:38:57.762988 2022] [wsgi:error] [pid 1475984:tid 1476323]
[remote 192.168.166.203:46788] ipa: INFO: [jsonserver_session]
tu...@example.test: user_add/1('suser', givenname='some', sn='user',
version='2.245'): SUCCESS

So user tuser added user suser successfully today at 1:30pm.

rob
> 
> For others facing similar situations, I found filebeat does the track,
> it can combine multiple lines of logs to a single line before forwarding
> the logs, which is searchable. 
> 
> Thanks.
> 
> Kathy. 
> 
> On Wed, Jan 26, 2022 at 8:21 AM Mark Reynolds  > wrote:
> 
> The audit log is essentially just a list of LDIF commands.  If you
> remove the "time" and "result" lines you can redirect the log
> straight to ldapmodify:
> 
> 
> time: 20220126111500
> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
> result: 0
> changetype: modify
> replace: nsslapd-lookthroughlimit
> nsslapd-lookthroughlimit: 5001
> -
> replace: modifiersname
> modifiersname: cn=dm
> -
> replace: modifytimestamp
> modifytimestamp: 20220126161500Z
> -
> 
> 
> I'm not sure this log is worth "parsing" since it's just describing
> the exact changes made to the server, and I'm not sure there are
> that many any useful "stats" that could be gained by parsing it. 
> What exactly are you hoping to get out of it?
> 
> Mark
> 
> On 1/26/22 11:05 AM, Florence Blanc-Renaud via FreeIPA-users wrote:
>> Hi,
>> You should try with 389-us...@lists.fedoraproject.org
>> 
>> ,
>> other users may have found a solution to your problem.
>> flo
>>
>> On Fri, Jan 21, 2022 at 6:45 PM Kathy Zhu > > wrote:
>>
>> Yes, correct, Florence. 
>>
>> BTW, Florence, I'd like to take this opportunity to let you
>> know that I benefit from your blog, especially the one about
>> certificates. 
>>
>> Thanks!
>>
>> Kathy. 
>>
>> On Fri, Jan 21, 2022 at 1:17 AM Florence Blanc-Renaud
>> mailto:f...@redhat.com>> wrote:
>>
>> Hi Kathy,
>> which log file are you referring to? 389-ds audit log in
>> /var/log/dirsrv/slapd-xxx/audit?
>>
>> flo
>>
>> On Thu, Jan 20, 2022 at 6:43 PM Kathy Zhu via
>> FreeIPA-users > > wrote:
>>
>> Hello list, 
>>
>> I had FreeIPA audit log on. I feed audit logs to
>> Graylog. Since there are multiple lines of logs for
>> each event, I could not find a suitable extractor to
>> parse the logs. Therefore, the logs are very hard to
>> read. Could anyone in the list share how you process
>> the logs if you are in a similar situation?
>>
>> Thanks!
>>
>> Kathy. 
>>
>>
>>
>> ___
>> FreeIPA-users mailing list --
>> freeipa-users@lists.fedorahosted.org
>> 
>> To unsubscribe send an email to
>> freeipa-users-le...@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.fedorahosted.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>>
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org 
>> 
>> To unsubscribe send an email to 
>> freeipa-users-le...@lists.fedorahosted.org 
>> 
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: 

[Freeipa-users] Re: parse the audit logs

[Kathy Zhu via FreeIPA-users]

Thanks Mark and Florence for your replies!

I will check directory389 list to see if there is any useful information.

By turning on audit logging, we'd like to have a record of what was
changed, when and by whom. For example, we should be able to answer when
and who added the user XYZ.  Unfortunately, IPA's audit logging isn't great
to serve that purpose, it provides information of what and when, not by
whom (modifiersname field is useless).

For others facing similar situations, I found filebeat does the track, it
can combine multiple lines of logs to a single line before forwarding the
logs, which is searchable.

Thanks.

Kathy.

On Wed, Jan 26, 2022 at 8:21 AM Mark Reynolds  wrote:

> The audit log is essentially just a list of LDIF commands.  If you remove
> the "time" and "result" lines you can redirect the log straight to
> ldapmodify:
>
>
> time: 20220126111500
> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
> result: 0
> changetype: modify
> replace: nsslapd-lookthroughlimit
> nsslapd-lookthroughlimit: 5001
> -
> replace: modifiersname
> modifiersname: cn=dm
> -
> replace: modifytimestamp
> modifytimestamp: 20220126161500Z
> -
>
>
> I'm not sure this log is worth "parsing" since it's just describing the
> exact changes made to the server, and I'm not sure there are that many any
> useful "stats" that could be gained by parsing it.  What exactly are you
> hoping to get out of it?
>
> Mark
> On 1/26/22 11:05 AM, Florence Blanc-Renaud via FreeIPA-users wrote:
>
> Hi,
> You should try with 389-us...@lists.fedoraproject.org
> ,
> other users may have found a solution to your problem.
> flo
>
> On Fri, Jan 21, 2022 at 6:45 PM Kathy Zhu  wrote:
>
>> Yes, correct, Florence.
>>
>> BTW, Florence, I'd like to take this opportunity to let you know that I
>> benefit from your blog, especially the one about certificates.
>>
>> Thanks!
>>
>> Kathy.
>>
>> On Fri, Jan 21, 2022 at 1:17 AM Florence Blanc-Renaud 
>> wrote:
>>
>>> Hi Kathy,
>>> which log file are you referring to? 389-ds audit log in
>>> /var/log/dirsrv/slapd-xxx/audit?
>>>
>>> flo
>>>
>>> On Thu, Jan 20, 2022 at 6:43 PM Kathy Zhu via FreeIPA-users <
>>> freeipa-users@lists.fedorahosted.org> wrote:
>>>
 Hello list,

 I had FreeIPA audit log on. I feed audit logs to Graylog. Since there
 are multiple lines of logs for each event, I could not find a suitable
 extractor to parse the logs. Therefore, the logs are very hard to read.
 Could anyone in the list share how you process the logs if you are in a
 similar situation?

 Thanks!

 Kathy.



 ___
 FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
 To unsubscribe send an email to
 freeipa-users-le...@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.fedorahosted.org
 Do not reply to spam on the list, report it:
 https://pagure.io/fedora-infrastructure

>>>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
>
> --
> Directory Server Development Team
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] first replica master - Internal error testing KRA clone

[lejeczek via FreeIPA-users]

Hi guys.

I believe that is reproducible every time - clean 
deployment, first master's ipa-healthcheck no problems, 
replica added still no problems, then on that first replica 
'ipa-kra-install' and immediately:


-> $ ipa-healthcheck
Internal error testing KRA clone. KRA clone problem detected 
Host: swir.mine.private Port: 443

Unhandler rdtype 256
Unhandler rdtype 256
Unhandler rdtype 256
Unhandler rdtype 256
Unhandler rdtype 256
Unhandler rdtype 256
Unhandler rdtype 256
Unhandler rdtype 256
[
  {
    "source": 
"pki.server.healthcheck.clones.connectivity_and_data",

    "check": "ClonesConnectivyAndDataCheck",
    "result": "ERROR",
    "uuid": "eed4f41f-27fe-4f37-aa01-d47602f2c58f",
    "when": "20220126174106Z",
    "duration": "1.207738",
    "kw": {
  "status": "ERROR:  pki-tomcat : Internal error 
testing KRA clone. Host: swir.mine.private Port: 443"

    }
  }
]

How critical is that and what to do to fix it?
many thanks, L.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: crypto policies but for SAMBA only - ?

[lejeczek via FreeIPA-users]

On 26/01/2022 16:23, Alexander Bokovoy wrote:

On ti, 25 tammi 2022, lejeczek via FreeIPA-users wrote:

On 25/01/2022 14:31, Alexander Bokovoy wrote:

On ti, 25 tammi 2022, lejeczek via FreeIPA-users wrote:

On 25/01/2022 12:11, Alexander Bokovoy wrote:

On ti, 25 tammi 2022, lejeczek via FreeIPA-users wrote:

Hi guys.

If that can be a news for some - I'd like to share a 
finding: it's possible to have ipa-integrated Samba 
serving non-enrolled clients, both Linux & Windows, 
with passwords for authentication. (which has been 
long & will continue to be a must-have for me)


Question for @devel - above I get with simply by 
switching to 'LEGACY' - is it possible to do that but 
only for IPA-Samba(+ whatever required bits) as 
oppose to system-widely?


It would be great to have IPA capable of that - 
perhaps an "enhancement" to future releases.


FreeIPA is not a single application, so it is hard to 
apply that.


I wonder if DEFAULT:AD-SUPPORT would work for you too? 
Or something on
top of AD-SUPPORT one? The following is what I have on 
Fedora 35:


$ cat 
/usr/share/crypto-policies/policies/modules/AD-SUPPORT.pmod 

# AD-SUPPORT subpolicy is intended to be used in 
Active Directory
# environments where either accounts or trusted domain 
objects were not yet
# migrated to AES or future encryption types. Active 
Directory implicitly
# requires RC4 and MD5 (arcfour-hmac-md5) in Kerberos 
by default.


cipher@kerberos = RC4-128+
hash@kerberos = MD5+

Samba uses GnuTLS, so may be expanding @gnutls scope 
in a similar way

would work?

E.g., add 
/etc/crypto-policies/policies/modules/MY-MODULE.pmod that

includes

cipher@kerberos = RC4-128+
hash@kerberos = MD5+
cipher@gnutls = RC4-128+
hash@gnutls = MD5+

and then set sytem-wide policy to use 
DEFAULT:MY-MODULE as a policy.


This doesn't define it per application but at least 
limits use of
insecure types to Kerberos and any application using 
GnuTLS.


I actually haven't tried this all.


Testing with this policy now and nope, Samba 4.15.3 says:

...

[2022/01/25 14:21:55.930113,  2, pid=16175] 
ipa_sam.c:3645(init_sam_from_ldap)

  init_sam_from_ldap: Entry found for user: dupa
[2022/01/25 14:21:55.947759,  1, pid=16175] 
../../source3/auth/check_samsec.c:454(check_sam_security)

  Failed to modify entry: NT_STATUS_NOT_IMPLEMENTED


All these modifications of the policy will not change 
the fact that we
do not implement modification of SAM entry in IPA SAM 
module. This means

you are getting in a different code path here.

So probably more changes to the policy are needed...



Here is something VERY ? peculiar...

1) I could both smbclient & ssh between IPA masters with 
passwords


2) I could ssh from a non-enrolled to IPA master with the 
password


3) non-enrolled smbclient _failed_ as with the log 
snipped, with password


then I looked at that Samba log again and did, on a master:

-> $ ipa passwd dupa

now I do ! can 3)

WTF? I must say.

user was created by IPA with '--password 
--password-expiration=20310312232428Z' as args to 'ipa 
user-add'


So, the policy seems good!! but that 'monstrosity' ? 
anybody will agree will be a 'bug', right?


I think what you see above is that the user was created 
before IPA setup
was enabled to handle trust configuration (which is a 
pre-requisite to
generate NT hashes). So when you re-generated password, 
that triggered

adding NT hash to that user.


Well.. I do not think that was that(or rather should not 
be), for my first master was set up with:
-> $ ipa-server-install --setup-dns --setup-kra 
--no-forwarders --idstart=5740 --admin-password=#diradm 
--ds-password=#dirsrv --enable-compat --setup-adtrust

and every next master as well
-> $ ipa-replica-install --setup-dns --no-forwarders 
--setup-ca --enable-compat --setup-adtrust


Would that be be what you think still, when instantiating 
IPA(4.9.6) in ways such as above?


thanks, L


With newer IPA (4.9.8 in Fedora or CentOS 9 Stream, for 
example, or
recent RHEL 8.5 update) you still need to prepare IPA to 
work with trust
(ipa-adtrust-install) but proper NT hash generation 
internally is
enabled from initial install instead of when 
ipa-adtrust-install is run.
For new installations this should reduce the gap as users 
created after
install would already be ready to access Samba when 
ipa-adtrust-install

will be run.



___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: crypto policies but for SAMBA only - ?

[Alexander Bokovoy via FreeIPA-users]

On ti, 25 tammi 2022, lejeczek via FreeIPA-users wrote:

On 25/01/2022 14:31, Alexander Bokovoy wrote:

On ti, 25 tammi 2022, lejeczek via FreeIPA-users wrote:

On 25/01/2022 12:11, Alexander Bokovoy wrote:

On ti, 25 tammi 2022, lejeczek via FreeIPA-users wrote:

Hi guys.

If that can be a news for some - I'd like to share a finding: 
it's possible to have ipa-integrated Samba serving 
non-enrolled clients, both Linux & Windows, with passwords for 
authentication. (which has been long & will continue to be a 
must-have for me)


Question for @devel - above I get with simply by switching to 
'LEGACY' - is it possible to do that but only for IPA-Samba(+ 
whatever required bits) as oppose to system-widely?


It would be great to have IPA capable of that - perhaps an 
"enhancement" to future releases.


FreeIPA is not a single application, so it is hard to apply that.

I wonder if DEFAULT:AD-SUPPORT would work for you too? Or something on
top of AD-SUPPORT one? The following is what I have on Fedora 35:

$ cat /usr/share/crypto-policies/policies/modules/AD-SUPPORT.pmod
# AD-SUPPORT subpolicy is intended to be used in Active Directory
# environments where either accounts or trusted domain objects 
were not yet
# migrated to AES or future encryption types. Active Directory 
implicitly

# requires RC4 and MD5 (arcfour-hmac-md5) in Kerberos by default.

cipher@kerberos = RC4-128+
hash@kerberos = MD5+

Samba uses GnuTLS, so may be expanding @gnutls scope in a similar way
would work?

E.g., add /etc/crypto-policies/policies/modules/MY-MODULE.pmod that
includes

cipher@kerberos = RC4-128+
hash@kerberos = MD5+
cipher@gnutls = RC4-128+
hash@gnutls = MD5+

and then set sytem-wide policy to use DEFAULT:MY-MODULE as a policy.

This doesn't define it per application but at least limits use of
insecure types to Kerberos and any application using GnuTLS.

I actually haven't tried this all.


Testing with this policy now and nope, Samba 4.15.3 says:

...

[2022/01/25 14:21:55.930113,  2, pid=16175] 
ipa_sam.c:3645(init_sam_from_ldap)

  init_sam_from_ldap: Entry found for user: dupa
[2022/01/25 14:21:55.947759,  1, pid=16175] 
../../source3/auth/check_samsec.c:454(check_sam_security)

  Failed to modify entry: NT_STATUS_NOT_IMPLEMENTED


All these modifications of the policy will not change the fact that we
do not implement modification of SAM entry in IPA SAM module. This means
you are getting in a different code path here.

So probably more changes to the policy are needed...



Here is something VERY ? peculiar...

1) I could both smbclient & ssh between IPA masters with passwords

2) I could ssh from a non-enrolled to IPA master with the password

3) non-enrolled smbclient _failed_ as with the log snipped, with password

then I looked at that Samba log again and did, on a master:

-> $ ipa passwd dupa

now I do ! can 3)

WTF? I must say.

user was created by IPA with '--password 
--password-expiration=20310312232428Z' as args to 'ipa user-add'


So, the policy seems good!! but that 'monstrosity' ? anybody will 
agree will be a 'bug', right?


I think what you see above is that the user was created before IPA setup
was enabled to handle trust configuration (which is a pre-requisite to
generate NT hashes). So when you re-generated password, that triggered
adding NT hash to that user.

With newer IPA (4.9.8 in Fedora or CentOS 9 Stream, for example, or
recent RHEL 8.5 update) you still need to prepare IPA to work with trust
(ipa-adtrust-install) but proper NT hash generation internally is
enabled from initial install instead of when ipa-adtrust-install is run.
For new installations this should reduce the gap as users created after
install would already be ready to access Samba when ipa-adtrust-install
will be run.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: parse the audit logs

[Mark Reynolds via FreeIPA-users]

The audit log is essentially just a list of LDIF commands.  If you 
remove the "time" and "result" lines you can redirect the log straight 
to ldapmodify:



time: 20220126111500
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
result: 0
changetype: modify
replace: nsslapd-lookthroughlimit
nsslapd-lookthroughlimit: 5001
-
replace: modifiersname
modifiersname: cn=dm
-
replace: modifytimestamp
modifytimestamp: 20220126161500Z
-


I'm not sure this log is worth "parsing" since it's just describing the 
exact changes made to the server, and I'm not sure there are that many 
any useful "stats" that could be gained by parsing it.  What exactly are 
you hoping to get out of it?


Mark

On 1/26/22 11:05 AM, Florence Blanc-Renaud via FreeIPA-users wrote:

Hi,
You should try with 389-us...@lists.fedoraproject.org 
, 
other users may have found a solution to your problem.

flo

On Fri, Jan 21, 2022 at 6:45 PM Kathy Zhu  wrote:

Yes, correct, Florence.

BTW, Florence, I'd like to take this opportunity to let you know
that I benefit from your blog, especially the one about certificates.

Thanks!

Kathy.

On Fri, Jan 21, 2022 at 1:17 AM Florence Blanc-Renaud
 wrote:

Hi Kathy,
which log file are you referring to? 389-ds audit log in
/var/log/dirsrv/slapd-xxx/audit?

flo

On Thu, Jan 20, 2022 at 6:43 PM Kathy Zhu via FreeIPA-users
 wrote:

Hello list,

I had FreeIPA audit log on. I feed audit logs to Graylog.
Since there are multiple lines of logs for each event, I
could not find a suitable extractor to parse the logs.
Therefore, the logs are very hard to read. Could anyone in
the list share how you process the logs if you are in a
similar situation?

Thanks!

Kathy.



___
FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure


___
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org
To unsubscribe send an email tofreeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report 
it:https://pagure.io/fedora-infrastructure


--
Directory Server Development Team
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: parse the audit logs

[Florence Blanc-Renaud via FreeIPA-users]

Hi,
You should try with 389-us...@lists.fedoraproject.org
,
other users may have found a solution to your problem.
flo

On Fri, Jan 21, 2022 at 6:45 PM Kathy Zhu  wrote:

> Yes, correct, Florence.
>
> BTW, Florence, I'd like to take this opportunity to let you know that I
> benefit from your blog, especially the one about certificates.
>
> Thanks!
>
> Kathy.
>
> On Fri, Jan 21, 2022 at 1:17 AM Florence Blanc-Renaud 
> wrote:
>
>> Hi Kathy,
>> which log file are you referring to? 389-ds audit log in
>> /var/log/dirsrv/slapd-xxx/audit?
>>
>> flo
>>
>> On Thu, Jan 20, 2022 at 6:43 PM Kathy Zhu via FreeIPA-users <
>> freeipa-users@lists.fedorahosted.org> wrote:
>>
>>> Hello list,
>>>
>>> I had FreeIPA audit log on. I feed audit logs to Graylog. Since there
>>> are multiple lines of logs for each event, I could not find a suitable
>>> extractor to parse the logs. Therefore, the logs are very hard to read.
>>> Could anyone in the list share how you process the logs if you are in a
>>> similar situation?
>>>
>>> Thanks!
>>>
>>> Kathy.
>>>
>>>
>>>
>>> ___
>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> To unsubscribe send an email to
>>> freeipa-users-le...@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.fedorahosted.org
>>> Do not reply to spam on the list, report it:
>>> https://pagure.io/fedora-infrastructure
>>>
>>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure