ldap cheatsheet

• slapacl: Checks the access to a list of attributes
• slapadd: Adds entries from an LDIF file to an LDAP directory
• slapauth: Checks a list of IDs for authentication and authorization permissions
• slapcat: Generates LDIF output from an LDAP directory
• slapdn: Checks a list of distinguished names (DNs) based on schema syntax
• slapindex: Re-indexes the directory. Run slapindex whenever indexing options are changed in the configuration file.
• slappasswd: Is a password utility for creating an encrypted user password
• slapschema: Checks compliance of a database with the corresponding schema
• slaptest: Checks the LDAP server configuration

LDAP is an simpler alternative to the X.500 Directory Access Protocol (DAP) but it is still a hierarchical DIT

A directory database is typically fairly static with reads far outstripping writes. As such they typically have:

• no transactions
• no rollback
• updates are all or nothing, or possibly not allowed at all.
• tuned for read performance, i.e. high-volume read

Implementations can use various databases. The DIT could be local to an organization, or global. A directory defines a uniform namespace, i.e. the same view is presented regardless of where queried, even in global directories.

Examples of global directory service is the Open Directory Project, dmoz.org This link will not respond to a typicall http request, but a ldap request.

Could be a relational database system, rdbs, or could be LDBS (built-in to OpenLDAP, a.k.a. slapd)

Typically organization and user authentication and authorization data. i.e. user rights data.

These are the typical keys in a DIT, typically from the top down.

dc = domain component

cn = common name

ou = organizational unit

mail = email address

sn = surname

A suffix is a branch or subtree whose entire contents are treated as a unit for admin purposes. Allows for splitting up the dit across multiple servers.

The top level tree root is called the root suffix

• A single tree, with a single root.
• Hierarchical
• distributed across 1 or more servers
• Entries consist of a set of attributes
  • each attribute has one or more values
• Each entry has a unique DN. ( Distinguished Name )
• Each unique DN is formed by combining its RDN, one or more attributes of the entry itself, and the RDN of each of the superior entries up to the root of the DIT. An analogy: if named.conf is the RDN, then /etc/named.conf is DN

A DN may change over the lifetime of the entry, for instance when entries are moved within a tree, from one department to another.

Below is an excerpt of a entry, when represented in the LDIF format (LDAP Data Interchange Format, LDIF):

dn: cn=John Doe,dc=zintis,dc=ops
cn: John Doe
givenName: John

sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: john@example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

dn is the distinguished name, i.e. cn=John Doe,dc=zintis,dc=ops

rdn is John doe, the relative distinguished name

"dn" is neither an attribute nor a part of the entry.

I could try using, or adding, an attribute to an entry. Let's say people that are registered to attend a conference will each get a polo shirt. I could try to add and attribute: ShirtSize: XL

But ldap would complain about that being an Object class violation". Therefore I must first define that attribute somewhere. The place where all attributes are defined, and the rules for attribute types are defined, is called a schema.

The set of rules that define the available attributes that you can use. Schemas have certain pre-defined standard attributes,

ou: organizational unit

cn: …

And user defined attributes

ShirtSize:

These attributes are defined under a set of object classes. Put another way, Attributes of the directory server are defined under object classes

Therefore, if you want to use an attribute that is defined in the directory server, you must also specify the object class of the attribute.

Have to mention which object class defines an attribute along with the attribute.

For example: The ojbect class that defines the attribute "ou" is "organizational unit:" would look like this:

dn: ou=engineering,dc=zintis,dc=ops
objectClass: organizationalunit
ou: engineering

You could not just do this. It would give you an error:

dn: ou=engineering,dc=zintis,dc=ops
ou: engineering

ou is an attribute of the domain, "dc=zintis,dc=ops" To see all attributes, you could run slapcat (but that also dumps all entries which is obviously overkill unless your directory is very small. Better to look at the schema. Can think of the schema as a template too.

/etc/openldap/schema

The file core.schema is included in the slapd.conf file. Every attriute that I define for the entries in my ldap server must match something in this core.schema file. You can add other, additional schemas but they must be mentioned in the slapd.conf file.

Opening up /etc/openldap/schema/core.schema you can see the definitions of the objectClasses. For instance, searching for organizationalUnit will show you this:

objectclass ( 2.5.6.5 NAME 'organizationalUnit'
     DESC 'RFC2256: an organizational unit'
     SUP top STRUCTURAL
     MUST ou
     MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
             x121Address $ registeredAddress $ destinationIndicator $
             preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
             telephoneNumber $ internationaliSDNNumber $
             facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
             postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )

That shows us that ou is a MUST have. If you are going to use this object class, you must have at least the ou attribute specified.

If you are going to use this object class, you also have the optional "MAY" attributes, ilke address, telephone number, etc..

(not covered in OPS335) A server holds a subtree starting from a specific entry, eg. dc=zintis,dc=ops and its children

Servers may hold reference to other servers, so an attempt to access ou=department,dc=zintis,dc=ops could return a referral or continution reference to a server that holds that part of the tree.

Recursive lookups are called "chaining" were the server does the lookup of the related server, on behalf of the client. usually the server just returns the address of the other server to the client and it is up to the client to query the next server.

It is a key-value database, implementing an upside down tree. i.e. root at the top.

Keys start the line followed by a colon space, then the value.

key: value

key: value

one key: value per line.

key: value (you need the <space> after the colon.)

LDIF is used to represent ldap data, but also and interestingly LDIF is used as input by LDAP commands to allow adds and edits of LDAP directory data.

So your interaction with an LDAP directory DIT is going to be via LDIF files.

LDIF can describe any entry within an LDAP system, as well as any changes or modifications to the system. i.e. DIT. Changes to the LDAP DIT are simply written within .ldif files with arbitrary names, and then "applied" to the ldap dit with one of several management commands that read data from this file

• ldbmcat converts ldbm database to ldif
• ldif2ldbm coverts ldif back to ldbm database

slapadd adds users in bulk. Your slapd(8) should not be running when you do this to ensure consistency of the database. Also slapadd may not provide naming or schema checks.

Therefore, it is advisable to use ldapadd when adding new entries into an existing directory.

To add a use to an ldap directory, you want that user to have the same password as the Linux password. OpenLDAP comes with tools for doing this, called "migrate_passwd.pl" (in the /usr/share/migrationtools directory)

First, pull out the line from /etc/passwd for the user in question.

grep -w zintis /etc/passwd > /root/zintispasswd.entry

Then use the migration tool to genearte that user's ldif file.

cd /usr/share/migrationtools
migrate_passwd.pl /root/zintispasswd.entry /root/zintisldap.ldif

less /root/zintisldap.ldif

• ldapadd: Adds entries to an LDAP directory either from a file or from standard input.
• ldapmodify: Modifies entries in an LDAP directory [ ldapmodify -a is identical to ldapadd. ]
• ldapadd is a symbolic link to ldapmodify -a, and it is used to read a user's ldif file and create an entry in the LDAP DIT for that user.

  ldapadd -x -v -D cn="ldaproot,dc=andrew,dc=ops" -W -f zintisldap.ldif=
  

  Credentials are always needed, so you will always see -D and -w or -W in every Openldap command.

  -D bind a.k.a. authentication user and tree root (top level) the credentials are for a specific user in the DIT, with a distinguished name (dn) at the top of the domain.

  -w password will use simple authentication and need the password (seneca99ldap)

  -W prompt for password

  -x Use simple authentication instead of SASL

  -f the file that as the user info in the LDIF format.

• the distinguished name, dn, of the ldap administrator is dn: cn=ldaproot,dc=andrew,dc=ops

ldapadd -x -W -D "cn=ldaproot,dc=andrew,dc=ops" -f usertoadd.ldif

The order of options does not matter, except that file has to follow -f and the dn has to follow -D.

Now if you are making several modifications within the same LDIF file, or even some mods as well as additions, OpenLDAP offers "Changetype: Add"

So, we could be modifying several entries, and adding a new entry. It looks much like above where we were just adding new entries, but we just add the line changetype: add directly below the dn: specification.

Let's say your directory information tree, DIT, already has ou=People,dc=worldtour2020,dc=com Then adding like this:

dn: uid=roadie22,ou=People,dc=worldtour2020,dc=com
changetype: add
objectClass: inetOrgPerson
description: Roadie Dude.  Roadie is a contracted roadie for
our North America leg of this world tour.
cn: Roadie-No.22
sn: Smith
uid: roadie22

Most every authentication looks the same:

-D "cn=ldaproot,dc=andrew,dc=ops" -W
-D "cn=admin,dc=acme,dc=com" -W
-D "cn=netops,dc=cisco,dc=com" -W

This first one is the bind of the user ldaproot in the andrew.ops tree with a prompted password (-W)

The "D" refers to a Bind "dn". The distinguised name that is used to bind you to the directory.

To delete an entry from an DIT, the process only needs the unique dn. So it is fairly easy. For instance, if we wanted to remove the ou=othergroup entry from our DIT, our LDIF file, rm-group.ldif, would only need to contain:

dn: ou=othergroup,dc=example,dc=com
changetype: delete

To actually do the deletion:

ldapmodify -x -D "cn=admin,dc=example,dc=com" -W -f rm-group.ldif

If you specify changetype and ommit the -a flag, then it is a true modifiy type. So if we make changes to certain fields in the .ldif file for a user, we can apply those changes in the DIT database with:

ldapmodify -x -D "cn=ldaproot,dc=andrew,dc=ops" -W -f modifyfile.ldif

-D …. -W are credentials -x use simple authentication vs SASL -f ldif file that has entries such as this:

dn: entryDN
changetype: modify
add: attribute 
attribute: value...
-
replace: attribute 
attribute: newValue...
-
delete: attribute 
[attribute: value]
...

Can use the same ldif file repeatedly, just be editing it and re-applying the new edits with the ldapmodify command. So for example, you can have an editing window open to changejohn.ldif then writing every change, one at a time with each change applied from another windowo that has the following two commands, repeated over and over, until the changes are done.

ldapmodify -x -D cn="ldaproot,dc=andrew,dc=ops" -w seneca99ldap
           -f changejohn.ldif
ldapsearch -x -D cn="ldaproot,dc=andrew,dc=ops" -w seneca99ldap
           -b dc=andrew,dc=ops uid=john

Similarily for another user, say, "jane"

ldapmodify -x -D cn="ldaproot,dc=andrew,dc=ops" -w seneca99ldap  
           -f changejane.ldif
ldapsearch -x -D cn="ldaproot,dc=andrew,dc=ops" -w seneca99ldap
           -b dc=andrew,dc=ops uid=jane

ldapmodify -x -D cn="ldaproot,dc=andrew,dc=ops" -w seneca99ldap -f changejane.ldif

These two are the same, while local host and port 389 are the defaults. ldapsearch -h localhost -p 389 -D cn="ldaproot,dc=andrew,dc=ops" -w seneca99ldap -b dc=andrew,dc=ops uid=john ldapsearch -D cn="ldaproot,dc=andrew,dc=ops" -w seneca99ldap -b dc=andrew,dc=ops uid=john

1. replace and existing attribute:

   dn: uid=john,ou=People,dc=andrew,dc=ops changetype: modify replace: gecos gecos: John Long Baldry

2. Add a new attribute:

   dn: uid=john,ou=People,dc=andrew,dc=ops changetype: modify add: roomNumber roomNumber: 1729

3. Delete an attribute

   dn: uid=john,ou=People,dc=andrew,dc=ops delete: title title: Grand Poobah

add: jpegPhoto jpegPhoto:<

delete: description

ldappasswd -s password123 -W -D "cn=ldaproot,dc=andrew,dc=ops"
           -x "uid=john,ou=people,dc=andrew,dc=ops"

-x username for which the password is changed -s specify the password for the username -D Distinguished name to bind (authenticate) to the LDAP server

ldapsearch -x -h localhost -p 389 -D cn="Manager,dc=acme,dc=com" -W
            -b dc=acme,dc=com objectClass=*

-h the host where you want to search (the defaul is localhost)

-p the port 389[default] over ldap, 636 over SSL-ldap, 389 over TLS

-D is the "binding" or authentication to the server. so specify the user, and its hierarchy? This is referred to as the "bind dn" is that what cn="…." is?

-W is not a password, but asking to be prompted for a password

-b is the search base dn." It is the place where you wish to start the search. If you are using an ldif file that has the base distinguished name clearly indluded as part of the add/modify, you won't need to specify -b.

finally "objectClass=*" is the filter you want to search for.

The following example shows that the results of these two operations are the same, even though the way they were queried are very different:

root@vm4~[798]$ 
ldapsearch -h localhost -p 389 -D cn="ldaproot,dc=andrew,dc=ops" -w seneca99ldap -b dc=andrew,dc=ops objectClass=* | grep "dn:"
dn: dc=andrew,dc=ops
dn: cn=ldaproot,dc=andrew,dc=ops
dn: ou=People,dc=andrew,dc=ops
dn: ou=Group,dc=andrew,dc=ops
dn: uid=john,ou=People,dc=andrew,dc=ops
dn: uid=zintis,ou=People,dc=andrew,dc=ops
dn: uid=jane,ou=People,dc=andrew,dc=ops
dn: uid=guest,ou=People,dc=andrew,dc=ops
dn: uid=deleteme,ou=People,dc=andrew,dc=ops

root@vm4~[799]$ 
slapcat | grep "dn:"
5e8397f1 The first database does not allow slapcat; using the first available one (2)
dn: dc=andrew,dc=ops
dn: cn=ldaproot,dc=andrew,dc=ops
dn: ou=People,dc=andrew,dc=ops
dn: ou=Group,dc=andrew,dc=ops
dn: uid=john,ou=People,dc=andrew,dc=ops
dn: uid=zintis,ou=People,dc=andrew,dc=ops
dn: uid=jane,ou=People,dc=andrew,dc=ops
dn: uid=guest,ou=People,dc=andrew,dc=ops
dn: uid=deleteme,ou=People,dc=andrew,dc=ops

root@vm4~[800]$ 

"Binding means authentication." So the unbind operation simply abandons any outstanding operations and closes the connection. Think of it "logoff".

It has no response. The name is of historical origin, and is NOT the opposite Bind.

Using Linux commandline ldapxxx commands are one-offs and you don't need to unbind, or rather every command finishes by undbinding. So you need to bind again at each new command.

dn: uid=zintis,ou=People,dc=andrew,dc=ops
uid: zintis
cn: zintis
sn: zintis
mail: zintis@zintis.ops
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$6$mjRyTHR5$ARM0BM7g1dPc422iHK3BGVHqcXVty0FETrE6yj/N47sudpjivy0ExxSNpvzW.
shadowLastChange: 18348
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 10000
gidNumber: 10000
homeDirectory: /home/zintis

slapcat
5e80f53b The first database does not allow slapcat; using the first available one (2)
dn: dc=andrew,dc=ops
dc: andrew
objectClass: top
objectClass: domain
structuralObjectClass: domain
entryUUID: 0192e632-da18-1038-83ca-ef40d5fa4d01
creatorsName: cn=ldaproot,dc=andrew,dc=ops
createTimestamp: 20190313201201Z
entryCSN: 20190313201201.126862Z#000000#000#000000
modifiersName: cn=ldaproot,dc=andrew,dc=ops
modifyTimestamp: 20190313201201Z

dn: cn=ldaproot,dc=andrew,dc=ops
objectClass: organizationalRole
cn: ldaproot
description: LDAP Manager
structuralObjectClass: organizationalRole
entryUUID: 019a13f8-da18-1038-83cb-ef40d5fa4d01
creatorsName: cn=ldaproot,dc=andrew,dc=ops
createTimestamp: 20190313201201Z
entryCSN: 20190313201201.174170Z#000000#000#000000
modifiersName: cn=ldaproot,dc=andrew,dc=ops
modifyTimestamp: 20190313201201Z

dn: ou=People,dc=andrew,dc=ops
objectClass: organizationalUnit
ou: People
structuralObjectClass: organizationalUnit
entryUUID: 01a1a870-da18-1038-83cc-ef40d5fa4d01
creatorsName: cn=ldaproot,dc=andrew,dc=ops
createTimestamp: 20190313201201Z
entryCSN: 20190313201201.223848Z#000000#000#000000
modifiersName: cn=ldaproot,dc=andrew,dc=ops
modifyTimestamp: 20190313201201Z

dn: ou=Group,dc=andrew,dc=ops
objectClass: organizationalUnit
ou: Group
structuralObjectClass: organizationalUnit
entryUUID: 01ac22f0-da18-1038-83cd-ef40d5fa4d01
creatorsName: cn=ldaproot,dc=andrew,dc=ops
createTimestamp: 20190313201201Z
entryCSN: 20190313201201.292521Z#000000#000#000000
modifiersName: cn=ldaproot,dc=andrew,dc=ops
modifyTimestamp: 20190313201201Z

dn: uid=john,ou=People,dc=andrew,dc=ops
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
cn: john
uid: john
uidNumber: 9999
gidNumber: 100
homeDirectory: /home/john
loginShell: /bin/bash
gecos: John Someone
shadowLastChange: 17058
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
structuralObjectClass: account
entryUUID: bfa78756-da1b-1038-83d1-ef40d5fa4d01
creatorsName: cn=ldaproot,dc=andrew,dc=ops
createTimestamp: 20190313203848Z
userPassword:: e1NTSEF9a0ljTGtXdVkxNXBQL0labDN3TklBaE5MSm94cWU4ZVQ=
entryCSN: 20190709215232.858989Z#000000#000#000000
modifiersName: cn=ldaproot,dc=andrew,dc=ops
modifyTimestamp: 20190709215232Z

This ldapusers.ldif file had an error that shows up with error: "no global superior knowledge"

root@vm4~[604]$ 
ldapadd -v -f ldapusers.ldif -D cn="ldaproot,dc=zintis,dc=ops" -W 
ldap_initialize( <DEFAULT> )
Enter LDAP Password: seneca99ldap
add uid:
     zintis
add cn:
     zintis
add sn:
     zintis
add mail:
     zintis@zintis.ops
add objectClass:
     person
     organizationalPerson
     inetOrgPerson
     posixAccount
     top
     shadowAccount
add userPassword:
     {crypt}$6$mjRyTHR5$ARM0hiRWKGdBM7g1dPc422i4Ut9TQ7HKty0FETrE6yj/NxudpjitlrhkNpvzW.
add shadowLastChange:
     18348
add shadowMin:
     0
add shadowMax:
     99999
add shadowWarning:
     7
add loginShell:
     /bin/bash
add uidNumber:
     10000
add gidNumber:
     10000
add homeDirectory:
     /home/zintis
adding new entry "uid=zintis,ou=People,dc=zintis,dc=op"s
ldap_add: Server is unwilling to perform (53)
     additional info: no global superior knowledge

root@vm4~[604]$ 

The error above occurs because we were trying to add entries specified for the zintis.ops tree, where the tree was actually andrew.ops.

Fix was to correct the config file in : /usr/share/migrationtools/migrate-passwd.pl so that the migrate_passwd step would generate ldif data correctly (i.e. dc=andrew,dc=ops)

This specific error means that slapd doesn't know where to put the new entry. This typically means that you have not defined an appropriate database, or you have made a typo in the higher in the tree. With newer systems (ones using cn=config instead of slapd.conf), you would typically first add a new database or modify an existing database entry using ldapadd or ldapmodify.

For example, let's say you are trying to add "uid=zintis,ou=People,dc=zintis,dc=ops" But you are in a tree with dc=zint,dc=ops slapd cannot find the root tree dc=zint,dc=ops so it says "No superior knowledge".

useradd zintis -u 10000
useradd -c "Jane Greystoke" jane -u 10001
useradd -c "Andrew's Guests" guest -u 10002

if user jane already exists, delete her with userdel jane
also chown her mailbox with chown jane /var/spool/mail/jane
And delete /var/spool/mail/andrew

grep -w zintis /etc/passwd > /root/zintis.entry
grep -w Jane /etc/passwd > /root/jane.entry
grep -w Andrew /etc/passwd > /root/guest.entry

/usr/share/migrationtools/migrate_passwd.pl /root/zintis.entry /root/zintis.ldif
/usr/share/migrationtools/migrate_passwd.pl /root/jane.entry /root/jane.ldif
/usr/share/migrationtools/migrate_passwd.pl /root/guest.entry /root/guest.ldif

ldapadd -v -f ldapusers.ldif -D cn="ldaproot,dc=andrew,dc=ops" -W 
ldapadd -v -f jane.ldif -D cn="ldaproot,dc=andrew,dc=ops" -W 
ldapadd -v -f guest.ldif -D cn="ldaproot,dc=andrew,dc=ops" -W 

slapcat shows user John as:

dn: uid=john,ou=People,dc=andrew,dc=ops
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
cn: john
uid: john
uidNumber: 9999
gidNumber: 100
homeDirectory: /home/john
loginShell: /bin/bash
gecos: John Someone
shadowLastChange: 17058
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
structuralObjectClass: account
entryUUID: bfa78756-da1b-1038-83d1-ef40d5fa4d01
creatorsName: cn=ldaproot,dc=andrew,dc=ops
createTimestamp: 20190313203848Z
userPassword:: e1NTSEF9a0ljTGtXdVkxNXBQL0labDN3TklBaE5MSm94cWU4ZVQ=
entryCSN: 20190709215232.858989Z#000000#000#000000
modifiersName: cn=ldaproot,dc=andrew,dc=ops
modifyTimestamp: 20190709215232Z

This is PAM the "Pluggable Authentication Module" and NSS the "Name Service Switch"

yum install -y openldap-clients nss-pam-ldapd Since CentOS8 does not see nss-pam-ldap I did the following:

First: dnf provides nss-pam-ldapd Then, based on the above this: dnf install -y nss-pam-ldapd-0.9.9-3.el8.x86₆₄

From arthurdejong.org: This is nss-pam-ldapd which provides a Name Service Switch (NSS, nsswitch) module that allows your LDAP server to provide user account, group, host name, alias, netgroup, and basically any other information that you would normally get from /etc flat files or NIS. It also provides a Pluggable Authentication Module (PAM) to do identity and authentication management with an LDAP server on unix systems.

This is implemented using thin NSS and PAM modules which delegate to a dedicated service (nslcd) that queries the LDAP server with persistent connections, authentication, attribute translation, etc.

The NSS module was originally a fork of nss_ldap with some structural design improvements. The most important features of nss-pam-ldapd are:

• light and simple NSS and PAM libraries
• avoid loading LDAP and SSL libraries in all programs
• separation between NSS, PAM and LDAP code
• fewer connections to the LDAP server
• better debugging possibilities
• better performance
• See the documentation section for more detai

Configure the client VM to use LDAP To add the client machine to LDAP server for single sign-on. Replace “192.168.1.10” with your LDAP server’s IP address or hostname.

authconfig –enableldap –enableldapauth –ldapserver=192.168.1.10 –ldapbasedn="dc=itzgeek,dc=local" –enablemkhomedir –update

Restart the LDAP client service. O.K, so this will make this VM defer logins to the LDAP server rather than looking in its own /etc/passwd file ??? That would mean that the users defined in the ldap server would require a local prescence on this VM, including home directory, and entry in /etc/passwds. I guess this is just centralizing the passwords themselves I guess?? Confirm this!

systemctl restart nslcd To verify LDAP Login, use the getent command to get the LDAP entries from the LDAP server.

getent passwd raj Output:

raj:x:9999:100:Raj [Admin (at) ITzGeek]:/home/raj:/bin/bash Screenshot:

OpenLDAP Server Configuration on CentOS 7 - Verify LDAP Login OpenLDAP Server Configuration on CentOS 7 – Verify LDAP Login

To verify the LDAP, log in using the LDAP user “raj” on the client machine. Like this:

These two videos explain LDAP nicely. Worth the 40 minutes of watching.

https://youtu.be/9x6_ALb76sQ

https://youtu.be/SJ5WYGTHQnY