Re: [External] Re: LDAP confusion with security settings
Roger Long and Bob Hansel nailed it. The userID is performing RACF LG commands
and when I removed SPECIAL these commands started failing on the middleware
machine. They were failing silently because I turned on UAUDIT for this ID
and got absolutely nothing back.I just completed testing of adding ROAUDIT
and removing SPECIAL and it is still working.
Thanks all, for your assistance and especially Bob and Roger for pointing me in
the right direction. One more RACF SPECIAL account removed!
Rex
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Robert S. Hansel (RSH)
Sent: Saturday, July 10, 2021 5:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: LDAP confusion with security settings
Hi Rex,
Very strange indeed. This does not seem like a native LDAP issue. Have you
looked at the source code of the software that is processing logons to see if
this ID is embedded in the code? Is this ID coded as the USERID on any CICS
terminal definitions or started transaction EXEC CICS START commands related to
this logon process? If you have SETROPTS SAUDIT or AUDIT(USER) active, have you
looked at SMF data to see if it is issuing any RACF commands, in particular
ALTUSER PASSWORD NOEXPIRE? Have you tried adding UAUDIT to the ID to see what
else it might be doing? If you have a product like zSecure Access Monitor, what
activity does it show for this ID? What happens if you swap ROAUDIT for
SPECIAL? If you define profiles LISTUSER and LU in the PROGRAM class with
ADDMEM('SYS1.LINKLIB'//NOPADCHK) UACC(READ) AUDIT(ALL), does SMF data show this
ID using these programs? My extreme SWAG is that it is being used to handle
password expiration and password changes.
Regards, Bob
Robert S. Hansel2021 #IBMChampion
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.twitter.com/RSH_RACF
www.rshconsulting.com
-Original Message-
Date:Fri, 9 Jul 2021 17:10:22 +
From:"Pommier, Rex"
Subject: LDAP confusion with security settings
Hi list,
I don't know if this belongs in the TCP/IP list, RACF list or here so I'm
starting here. Here's the situation as best I understand it. First off, LDAP
is a black hole as far as I'm concerned. It was set up here long before my
time. We're using it to communicate and authenticate to RACF for users coming
in from a browser into our CICS regions. The LDAP server runs under a user ID
of LDAPSRV. Users coming in from the browser are given a logon screen where
they enter their own ID and password which LDAP validates against RACF. LDAP
provides the appropriate ICH408I message if they fat-finger a password etc.
That part is all OK. The RACF group that LDAPSRV is a member of is LDAPGRP and
some of the attributes assigned to LDAPSRV are actually given through the group.
The LDAP server is defined within RACF in the APPL class and anybody that
tries to log on through LDAP need to have READ access to this APPL.
Here's where I'm getting confused. There is another ID on the system, we'll
call LDAPU, that has no special privileges except this ID is RACF SPECIAL. The
group this ID belongs to (LDAP) also has no special privileges. The ID is not
UID0 and the only connection LDAPU has is to the LDAP group, the only
permission it has is to the LDAPSRV APPL. The LDAP group actually has no
permissions given to it. The only thing strange is that the ID has SPECIAL.
Since the ID isn't anything special (or so I thought) I removed SPECIAL from
it. As soon as I removed SPECIAL, anybody coming in through the browser
started getting invalid userid or password errors on their browser logon page.
They were getting NO RACF ICH408I messages being logged either in the SYSLOG or
in the LDAPSRV address space. As soon as I gave SPECIAL back to LDAPU
everything started working again. I can find nowhere within the LDAP config
file that defines LDAPU as any kind of special ID that has magical powers over
people trying to log in thru the LDAP. If anybody has any idea where I could
go look for what LDAP is using this ID for or where it is defined to use this
ID for something, I'd appreciate it. I really don't like the idea of having a
RACF SPECIAL user floating around that nobody knows why it has SPECIAL.
Apologies if this sounds as confusing to you reading it as it does to me
writing it.
Thanks,
Rex
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The information contained in this message is confidential, protected from
disclosure and may be legally privileged. If the reader of this message is not
the intended recipient or an employee or agent responsible for delivering this
message to the intended recipie
Re: [External] Re: LDAP confusion with security settings
Hi Attila, At first I thought you might be on to something there, but alas, no. We are actually running the Tivoli LDAP server. Thanks for the suggestion, though. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Attila Fogarasi Sent: Sunday, July 11, 2021 7:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: LDAP confusion with security settings It sounds like you are using the old zos LDAP server which IBM discontinued circa zos 1.11 for good reason ... replaced by the Tivoli LDAP server which uses SDBM to access RACF. Probably to fix this key integrity vulnerability that you have highlighted. It is a very high risk for your zos to be hacked running this way, you undoubtedly realize what SPECIAL can do. You need to switch to a supported and working LDAP server on zos, there are no free ones for RACF but ACF2 and TSS come with an LDAP server included. Maybe IBM will cut you a deal for the Tivoli Directory Server that you need. On Sat, Jul 10, 2021 at 3:10 AM Pommier, Rex wrote: > Hi list, > > I don't know if this belongs in the TCP/IP list, RACF list or here so > I'm starting here. Here's the situation as best I understand it. > First off, LDAP is a black hole as far as I'm concerned. It was set > up here long before my time. We're using it to communicate and > authenticate to RACF for users coming in from a browser into our CICS > regions. The LDAP server runs under a user ID of LDAPSRV. Users > coming in from the browser are given a logon screen where they enter > their own ID and password which LDAP validates against RACF. LDAP > provides the appropriate ICH408I message if they fat-finger a password > etc. That part is all OK. The RACF group that LDAPSRV is a member of > is LDAPGRP and some of the attributes assigned to LDAPSRV are actually given > through the group. > > The LDAP server is defined within RACF in the APPL class and anybody > that tries to log on through LDAP need to have READ access to this APPL. > > > Here's where I'm getting confused. There is another ID on the system, > we'll call LDAPU, that has no special privileges except this ID is > RACF SPECIAL. The group this ID belongs to (LDAP) also has no special > privileges. The ID is not UID0 and the only connection LDAPU has is to the > LDAP group, the only permission it has is to the LDAPSRV APPL. The LDAP > group actually has no permissions given to it. The only thing strange > is that the ID has SPECIAL. Since the ID isn't anything special (or > so I > thought) I removed SPECIAL from it. As soon as I removed SPECIAL, > anybody coming in through the browser started getting invalid userid > or password errors on their browser logon page. They were getting NO > RACF ICH408I messages being logged either in the SYSLOG or in the > LDAPSRV address space. As soon as I gave SPECIAL back to LDAPU > everything started working again. I can find nowhere within the LDAP > config file that defines LDAPU as any kind of special ID that has > magical powers over people trying to log in thru the LDAP. If anybody > has any idea where I could go look for what LDAP is using this ID for > or where it is defined to use this ID for something, I'd appreciate > it. I really don't like the idea of having a RACF SPECIAL user floating > around that nobody knows why it has SPECIAL. > > Apologies if this sounds as confusing to you reading it as it does to > me writing it. > > Thanks, > Rex > > The information contained in this message is confidential, protected > from disclosure and may be legally privileged. If the reader of this > message is not the intended recipient or an employee or agent > responsible for delivering this message to the intended recipient, you > are hereby notified that any disclosure, distribution, copying, or any > action taken or action omitted in reliance on it, is strictly > prohibited and may be unlawful. If you have received this > communication in error, please notify us immediately by replying to > this message and destroy the material in its entirety, whether in electronic > or hard copy format. Thank you. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is
Re: LDAP confusion with security settings
It sounds like you are using the old zos LDAP server which IBM discontinued circa zos 1.11 for good reason ... replaced by the Tivoli LDAP server which uses SDBM to access RACF. Probably to fix this key integrity vulnerability that you have highlighted. It is a very high risk for your zos to be hacked running this way, you undoubtedly realize what SPECIAL can do. You need to switch to a supported and working LDAP server on zos, there are no free ones for RACF but ACF2 and TSS come with an LDAP server included. Maybe IBM will cut you a deal for the Tivoli Directory Server that you need. On Sat, Jul 10, 2021 at 3:10 AM Pommier, Rex wrote: > Hi list, > > I don't know if this belongs in the TCP/IP list, RACF list or here so I'm > starting here. Here's the situation as best I understand it. First off, > LDAP is a black hole as far as I'm concerned. It was set up here long > before my time. We're using it to communicate and authenticate to RACF for > users coming in from a browser into our CICS regions. The LDAP server runs > under a user ID of LDAPSRV. Users coming in from the browser are given a > logon screen where they enter their own ID and password which LDAP > validates against RACF. LDAP provides the appropriate ICH408I message if > they fat-finger a password etc. That part is all OK. The RACF group that > LDAPSRV is a member of is LDAPGRP and some of the attributes assigned to > LDAPSRV are actually given through the group. > > The LDAP server is defined within RACF in the APPL class and anybody that > tries to log on through LDAP need to have READ access to this APPL. > > > Here's where I'm getting confused. There is another ID on the system, > we'll call LDAPU, that has no special privileges except this ID is RACF > SPECIAL. The group this ID belongs to (LDAP) also has no special > privileges. The ID is not UID0 and the only connection LDAPU has is to the > LDAP group, the only permission it has is to the LDAPSRV APPL. The LDAP > group actually has no permissions given to it. The only thing strange is > that the ID has SPECIAL. Since the ID isn't anything special (or so I > thought) I removed SPECIAL from it. As soon as I removed SPECIAL, anybody > coming in through the browser started getting invalid userid or password > errors on their browser logon page. They were getting NO RACF ICH408I > messages being logged either in the SYSLOG or in the LDAPSRV address > space. As soon as I gave SPECIAL back to LDAPU everything started working > again. I can find nowhere within the LDAP config file that defines LDAPU > as any kind of special ID that has magical powers over people trying to log > in thru the LDAP. If anybody has any idea where I could go look for what > LDAP is using this ID for or where it is defined to use this ID for > something, I'd appreciate it. I really don't like the idea of having a > RACF SPECIAL user floating around that nobody knows why it has SPECIAL. > > Apologies if this sounds as confusing to you reading it as it does to me > writing it. > > Thanks, > Rex > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby notified > that any disclosure, distribution, copying, or any action taken or action > omitted in reliance on it, is strictly prohibited and may be unlawful. If > you have received this communication in error, please notify us immediately > by replying to this message and destroy the material in its entirety, > whether in electronic or hard copy format. Thank you. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LDAP confusion with security settings
On Fri, 9 Jul 2021 17:10:22 +, Pommier, Rex wrote: >Hi list, > >I don't know if this belongs in the TCP/IP list, RACF list or here so I'm >starting here. Here's the situation as best I understand it. First off, LDAP >is a black hole as far as I'm concerned. It was set up here long before my >time. We're using it to communicate and authenticate to RACF for users coming >in from a browser into our CICS regions. The LDAP server runs under a user ID >of LDAPSRV. Users coming in from the browser are given a logon screen where >they enter their own ID and password which LDAP validates against RACF. LDAP >provides the appropriate ICH408I message if they fat-finger a password etc. >That part is all OK. The RACF group that LDAPSRV is a member of is LDAPGRP >and some of the attributes assigned to LDAPSRV are actually given through the >group. > >The LDAP server is defined within RACF in the APPL class and anybody that >tries to log on through LDAP need to have READ access to this APPL. > > >Here's where I'm getting confused. There is another ID on the system, we'll >call LDAPU, that has no special privileges except this ID is RACF SPECIAL. >The group this ID belongs to (LDAP) also has no special privileges. The ID is >not UID0 and the only connection LDAPU has is to the LDAP group, the only >permission it has is to the LDAPSRV APPL. The LDAP group actually has no >permissions given to it. The only thing strange is that the ID has SPECIAL. >Since the ID isn't anything special (or so I thought) I removed SPECIAL from >it. As soon as I removed SPECIAL, anybody coming in through the browser >started getting invalid userid or password errors on their browser logon page. > They were getting NO RACF ICH408I messages being logged either in the SYSLOG >or in the LDAPSRV address space. As soon as I gave SPECIAL back to LDAPU >everything started working again. I can find nowhere within the LDAP config >file that defines LDAPU as any kind of special ID that has magical powers over >people trying to log in thru the LDAP. If anybody has any idea where I could >go look for what LDAP is using this ID for or where it is defined to use this >ID for something, I'd appreciate it. I really don't like the idea of having a >RACF SPECIAL user floating around that nobody knows why it has SPECIAL. > Rex, At a guess, I would say the application that is presenting the logon screen to the user is doing either a LU or LG of the user attempting to sign in. Do you have access to the application code to check if that is the case? I have had a similar situation when setting up the TS7700 HMC MI authentication using zOS LDAP and RACF as the backend Hope that helps. Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LDAP confusion with security settings
Hi Rex,
Very strange indeed. This does not seem like a native LDAP issue. Have you
looked at the source code of the software that is processing logons to see if
this ID is embedded in the code? Is this ID coded as the USERID on any CICS
terminal definitions or started transaction EXEC CICS START commands related to
this logon process? If you have SETROPTS SAUDIT or AUDIT(USER) active, have you
looked at SMF data to see if it is issuing any RACF commands, in particular
ALTUSER PASSWORD NOEXPIRE? Have you tried adding UAUDIT to the ID to see what
else it might be doing? If you have a product like zSecure Access Monitor, what
activity does it show for this ID? What happens if you swap ROAUDIT for
SPECIAL? If you define profiles LISTUSER and LU in the PROGRAM class with
ADDMEM('SYS1.LINKLIB'//NOPADCHK) UACC(READ) AUDIT(ALL), does SMF data show this
ID using these programs? My extreme SWAG is that it is being used to handle
password expiration and password changes.
Regards, Bob
Robert S. Hansel2021 #IBMChampion
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.twitter.com/RSH_RACF
www.rshconsulting.com
-Original Message-
Date:Fri, 9 Jul 2021 17:10:22 +
From:"Pommier, Rex"
Subject: LDAP confusion with security settings
Hi list,
I don't know if this belongs in the TCP/IP list, RACF list or here so I'm
starting here. Here's the situation as best I understand it. First off, LDAP
is a black hole as far as I'm concerned. It was set up here long before my
time. We're using it to communicate and authenticate to RACF for users coming
in from a browser into our CICS regions. The LDAP server runs under a user ID
of LDAPSRV. Users coming in from the browser are given a logon screen where
they enter their own ID and password which LDAP validates against RACF. LDAP
provides the appropriate ICH408I message if they fat-finger a password etc.
That part is all OK. The RACF group that LDAPSRV is a member of is LDAPGRP and
some of the attributes assigned to LDAPSRV are actually given through the group.
The LDAP server is defined within RACF in the APPL class and anybody that
tries to log on through LDAP need to have READ access to this APPL.
Here's where I'm getting confused. There is another ID on the system, we'll
call LDAPU, that has no special privileges except this ID is RACF SPECIAL. The
group this ID belongs to (LDAP) also has no special privileges. The ID is not
UID0 and the only connection LDAPU has is to the LDAP group, the only
permission it has is to the LDAPSRV APPL. The LDAP group actually has no
permissions given to it. The only thing strange is that the ID has SPECIAL.
Since the ID isn't anything special (or so I thought) I removed SPECIAL from
it. As soon as I removed SPECIAL, anybody coming in through the browser
started getting invalid userid or password errors on their browser logon page.
They were getting NO RACF ICH408I messages being logged either in the SYSLOG or
in the LDAPSRV address space. As soon as I gave SPECIAL back to LDAPU
everything started working again. I can find nowhere within the LDAP config
file that defines LDAPU as any kind of special ID that has magical powers over
people trying to log in thru the LDAP. If anybody has any idea where I could
go look for what LDAP is using this ID for or where it is defined to use this
ID for something, I'd appreciate it. I really don't like the idea of having a
RACF SPECIAL user floating around that nobody knows why it has SPECIAL.
Apologies if this sounds as confusing to you reading it as it does to me
writing it.
Thanks,
Rex
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LDAP confusion with security settings
I don't know the answer to your question but oh boy! > I really don't like the idea of having a RACF SPECIAL user floating around > that nobody knows why it has SPECIAL You can say that again! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Friday, July 9, 2021 10:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: LDAP confusion with security settings Hi list, I don't know if this belongs in the TCP/IP list, RACF list or here so I'm starting here. Here's the situation as best I understand it. First off, LDAP is a black hole as far as I'm concerned. It was set up here long before my time. We're using it to communicate and authenticate to RACF for users coming in from a browser into our CICS regions. The LDAP server runs under a user ID of LDAPSRV. Users coming in from the browser are given a logon screen where they enter their own ID and password which LDAP validates against RACF. LDAP provides the appropriate ICH408I message if they fat-finger a password etc. That part is all OK. The RACF group that LDAPSRV is a member of is LDAPGRP and some of the attributes assigned to LDAPSRV are actually given through the group. The LDAP server is defined within RACF in the APPL class and anybody that tries to log on through LDAP need to have READ access to this APPL. Here's where I'm getting confused. There is another ID on the system, we'll call LDAPU, that has no special privileges except this ID is RACF SPECIAL. The group this ID belongs to (LDAP) also has no special privileges. The ID is not UID0 and the only connection LDAPU has is to the LDAP group, the only permission it has is to the LDAPSRV APPL. The LDAP group actually has no permissions given to it. The only thing strange is that the ID has SPECIAL. Since the ID isn't anything special (or so I thought) I removed SPECIAL from it. As soon as I removed SPECIAL, anybody coming in through the browser started getting invalid userid or password errors on their browser logon page. They were getting NO RACF ICH408I messages being logged either in the SYSLOG or in the LDAPSRV address space. As soon as I gave SPECIAL back to LDAPU everything started working again. I can find nowhere within the LDAP config file that defines LDAPU as any kind of special ID that has magical powers over people trying to log in thru the LDAP. If anybody has any idea where I could go look for what LDAP is using this ID for or where it is defined to use this ID for something, I'd appreciate it. I really don't like the idea of having a RACF SPECIAL user floating around that nobody knows why it has SPECIAL. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
LDAP confusion with security settings
Hi list, I don't know if this belongs in the TCP/IP list, RACF list or here so I'm starting here. Here's the situation as best I understand it. First off, LDAP is a black hole as far as I'm concerned. It was set up here long before my time. We're using it to communicate and authenticate to RACF for users coming in from a browser into our CICS regions. The LDAP server runs under a user ID of LDAPSRV. Users coming in from the browser are given a logon screen where they enter their own ID and password which LDAP validates against RACF. LDAP provides the appropriate ICH408I message if they fat-finger a password etc. That part is all OK. The RACF group that LDAPSRV is a member of is LDAPGRP and some of the attributes assigned to LDAPSRV are actually given through the group. The LDAP server is defined within RACF in the APPL class and anybody that tries to log on through LDAP need to have READ access to this APPL. Here's where I'm getting confused. There is another ID on the system, we'll call LDAPU, that has no special privileges except this ID is RACF SPECIAL. The group this ID belongs to (LDAP) also has no special privileges. The ID is not UID0 and the only connection LDAPU has is to the LDAP group, the only permission it has is to the LDAPSRV APPL. The LDAP group actually has no permissions given to it. The only thing strange is that the ID has SPECIAL. Since the ID isn't anything special (or so I thought) I removed SPECIAL from it. As soon as I removed SPECIAL, anybody coming in through the browser started getting invalid userid or password errors on their browser logon page. They were getting NO RACF ICH408I messages being logged either in the SYSLOG or in the LDAPSRV address space. As soon as I gave SPECIAL back to LDAPU everything started working again. I can find nowhere within the LDAP config file that defines LDAPU as any kind of special ID that has magical powers over people trying to log in thru the LDAP. If anybody has any idea where I could go look for what LDAP is using this ID for or where it is defined to use this ID for something, I'd appreciate it. I really don't like the idea of having a RACF SPECIAL user floating around that nobody knows why it has SPECIAL. Apologies if this sounds as confusing to you reading it as it does to me writing it. Thanks, Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
